The no-agent test: when ordinary automation is the better choice

An agent can interpret a goal, choose steps and use tools under changing conditions. That flexibility is valuable when the path cannot be specified in advance. It is unnecessary overhead when the path can be specified.

Before approving an agent, design the strongest credible version of the workflow without one. Compare the two. If a form change, deterministic rule, search interface, scheduled integration or conventional workflow engine solves the problem, choosing it is not a failure of innovation. It is sound engineering.

The UK Government Service Standard asks teams to consider alternatives to creating a new service and to avoid designing around a pre-selected technology. The no-agent test applies that discipline to autonomy.

Start with the capability the workflow actually needs

Separate the requested outcome from the fashionable implementation. “We need an agent to triage requests” might contain several needs:

• capture structured information;
• detect missing fields;
• classify a request against a stable taxonomy;
• retrieve relevant policy;
• route the case by explicit rules;
• summarise material for a reviewer; or
• act when the situation does not match known patterns.

The first five may be handled with ordinary interfaces, validation, search and rules. Summarization may use a model inside a fixed workflow. Only the final need clearly suggests adaptive planning—and even then, the correct response to an unknown case may be escalation rather than more autonomy.

Write the required capability without mentioning AI. Then identify which parts require interpretation, which require probabilistic estimation and which require control of an action sequence.

Run six gates before granting agent autonomy

The no-agent test uses six gates. A “no” does not automatically reject the proposal, but it shifts the burden of proof towards the simpler design.

1. Does the path vary for legitimate reasons?

Agents are useful when the appropriate next step depends on context that cannot be reduced to a manageable decision table. Variation caused by a broken process, inconsistent policy or missing master data is not a reason to add an agent. Repair the source of variation first where possible.

2. Does the system need to interpret unstructured evidence?

Large volumes of documents, conversations or observations can justify model assistance. But interpretation does not require control. A model can extract or propose while deterministic software governs state transitions and an eligible person approves a consequential decision.

3. Is adaptive planning valuable at runtime?

If engineers can enumerate the sequence, retries and exceptions, a workflow engine offers clearer behaviour and easier testing. An agent earns its place when choosing among tools or routes at runtime creates material value across a sufficiently diverse case set.

4. Can its authority be bounded and enforced?

The system must know which resources, actions, amounts, case classes and time windows are permitted. A prompt such as “do not make risky changes” is not an enforcement boundary. If least privilege cannot be expressed and checked outside the model, keep the component advisory or redesign the integration.

5. Can performance be observed in the world?

The final message is not enough. The team needs to inspect the records retrieved, decisions made, tools called, state changed, approvals obtained and recovery taken. Where outcomes cannot be observed, it is hard to demonstrate that flexible planning improved the workflow.

6. Is the value greater than the operating burden?

Include evaluation, review, monitoring, incident response, vendor change, model and prompt maintenance, latency, token or compute usage, support, security and exception handling. A solution that saves operator minutes but creates an expensive assurance function may still be worthwhile—but the comparison should be explicit.

Compare four solution shapes on the same cases

Take a representative set of workflow cases, including exceptions, and prototype four versions:

Shape	What varies	What remains deterministic
Process change	Human practice and information design	Existing systems
Rules and workflow	Inputs and predefined branches	Sequence and authority
AI-assisted workflow	Model output within selected steps	State, permissions and routing
Bounded agent	Planning and tool selection within limits	Policy gates, budgets and prohibited actions

Use the same outcome and control measures for all four. Compare completion, quality, error consequence, review effort, recoverability, cost and user experience. Do not give the agent a polished interface while comparing it with an unreformed manual process; that confounds autonomy with product design.

NIST’s AI RMF asks organisations to define targeted scope, expected benefits and costs, human oversight and appropriate benchmarks before deployment (AI RMF Core). The non-agent design is often the most informative benchmark because it represents the actual investment alternative.

Know the signals that favour ordinary automation

Prefer conventional software when most of these conditions hold:

• the inputs can be made structured at reasonable cost;
• policy can be represented as stable rules;
• the valid path and exceptions are enumerable;
• exact repeatability is important;
• actions have high consequence and little tolerance for interpretation;
• response time or unit cost is tightly constrained;
• the workflow has low case variety; and
• a reliable API or system event already exposes the necessary state.

For example, reconciling invoice totals against an approved purchase order is primarily a deterministic control. A model might help extract fields from varied documents, but allowing an agent to decide whether mismatches are acceptable mixes evidence extraction with financial authority. Keep the arithmetic and policy gates explicit.

NIST notes that risk tolerance is contextual and that resources should be prioritised by assessed impact (Framing Risk). High consequence does not ban an agent, but it raises the evidence threshold and usually narrows permitted action.

Know the signals that can justify an agent

An agent becomes more plausible when:

• cases are varied but share a bounded outcome;
• relevant evidence is distributed across sources;
• the useful path changes with evidence discovered during the task;
• there are several equivalent safe sequences;
• the agent can stop and transfer state when uncertainty is high;
• tool permissions and budgets are enforceable; and
• the outcome and important intermediate states are measurable.

Consider a support investigation. A rules engine can route by product and severity. An agent may add value by forming hypotheses, selecting diagnostic queries and assembling evidence across logs and documentation. It should not silently expand its own access or apply a production change because its diagnosis sounds confident.

Treat simplicity as a performance property

Simplicity is not merely lower build effort. A simpler system can offer stronger properties:

• behaviour that is easier to specify and reproduce;
• fewer permissions and dependencies;
• lower evaluation surface;
• clearer recovery semantics;
• easier operator training; and
• more stable unit economics.

GAO describes technology readiness assessment as an evidence-based way to examine whether critical technologies are mature enough for integration and to expose risk before resource needs rise (GAO). Apply the same reasoning to autonomy: do not integrate the most flexible design until its critical behaviours are mature enough for the intended setting.

Record why the agent won

If the agent design passes, preserve the comparison. State which cases required adaptation, what the simpler alternatives could not do, which authority boundaries apply, how outcomes will be observed, and what operating cost was accepted. That record gives future reviewers a way to challenge the design when workflows or technology change.

If the agent does not pass, keep the work. The no-agent design is now a delivery candidate, and the case set becomes a benchmark if adaptive autonomy is reconsidered later.

Agents should be chosen for the value of bounded adaptation, not for the prestige of using them. The strongest agent strategy includes the discipline to build none where ordinary automation is better.