Start with the decision the agent is allowed to make
An agent that summarizes an incident is a different proposition from an agent that changes a production configuration. Both might use the same model. Their architecture should not be the same.
Before drawing an agent diagram, write down the actions it can take, the systems it can reach and the decisions it must hand back to a person. This short exercise usually exposes more risk than debating frameworks.
- Read-only assistance: retrieve and summarize information without changing source systems.
- Proposed actions: prepare a change for human approval, with the proposed effect made visible.
- Bounded execution: perform narrow, reversible actions under explicit limits.
- High-impact operations: require stronger authorization, review and recovery design.
Pattern 1: Put a policy gate between reasoning and tools
Treat the model's tool request as an untrusted proposal. A separate service checks the user's identity, the agent's permitted scope, the target resource and the requested operation. Only then does the tool run.
For example, a support agent may draft a refund, but the transaction service should independently enforce refund limits and approval rules. A prompt telling the agent to be careful is not an authorization boundary.
- Use narrowly scoped credentials rather than shared administrator access.
- Validate tool arguments and restrict destination systems.
- Record the decision made by the policy gate, including denials.
Pattern 2: Separate planning from execution
Let an agent produce a plan that another component can inspect before any meaningful side effect occurs. This makes it easier to catch a wrong target, an unexpected sequence or a missing prerequisite.
A plan does not need to be elaborate. For a change-management assistant, it might contain the target service, proposed change, expected impact and rollback instruction. The execution service should verify those fields again when the action is taken.
Pattern 3: Design for interruption and recovery
Agents will encounter timeouts, conflicting data, partial tool failures and repeated requests. The system needs to know whether an action completed before it tries again.
Use idempotency keys for actions that could otherwise run twice. Set budgets for steps, time and tool calls. Provide a stop mechanism and an escalation route when the agent cannot determine a safe next move.
Pattern 4: Observe decisions, not only model responses
A transcript is useful for investigation, but it is a poor substitute for operational telemetry. Track the tool requested, authorization result, execution outcome, retries, human interventions and the version of the policy applied.
Be selective with what you log. Sensitive prompts and retrieved records may require redaction, retention limits and controlled access.
A useful architecture review exercise
Pick one agent workflow your team wants to deploy. Walk through a normal request, a malicious or mistaken request, a tool timeout and a human override. At each step, ask which component has authority to say no.
If the answer is always 'the model will decide,' the boundary is probably too weak. Start with a narrow workflow, make the controls observable and expand autonomy only after you have evidence that the system behaves as intended.