When an AI agent is the wrong architecture

A fixed approval rule does not become a better rule because a language model interprets it. If an invoice above an agreed threshold needs a second approver, ordinary software can enforce that condition consistently. The more interesting question is whether the work around the rule requires judgment that a fixed workflow cannot reasonably provide.

That is where an enterprise architect should begin an agent proposal. Identify the decision that genuinely needs adaptive behaviour, then ask whether giving a model that discretion improves the completed business task. “We need an agent” is an architectural conclusion, not a requirement.

Find the uncertainty that matters

Anthropic’s guidance on building effective agents distinguishes predefined workflows from systems where a model dynamically directs its process and tool use. It recommends beginning with the simplest solution and adding complexity where it improves outcomes, recognising the latency and cost trade-offs.

For a buyer, that distinction is more useful than a product’s agent label. A task can contain one ambiguous step without requiring autonomy across the whole process. Interpreting a supplier’s free-text request may benefit from a model; checking an account identifier and enforcing a spending limit can remain deterministic.

Keep those boundaries separate. The model might propose a classification or assemble missing information while ordinary application logic controls what can be submitted. That gives the organisation a narrower evaluation problem and a clearer failure path.

Compare three versions of the same task

Take a hypothetical purchase-request workflow. One version uses structured forms and fixed routing. A second uses a model to interpret unstructured requests, then hands a validated record to the same routing logic. A third lets an agent decide what information to obtain and which tools to call.

Compare completed, acceptable requests rather than impressive individual responses. The fixed workflow may demand more initial input from users but be easier to support. The assisted workflow may remove that friction without changing approval authority. The agent may help with genuinely variable cases, but its extra calls and actions need to earn their place.

Include retries, human correction and requests that never finish. An agent that makes easy cases faster but produces difficult exceptions can move work onto the very specialists the project was intended to free.

Look for conditions that favour a simpler design

Stable rules, a small number of predictable routes and well-structured inputs usually make direct automation a strong comparator. If the main problem is missing data or an unclear business policy, adding an agent may merely make the ambiguity harder to see.

Slow feedback is another warning. When a mistaken action is discovered only after a customer complaint or a financial reconciliation, the system has fewer opportunities to correct itself during the task. The architecture needs stronger limits than an experiment where every step has an immediate, reliable result.

Recovery effort matters too. Reversing a draft is different from unwinding several changes across customer, finance and fulfilment systems. If the business cannot explain how a partial run will be reconciled, narrow the scope before expanding autonomy.

A human approval must be a real control

Adding an approval screen does not automatically make a broad agent appropriate. The reviewer needs to see the proposed action and its relevant evidence, and the application must enforce the decision on the action that executes. Otherwise the human is checking a summary while a different operation proceeds.

Our guide to human approval for AI examines that boundary. It is especially important where the agent can revise a plan after an approval or call several tools under one broad permission.

Leave a route to reconsider

Rejecting agent autonomy today need not mean rejecting it permanently. A model-assisted workflow can produce evidence about ambiguous cases, correction effort and the tasks that genuinely resist fixed routing. That evidence provides a better basis for a later agent pilot.

Proceed when adaptive planning solves a demonstrated problem and the team can observe, constrain and recover the work. Use a failure-based agent evaluation to test that proposition. A simpler architecture that completes the task reliably is a successful outcome, even when the original proposal promised more autonomy.