Key takeaways
- An agent is more than a model. It needs a loop, layers, and guardrails.
- Architecture governs what the agent can perceive, do, remember, and recover from.
- Reliable recovery observes workflow state and side effects, not transport signals alone.
What belongs in a generative AI agent architecture?
A generative AI agent architecture includes the model, memory, functions, and routing, but those components are only the inner machinery. A working autonomous agent also needs a loop, layers, and guardrails. The architecture has to determine what the agent can perceive, do, and remember across sessions, along with what happens when something goes wrong.
That surrounding machinery is the harness. In the narrower setting of coding agents, "harness" is shorthand for everything in the agent except the model.
Our agent harness guide develops that outer-system view. For the diagram here, the model sits inside an execution loop. Memory carries state. Functions expose possible actions. Routing decides where work goes. The harness supplies the layers and guardrails around those pieces.
You can test whether those parts form an architecture by tracing a single requested action. Start where the model produces the request. Follow the route to the function, note what memory is available, and continue until the result returns to the loop. Then trace a failed attempt.
The component boundary also keeps model capability separate from system authority. The model participates in the decision, but memory, functions, routing, and the surrounding harness define the path through which that decision becomes work. That path is where production control has to live.
Production failures can change the agent's whole trajectory
Code that works on a developer machine still needs significant engineering before it becomes a reliable production agent. The difficulty is not limited to whether one function call returns an error. Errors can compound in agentic systems, so a problem that would be minor in traditional software can derail an agent.
A failed step can also send the agent onto a different trajectory. The next model decision is then based on a changed state, a missing result, or a side effect that may already have happened. The eventual outcome becomes unpredictable because the agent is no longer following the path the developer expected.
This is why an execution trace needs more than a start box and a success box. The architecture must expose enough workflow state to tell what the agent tried, which side effects occurred, and what decision followed. A retry is not automatically a return to the same point. If the first attempt changed an external system, another attempt can create another change. If a failed result changes the model's reasoning, the loop can head somewhere new.
The production gap is therefore a control problem. The system needs a recovery decision that reflects the work actually performed, not merely the response received by the network layer.
Treat trajectory divergence as its own failure condition. The immediate error tells you that one step failed. It does not tell you whether the agent continued from the expected state or changed direction after the failure. Direct workflow observation is what reveals that distinction. Without it, a healthy transport layer can sit beneath an agent whose reasoning has already moved onto an unintended path.
How should a generative AI agent architecture handle failure?
The control map has two aligned lanes:
- Action lane: model request -> application permission decision -> human approval for a consequential change -> execution.
- Recovery lane: observe workflow state and side effects -> classify the failed work -> apply the recovery control for a read, write, or reasoning loop.
| Control point | Signal or state | Risk | Response |
|---|---|---|---|
| Workflow observation | Workflow state and side effects | A transport success signal misses an agent failure | Observe state and side effects directly |
| Infrastructure monitor | HTTP status and latency | Model-reasoning failure remains invisible | Keep these signals for infrastructure health, not full workflow recovery |
| Read access | Read-only data request | The requested data is temporarily unavailable | Retry aggressively, then use a cached response as fallback |
| Write mutation | Prior execution and partial mutation | A retry duplicates a change that partly completed | Record prior execution, require an idempotency key, and avoid naive retries |
| Reasoning budget | Internal replanning and retries | Infrastructure monitors miss the loop while budget use becomes unbounded | Enforce workflow-level limits |
| Application permission | Requested action and its arguments | The model requests an action it should not execute | Apply least privilege, deterministic authorization, and argument validation |
| Consequential approval | High-impact change awaiting execution | Autonomous action creates consequential risk without clear accountability | Require approval immediately before the change, audit the decision, and support safe shutdown |
The consequential design choice is the split between reads and writes. Read-only access can use aggressive retry and a cached response. A write can partially complete, so recovery records prior execution and uses idempotency instead of retrying naively. The agent loop then carries the applicable limit, permission decision, and recovery signal through another attempt.
What should the harness check before and after action?
For coding agents, a useful outer harness checks both sides of an action. Feedforward guides steer behavior before the agent acts. Feedback sensors observe what happened afterward and help the agent correct itself, especially when their signals are optimized for LLM consumption.
A simple coding-agent path can put a guide before the action and a legible sensor after it:
- The feedforward guide anticipates the behavior that needs steering before the agent changes code.
- The agent acts within the permitted function surface.
- A feedback sensor observes the result and returns a signal the model can use for correction.
This pairing serves two different control jobs. Feedforward raises the probability of a good first result. Feedback creates a self-correction loop before human review. Feedback without feedforward can repeat mistakes. Feedforward without feedback can encode rules without discovering whether they worked.
That balance matters more than adding instructions indefinitely. A guide can shape the attempt, but it cannot observe the result. A sensor can expose a problem, but it arrives after the action. The outer harness combines direction and observation so the coding agent has a controlled first attempt and a way to respond to what actually happened.
Feedback belongs after the function because its job is to observe. If the diagram has only a prompt entering the model, it does not show the post-action signal needed for self-correction. If it has only evaluation after the work, it does not show what steers the first attempt.
For a coding agent, the smallest useful pattern is therefore a guide, an allowed action, and a sensor whose result the model can consume. That outer pattern can raise the chance of a correct initial result and catch issues before a person reviews the work. It also keeps the source of correction visible: direction came before action, while observation came after it.
Our deeper treatment of the agent loop places this before-and-after pattern inside the full cycle of model decisions, functions, state, and feedback.
Early checks split into computational and inferential controls
Coding-agent checks fall into two practical groups. Computational controls include deterministic tests, linters, type checkers, and structural analysis. They run quickly and produce reliable results. Inferential controls include semantic analysis, AI code review, and evaluation by another language model. Those checks are slower, more expensive, and more non-deterministic.
The difference determines placement. Fast computational checks can run early and often. Moving checks earlier in the path to production makes the issues they detect cheaper to fix. A type error or failed deterministic test can return a direct signal while the agent still has the relevant working state.
Inferential checks address semantic questions that deterministic tools do not cover, but their cost and variability make them a different control surface. They should not replace the fast checks. The harness can use computational controls for quick, reliable feedback and reserve inferential controls for semantic analysis and review.
This is another reason to draw evaluation inside the architecture. If checks appear only after the agent has completed the whole path, the diagram hides when correction becomes possible. Placing early computational checks and later inferential checks on the execution path makes their different speed, cost, and determinism visible.
Tests, linters, type checkers, and structural analysis supply the early deterministic layer. Semantic analysis, AI code review, and evaluation by another language model supply an inferential layer. The first group is fast and reliable. The second can evaluate semantics, with the tradeoff of greater cost, slower execution, and more non-determinism.
When a computational check detects an issue early, the issue is cheaper to fix. That is a placement rule, not a reason to remove inferential review. The two groups answer different questions. A coding-agent harness can keep both visible without pretending that a slower inferential judgment has the same operating properties as a deterministic test.
Security boundaries span tools, memory, and external data
Permission at the function call is necessary, but the security surface is wider. Agent architecture risks include memory poisoning, semantic exploitation of legitimate APIs for tool misuse, and contamination of data used for retrieval-augmented generation. Each enters through a valid-looking system surface, so a tool allowlist alone does not cover the whole path.
Zero-trust principles should extend across tool access, memory systems, and validation of external data. Tool access needs a scoped permission boundary. Memory needs controls that account for poisoned state. External data needs validation before it becomes material the agent can retrieve and use.
Governance also needs a place in the diagram. Centralized governance policies can respond to new vulnerabilities faster than policies hardcoded separately into each agent. That does not remove controls from the execution path. It gives those controls a shared policy source that can change without revising every agent independently.
Operations with meaningful consequences need a deterministic boundary. Human approval is a practical control for reducing the risk of autonomous action, especially when it sits immediately before the consequential change. The approval decision should not be buried inside model reasoning. The application owns permission, and the human owns the high-impact authorization.
These boundaries keep authority legible. Tools, memory, and external data each have their own risk surface. Central policy governs the rules, deterministic application logic enforces permission, and approval adds accountability where the consequence warrants it.
The important split is between policy and execution. A centralized policy can change quickly when a new vulnerability appears. The application still makes the deterministic decision for the requested action, and a human can approve a high-impact operation at the final boundary. Keeping those responsibilities distinct prevents model reasoning from becoming the place where permission is granted.
Memory and external data also need explicit treatment because both can affect later model decisions. Zero-trust coverage extends to memory systems and validation of outside data, not just the tools an agent can call. That broader surface addresses the named risks of poisoned memory and contaminated retrieval data while scoped tool access addresses misuse through legitimate APIs.
When do you need more than one agent?
Use more than one agent when the work or the required isolation justifies the coordination burden.
| Situation | Architecture move | Decision basis | Required control or test |
|---|---|---|---|
| Well-defined sequential work | Start with one agent | Simpler governance and lower cost | Test the complete sequential path |
| Process-driven parallel work | Distribute work across specialized agents | Scalability, fault tolerance, and parallel execution | Define how specialized work is coordinated |
| Architecture choice remains unclear | Build comparative prototypes | Context handling, role separation, or performance may decide the shape | Compare against defined success metrics |
| Hard separation requirements | Use isolated agents with scoped access | Security, compliance, organizational separation, or guaranteed multi-domain scaling | Define explicit interface contracts |
Moving from one agent to many adds coordination complexity, with visible effects on performance, cost, and governance. If the benefit remains unclear, compare prototypes against defined metrics and include coordination cost in the decision. Hard separation requirements provide a firmer basis for isolated agents and explicit interfaces.
Multi-agent reliability depends on explicit coordination controls
Once work is distributed, reliable operation depends on explicit role boundaries, communication protocols, continuous monitoring, and built-in oversight. Those controls define who may do what, how work crosses an interface, and where the system observes the combined process.
Role boundaries make specialization explicit. Communication protocols give the distributed work a defined route. Continuous monitoring watches the combined process, while built-in oversight keeps a control point inside the deployment. Together, they supply the coordination structure that a single-agent loop does not need in the same form.
The engineering burden is especially clear in multi-agent research systems at scale. In that setting, reliability requires comprehensive testing, detailed prompt and tool design, robust operations, and collaboration among teams that understand current agent capabilities. The claim is specific to that demanding system class, but the control lesson is useful: topology does not supply coordination automatically.
For that system class, prompts and tools are only part of the reliability work. Comprehensive testing and robust operations remain necessary, and the teams involved need to understand current agent capabilities. The architecture therefore has to make operational ownership visible alongside agent roles and communication paths.
If you are deciding between one agent and several, compare that choice against the control map, then use our production architecture decision guide to test the shape against the work, boundaries, and recovery path you actually need.