For: Architects, engineering leads and product owners choosing how much autonomy an enterprise AI use case needs.
What must the system decide at runtime?#
A request written in natural language does not automatically require an agent. Consider an invoice intake process: extract fields, validate the supplier, compare the purchase order, and send discrepancies for review. The document layout may vary substantially while the sequence remains stable. A model can help extract the fields without deciding who may be paid or inventing a new approval route.
There are three useful starting patterns. Deterministic software implements explicit rules. An AI-assisted workflow places model calls inside a predefined process. A bounded agent selects its next investigation or action from permitted options using what it has learned. ‘Deterministic’ here describes control flow and business rules; it does not claim that a model’s output becomes deterministic merely because a workflow calls it.
This distinction follows Anthropic’s account of workflows and agents. The framework below is an architectural synthesis, not a vendor standard or a numeric maturity score. It is designed to expose the specific freedom you need to buy, and the controls that freedom requires.
A decision matrix, not an autonomy score#
On a narrow screen, scroll the table sideways to see every column.
| Question | Workflow is a strong fit | An agent may add value |
|---|---|---|
| Where is the uncertainty? | Input wording varies; the required steps are known. | Each finding can change which investigation is useful next. |
| Can routes be named in advance? | A manageable set of branches covers the supported work. | Useful combinations cannot be enumerated economically. |
| How is completion verified? | Typed fields, rules or a reviewer establish completion. | Observable evidence can validate an adaptively chosen path. |
| What happens after a mistake? | Exceptions enter a defined queue with known recovery. | The run can stop, preserve evidence and hand over without compounding effects. |
| What does discretion cost? | Predictable latency and operation count matter most. | Measured outcome gains justify extra calls, latency and supervision. |
Do not total the right-hand column and declare a winner. Some answers are gates. If completion cannot be verified, neither a flexible planner nor a fixed chain deserves autonomous execution. If the proposed tools cannot enforce the user’s permissions, changing the orchestration pattern does not repair that boundary. Resolve those gaps or restrict the capability to a draft that someone can meaningfully inspect.
The matrix can also reveal that the process is simply underspecified. ‘Every case is different’ may mean that no one has documented the existing decision rules. Ask an experienced operator to walk through contrasting cases before treating organizational ambiguity as a reason for machine discretion.
Worked example: a service-operations assistant#
Imagine a team handling requests from business customers about delayed equipment repairs. Staff read a request, locate the repair, inspect workshop events, check the service agreement and prepare a response. Some delays have a standard explanation; others require comparing conflicting records. A proposed ‘repair agent’ includes investigation, drafting, updating a case and sending the customer an email. That label conceals four different decisions.
On a narrow screen, scroll the table sideways to see every column.
| Capability | Initial design | Reason and boundary |
|---|---|---|
| Identify the repair | Constrained extraction plus deterministic lookup | Ambiguous identifiers require clarification, not a guessed match. |
| Explain a standard delay | AI-assisted workflow | Retrieve permitted status and policy, then draft a sourced explanation. |
| Investigate contradictory events | Bounded read-only agent experiment | Select relevant records adaptively; stop when evidence conflicts or the agreed budget is spent. |
| Update the case and send a reply | Explicit human approval plus fixed executor | The operator reviews the exact customer, text and case changes; the model cannot expand them. |
Only the investigation currently justifies testing an agent. Give it approved read tools scoped to one customer and repair. For the experiment, suppose it may make at most six lookups and run for ninety seconds. Those are trial settings chosen to make comparison practical, not production defaults. It returns an evidence bundle, unresolved contradictions and a proposed explanation. It does not change a delivery promise, offer compensation or send anything.
Now consider a workshop event marked ‘dispatched’ while the carrier record says ‘label created’. A fixed workflow could surface both records. The agent earns its place only if a further authorized investigation materially helps: perhaps it finds a later collection scan linked through a replacement shipment identifier. If it merely rewrites the contradiction fluently, it has added cost without resolving the work.
Do not make sending automatic because investigation worked. The next release decision concerns a different capability with different consequences. The bounded-autonomy execution contract describes how to record and enforce that boundary once the pattern has been selected.
Three costs a convincing demonstration hides#
First, review can move rather than disappear. A draft that takes two seconds to produce but fifteen minutes to verify may be worse than a structured ten-minute manual process. Measure reading, source checking, correcting and recovering alongside model runtime. Ask whether the reviewer can detect the important errors from the evidence provided, rather than assuming an approval button solves oversight.
Second, flexibility can silently increase authority. A general tool that searches, edits and deletes is not equivalent to the narrow search operation the use case needs. OWASP’s excessive-agency guidance separates excessive functionality, permissions and autonomy. Treat the candidate’s tool list as part of the architecture decision, not as a convenience hidden inside the prototype.
Third, an ambiguous tool response can create repeated effects. AWS’s analysis of idempotent APIs explains why retry semantics must represent the caller’s intent. In our example, losing the response to ‘create case note’ does not prove that no note exists. A planner that simply tries again may duplicate it. Recovery belongs in the tool and execution contract; it should not depend on the model guessing what happened.
Run an experiment that can reject the agent#
Build the simplest credible workflow baseline, not an intentionally weak strawman. Use the same task definitions, access permissions, authoritative data and completion criteria for both designs. Include ordinary cases, ambiguous identifiers, missing evidence, conflicting records and unavailable dependencies. Keep tuning examples separate from the cases used for the final comparison.
Specify the outcome
Write what a reviewer must be able to verify and what must never happen.
Compare two designs
Run the workflow and bounded agent on matched cases with independent state.
Inspect the difference
Review successful work, unresolved cases, unsafe effects, elapsed time and human effort.
Keep only earned discretion
Select the simpler design unless a repeatable benefit justifies the added operating burden.
Pre-agree the decision rule with the people who own the work. For example: the candidate must improve resolution of contradictory records without weakening permission checks, and the time saved must exceed additional review and recovery. Choose numerical targets from your baseline and risk tolerance. This article deliberately supplies no universal percentage that turns an experiment into permission to deploy.
Repeat representative cases: one successful demonstration says little about consistency. Report the first attempt as well as any permitted retries, and include the retries in cost and time. If the candidate helps only one category, deploy it only there. A routing workflow with a bounded investigation branch is a coherent result, not a compromised agent vision.
Copy this decision record into your architecture review#
A useful decision record can say ‘we do not yet know’. What matters is that uncertainty has an owner and an experiment, rather than being buried under a platform choice. These capability and trade-off exercises connect directly to the Enterprise AI Architecture Bootcamp; the agent evaluation guide turns the comparison criteria into release evidence.
Sources and further reading
Primary sources checked on . Worked examples and worksheets are Ardevant teaching material; sources do not imply endorsement.
- Anthropic: Building effective agents
Supports the distinction between predefined orchestration and model-directed execution, and the need to weigh flexibility against cost and latency. The decision matrix here is Ardevant’s synthesis.
- OWASP: LLM06:2025 Excessive Agency
Describes risks from excessive functionality, permissions and autonomy, with authorization and approval controls outside model judgement.
- AWS Builders’ Library: Making retries safe with idempotent APIs
Explains duplicate side effects, caller-provided request identifiers and retry contracts. It does not establish that any particular agent tool is safe to retry.