Comparing the interaction patterns
| Dimension | Who decides next | Authority | Typical fit |
|---|---|---|---|
| Chat interface | The person, every turn. | None beyond the conversation. | Exploration and drafting where the user reviews everything. |
| Retrieval (RAG) | The person, with the system choosing sources. | Read-only over permitted content. | Questions answered from an owned corpus. |
| Deterministic workflow | The designer, in advance. | Whatever the steps were built to do. | Known sequences with predictable failures. |
| Agent with tools | The system, within a defined tool set. | Scoped reads, and writes behind approval. | Variable sequences with cheap detection and reversal. |
| Autonomous loop | The system, repeatedly. | Widest, and the easiest to get wrong. | Rarely justified; only with strong limits and monitoring. |
Five patterns that get called the same thing
A chat interface answers questions. A retrieval system grounds answers in owned sources. A deterministic workflow executes steps someone defined. An agent chooses its own next action from a set of tools. An autonomous loop does that repeatedly, with less supervision. Each step along that line adds authority and removes predictability, so the pattern has to be chosen deliberately rather than described loosely.
- Chat: conversation, no tool access
- Retrieval: grounded answers from owned sources
- Workflow: fixed steps, predictable failure
- Agent: chooses tools within a defined set
- Autonomous loop: repeated action, highest supervision cost
Where agents genuinely help
Agents earn their place when the sequence of steps cannot be known in advance, the environment provides reliable feedback, and a wrong step is cheap to detect and reverse — triage across several systems, gathering evidence for a review, or assembling a report from multiple sources. They struggle where feedback is delayed, actions are irreversible, or success is defined by judgement nobody has written down.
Tool permissions are the design
An agent's capability equals the tools it holds, so the smallest useful set is the goal. Give read access where reading is enough, scope writes to specific records, expire credentials, and separate tools that change external systems from those that only read them. Require human approval for anything irreversible, and make the approval request state exactly what would change.
Treat every tool result as untrusted input. A web page, email or document an agent reads can contain instructions, and an agent holding write tools can be steered by them. OWASP lists prompt injection and excessive agency among the top risks for LLM applications for exactly this reason.
- Minimum tool set per task, reviewed like any permission
- Read and write capabilities separated
- Irreversible actions gated behind explicit approval
State, planning and failure handling
Long-running agents accumulate state, and state is where silent errors hide. Define what is remembered, where it is stored, how it is reset, and what happens when a tool call fails or returns something unexpected. Cap the number of steps, add a deadline, and design a safe stop instead of assuming the loop converges.
Audit, rollback and human approval
Every consequential action should be reconstructable: what was requested, what the agent decided, which tool ran with which arguments, and who approved it. Rollback has to be designed per action type — a sent message cannot be unsent, but a record change can be reversed if the previous value was captured first. Where neither is possible, the action should not be delegated.
- Decision and tool calls recorded with their inputs
- Reversal designed per action, tested before launch
- Actions that cannot be reversed stay human
Illustrative example · hypothetical organisation
Worked example: an access-request agent
Take a hypothetical agent that handles requests for access to internal applications.
It can read the request, look up the requester's team and manager, and check the access policy for the application. Those tools are read-only. It cannot grant access itself: it drafts the change and sends it to the application owner, who approves or rejects it in one step.
The agent stops after a fixed number of tool calls, records each call with its inputs and result, and hands the case to a person when the policy is ambiguous. Revoking access, which is quick to do and hard to notice when wrong, is not delegated at all.
When not to use an agent
If the steps are known, a workflow is cheaper, faster and easier to audit. If the task is answering questions, retrieval is the right pattern. If success depends on judgement that has not been codified, an agent will encode someone's guess and act on it repeatedly. Autonomy is worth paying for only when the path genuinely cannot be predetermined.
Questions and trade-offs
Question
Do we need an agent or a workflow?
If the steps can be written down in advance, build the workflow: it is cheaper to run, easier to test and simpler to audit. Choose an agent only when the sequence genuinely varies with the situation, the environment gives reliable feedback, and a wrong step is cheap to detect and reverse.
Question
How do we prevent an agent causing damage?
By limiting what it can reach instead of asking it to behave. Give the smallest useful tool set, keep writes behind human approval, cap steps and time, record every decision with its inputs, and design the reversal for each action type. Where no reversal exists, keep the action with a person.
Question
What is the Model Context Protocol?
MCP is an open protocol for connecting AI applications to tools and data sources through a standard interface. It makes tools easier to plug in, which makes permission design more important: each connected server is a capability the agent holds, so scope, credentials and approval rules apply to it like any other integration.
