Where Deterministic Workflows Should Bound AI Agents

"Agent" is often used for any system that calls a language model and a tool. Anthropic's engineering guidance Building effective agents draws a sharper line. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths"; agents are "systems where LLMs dynamically direct their own processes and tool usage." The useful architecture question is not which one to pick, but where the boundary between them should sit.

Let the model decide only what cannot be specified

The same guidance recommends "finding the simplest solution possible, and only increasing complexity when needed." Workflows "offer predictability and consistency for well-defined tasks"; agents fit when "flexibility and model-driven decision-making are needed at scale." That suggests a practical test. If a step can be written as a rule, a schema or a fixed sequence, write it in code. Give the model the parts that need judgment, such as interpreting a request, choosing the next document to read or drafting text.

What stays deterministic

Some responsibilities stay outside the model whatever the design.

• Authorization. OWASP's entry on Excessive Agency recommends complete mediation: enforce authorization in the downstream systems instead of relying on the model to decide whether an action is allowed. Tools should act with the end user's permissions, not a broad service account.
• Tool scope. The same entry advises offering only the tools a task needs, with the narrowest permission on each, such as read-only access where the agent only reads.
• Validation. The Model Context Protocol (MCP) specification requires servers to validate tool inputs, enforce access controls and rate-limit invocations. It asks clients to validate tool results before passing them to the model and to time out slow calls.
• Limits. Anthropic notes that agents commonly include stopping conditions, such as a maximum number of iterations, to maintain control. Budgets for steps, tokens and time belong in code the model cannot edit.
• Approval. OWASP recommends human approval for high-impact actions before they run, and MCP says there should always be a human able to deny a tool invocation.

A bounded agent in practice

Consider a request to change the delivery address on an order. The agent reads the message, finds the order and proposes the change. Code then checks that the requester owns the order, validates the address and applies the change through the order system's own interface, which logs it. If the order is already being picked, a person approves the change; if it has shipped, the case goes to a person. The model never decides whether it is allowed to write.

# Illustrative policy, not a production configuration
tool: update_delivery_address
model_role: propose          # the model proposes; code applies
checks:                      # run by code before any write
  - requester_owns_order
  - address_passes_schema
apply_when:
  order_status: [created]
approval_when:
  order_status: [picking]
otherwise: route_to_person   # for example, the order has shipped
limits:
  max_steps: 6
  timeout_seconds: 30

Why the boundary matters

Anthropic warns that autonomy brings "higher costs, and the potential for compounding errors," and recommends testing in sandboxed environments with appropriate guardrails. A deterministic boundary limits how far one wrong step travels: a bad proposal fails a check instead of becoming a change in a system of record. It also gives evaluations and audits something stable to test. The Architecture Lab study From Prompt to Action: Anatomy of an AI Agent shows where these checks sit in a tool-using loop.