Applied AI Notes · What Businesses Are Asking AI to Do · October 2026
How Will Anyone Know It Works?
What business requirements for AI systems say about acceptance, oversight and running the system once it is live.
- 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
In 39% of about 220 real business projects for AI systems that act through software tools, the requirements reviewed state no success check: no test cases, no known answers, no metric. I surveyed requirements published online over roughly the first two weeks of October 2026 and classified each against the framework I use to decide when a task needs an agent at all.
The first article in this series covered what businesses ask for and how often an “agent” turns out to be a workflow. This one covers acceptance and responsibility: how the requirements say success will be judged, who steps in when the system is unsure, and who runs it once it is live.
Acceptance checks are often unspecified
Among projects that state a check, 81% are classified as reference checks, such as a test or a comparison with known values, or 49% of all projects. A metric or model-based assessment accounts for 6% of all projects and someone's judgment that the output looks right for 6%. Each project has one category; when several apply, a reference check takes precedence over a metric, then judgment.
A requirement to test is not the same as a defined acceptance criterion: an explicit testing requirement counts here as a reference check even when no pass threshold is given, so these figures do not measure how many projects define adequate criteria.
Detailed specifications usually state a check
Specifications fall into three levels: a brief one names a goal and little else, while a detailed one reads like an engineering brief, naming systems, approval points and deployment. Among detailed specifications, 9% state no success check, against 72% of brief ones.
| Brief | Partial | Detailed | |
|---|---|---|---|
| Share of projects | 26% | 40% | 35% |
| Design too vague to tell | 70% | 17% | 4% |
| No success check stated | 72% | 45% | 9% |
| Human review or approval | 4% | 47% | 75% |
| Deployment or maintenance | 18% | 44% | 75% |
| Names the systems to connect | 40% | 72% | 88% |
The level reflects how completely the requirements describe the task, inputs, outputs and acceptance. Because acceptance is part of that judgment, the link with stated checks is partly built in.
Projects started by events more often mention people
53% of projects describe a system started by events or schedules (an incoming call, a new lead, a nightly run) rather than on demand, when a person or another program hands over a job. Compared with on-demand projects, they more often mention human review, approval or handoff (59% against 42%) and state a success check about as often (65% against 63%).
| Requirement | Started by events or schedules | Started on demand |
|---|---|---|
| Human review, approval or handoff mentioned | 59% | 42% |
| Success check stated | 65% | 63% |
| Neither mentioned | 19% | 25% |
Projects whose requirements do not make the trigger clear are left out of this comparison.
Chat and voice assistants are the largest group here: 85% of them are started by events, and 33% state no success check. They speak to customers on the business's behalf and, in many projects, book appointments or write to a CRM.
Delivery is more than the model
46% of projects mention human review, approval or a handoff to a person; 48% mention deployment, monitoring or maintenance; 46% raise guardrails, privacy or compliance, but only 22% set cost or speed limits and 13% mention a simpler option. In 26% of projects, the requirements state a success check and mention both human involvement and deployment or maintenance; 22% do so with a reference check.
Each kind of system draws a different set of requirements: read across a row to see what projects of that kind tend to specify, where darker cells mean more of them do.
| Systems named | Human review | Deployment | Testing | Guardrails | Interpretation | Cost or speed | Simpler option | |
|---|---|---|---|---|---|---|---|---|
| Chat or voice assistant | 79% | 52% | 48% | 56% | 44% | 36% | 26% | 15% |
| Business workflow automation | 68% | 32% | 44% | 44% | 24% | 32% | 3% | 3% |
| Multi-agent platform | 55% | 68% | 73% | 73% | 82% | 45% | 32% | 23% |
| Tool integration (MCP) | 78% | 17% | 50% | 50% | 56% | 17% | 17% | 11% |
| Content pipeline | 65% | 59% | 47% | 35% | 41% | 53% | 35% | 12% |
| Outreach sequencing | 90% | 50% | 30% | 30% | 50% | 90% | 10% | 10% |
| Research or monitoring | 80% | 60% | 60% | 90% | 80% | 70% | 50% | 60% |
| Knowledge Q&A | 78% | 33% | 44% | 56% | 44% | 22% | 33% | 0% |
| All projects | 70% | 46% | 48% | 53% | 46% | 38% | 22% | 13% |
Columns follow the requirement list in the chart above. Smaller task groups are left out of this table and included in “All projects”.
What this means
The gaps sit in acceptance and responsibility: about two in five requirements do not say how success will be checked, and some that ask for testing do not say what the test must show. Requirements for systems started by events more often mention people stepping in, yet state a success check about as often as on-demand ones, although these are the systems that act for the business without anyone handing them a job; that does not show that either control is enough. The third article sets out what a business can settle before anyone builds to make acceptance and responsibility explicit.
Next: Before you commission an agent
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.