Applied AI Notes · What Businesses Are Asking AI to Do · October 2026
Called an Agent, Specified as a Workflow
What businesses ask AI systems to do, and what their requirements actually describe.
- Part 1 of 3Called an agent, specified as a workflow
- Part 2 of 3How will anyone know it works?
- Part 3 of 3Before you commission an agent
For my first series, I plan to track each month what businesses ask AI systems to do: what they want built, how they say success will be checked, and what they leave unsettled. This is the October 2026 edition.
I surveyed the requirements of about 220 real business projects published online over roughly the first two weeks of October 2026: businesses setting out what they want built, or improved, with AI systems that act through software tools. 87% of them ask for an “agent”, but classified by what their requirements describe rather than by the label, 49% of those describe a fixed workflow and 18% a model that has to choose its next step.
The classification uses the framework I use with clients to decide when a task needs an agent at all. This first article covers what businesses ask for and what their requirements describe; the second covers how they say success will be checked, and the third what to settle before commissioning a system.
Assistants and business workflows lead
About a quarter of projects are for a chat or voice assistant: answering customers, qualifying leads, booking appointments and updating the business's own systems as it goes. The next largest group automates a business workflow end to end, followed by multi-agent platforms, tool integrations through the Model Context Protocol (MCP), content pipelines and research monitors.
The demand sits close to revenue: sales and lead generation is the largest named business domain (16% of projects), ahead of internal operations (12%), marketing (11%) and customer support (10%). Real estate and healthcare appear as small niches; finance, accounting and insurance together account for 3% of this sample.
Called an agent, specified as a workflow
I classified each project that asks for an “agent” by what its requirements actually describe, not by the label. 49% describe a fixed workflow: a sequence of steps with a model inside, possibly with branches and retries, where the order of work is known in advance. Only 18% describe a model that has to choose its next step from what it finds, which is what makes a system an agent. Another 6% describe plain code or a single model call, and 27% do not give enough detail to tell.
The tools point the same way: among projects that name a low-code automation platform (n8n, Make or Zapier), 64% describe a fixed workflow and 14% a model that chooses its next step. A typical example is a lead arriving in a CRM, a model classifying it and drafting a reply, and the workflow routing it: an “AI agent” in name, a fixed sequence in practice.
That is not a criticism: where a fixed workflow meets the acceptance criteria, it avoids the added complexity of letting a model direct the work, and its behaviour is easier to test. The label matters because it shapes what gets built and how it is judged.
Where model-directed control may help
A separate screen asks a different question: not what design the requirements describe, but whether the task holds a decision that a fixed procedure might leave unresolved. It flags 13% of projects as possible agent cases, whose open decisions fall into three kinds:
- What to do next, given results. Choosing next week's topics and formats from performance data, the next hypothesis to test, the next change to make toward a ranking goal.
- How to carry out a free-form request. Turning a spoken or written request into the right actions across several applications, or handling whatever a caller or a phone menu presents mid-conversation.
- How to resolve evidence that does not fit. Deciding which source to check next when records conflict, or how to read a form or portal the system has not seen before.
These projects more often name a step that needs interpretation, human review or guardrails. More of them also state how success would be judged and ask for testing or evaluation as part of the work, so on the whole their requirements are more complete than those of other projects.
| Requirement | Possible agent cases | All other projects |
|---|---|---|
| A step that needs interpretation | 90% | 30% |
| Human review, approval or handoff | 86% | 40% |
| Guardrails, privacy, compliance | 90% | 39% |
| Deployment, monitoring, maintenance | 66% | 45% |
| Testing or evaluation | 69% | 51% |
| No success check stated | 17% | 43% |
Passing the screen warrants comparing model-directed control with the strongest fixed workflow; it does not show that an agent is needed. Interpretation is part of the screen, so that difference is partly built in.
What they build with
Low-code automation platforms (n8n, Make, Zapier) are named in 36% of projects, and OpenAI in 30%, while developer agent frameworks such as LangChain and LangGraph appear in only 12%. These categories can overlap, and the requirements may not name every tool used.
What this means
The demand is real and practical: businesses want systems that answer, book, qualify and update the tools they already run, and much of what they describe can be built as a well-designed workflow. The word “agent” should open a conversation about design, not settle it, and the tasks flagged as possible agent cases deserve a direct comparison with the strongest workflow before anyone commits to an agent.
Next: How will anyone know it works?
Method and limits
I surveyed requirements that businesses published online for AI projects over roughly the first two weeks of October 2026, kept those that ask for a system acting through software tools, and kept the projects to build a new system or fix or extend an existing one. A language model classified each set of requirements against a fixed codebook built on the design process and task-screening worksheet I use in practice: the task, the trigger, the design the requirements imply, how success would be checked, the requirements stated, the level of specification and the tools named.
Limits. The requirements were published in one place over about two weeks, so they describe these projects, not the whole market; shares are of projects, and one business may have several. Each project has one retained set of labels; longer requirements were reclassified from the full text, and the latest result was kept. The success-check label was reviewed separately: a second model labelled every project twice, and where its labels and the original disagreed, about a third of projects, a third model settled the label under written rules. Where all three agreed, the label was checked against the same rules, and the third model settled any the check would change, although agreement does not establish correctness. Other labels were not independently re-coded, and no manual audit has been done. The classification read the full text of each set of requirements and reflects what they state, not the system eventually built; businesses may have plans they did not write down. Shares for small groups, such as existing-system work and possible agent cases, are indicative.
Each edition uses the same sources, window and codebook, so editions can be compared; changes describe the mix of requirements, not market growth.
Use of AI tools
A language model classified the requirements against my codebook and helped draft the analysis code and this text, and other AI models re-checked the success-check labels and reviewed the method and claims. I designed the framework and the codebook, checked the figures and am responsible for the conclusions.