Applied AI Notes · What Businesses Are Asking AI to Do · October 2026
Before You Commission an Agent
What projects on existing AI systems specify, and five questions to answer before anyone builds.
- 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 a survey of about 220 real business projects for AI systems that act through software tools, published online over roughly the first two weeks of October 2026, one in five (20%) was to fix or extend a system the business already has. These requirements are brief less often than those for new builds (14% against 28%) and ask for testing more often (61% against 51%), yet their control pattern, whether a fixed workflow or the model decides the next step, is unclear more often: 34%, against 24% of new builds.
The first two articles in this series covered what businesses ask for and what their requirements leave out on acceptance and responsibility. This one looks at how requirements for existing systems differ from those for new builds, and at five questions that make a project's requirements explicit before anyone builds.
Testing and tool integration feature more in existing-system work
20% of projects concern a system the business already has: fixing it, hardening it or extending it. Voice and chat assistants make up 27% of this work, the same share as in new builds. Testing and reliability of existing agents make up 16% of it, against 1% of new builds, and MCP connectors 16%, against 6%.
The trigger and control pattern are more often unclear
Requirements for existing systems state a reference check more often than new builds (57% against 47%), but most of that difference comes from projects that are mainly about testing; with those set aside, the shares are 51% and 47%. Other differences concern the trigger and human involvement: what starts the work is unclear in 32% (against 22%), and they mention human review, approval or handoff less often (36% against 48%). The group is small, so these differences are indicative.
| Requirement | New build | Fix or extend |
|---|---|---|
| Brief specification | 28% | 14% |
| Control pattern unclear from the requirements | 24% | 34% |
| Trigger unclear | 22% | 32% |
| Names the systems to connect | 70% | 66% |
| Human review, approval or handoff | 48% | 36% |
| Deployment, monitoring, maintenance | 48% | 48% |
| Testing or evaluation | 51% | 61% |
| Guardrails, privacy, compliance | 46% | 43% |
| Reference check stated | 47% | 57% |
| No check stated | 41% | 32% |
This table includes projects whose main purpose is testing.
Five questions to answer first
These are my recommendations, drawn from the screening worksheet I use with clients, and they apply to work on an existing system as much as to a new build. Requirements that answer them are easier to price, build and test, and they show early whether an agent is worth considering at all.
- What starts the work?An incoming call, a new lead, a schedule, or a person handing over a job. Decide which actions may proceed automatically and where a person must review.
- What can the system change?List the systems it reads and the ones it writes to, and which actions need a person's approval first.
- Which decisions stay open?Write the strongest fixed workflow first and, where it leaves decisions unresolved, compare letting a model direct the work against it, under the same limits on cost and time.
- How will you know it works?Collect representative cases before building, agree on acceptance criteria, using known answers where available, and name the results that would count as failure.
- Who handles exceptions?Name the person who reviews uncertain cases, the point at which the system hands over, and who maintains it once it is live.
What this means
Existing-system requirements in this sample ask for testing more often than new-build requirements, but more often leave the trigger and control pattern unclear. Both new and existing projects can make those explicit and define acceptance criteria before work begins: known answers where they can be collected, and clear criteria for judgment where they cannot. My recommended starting points are representative cases with agreed acceptance criteria, a clear line between what the system may do alone and what needs approval, and a named owner for exceptions. They give both sides a fair basis for judging the work and holding each other to account.
Back to the start: Called an agent, specified as a workflow
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.