Step by step AI agent architecture: build from recovery backward

Key takeaways

• An agent is a model inside a harness of tools, memory, execution, and guardrails.
• Keep the design simple until evaluation shows that more steps are needed.
• Persist completed execution boundaries so a crash does not repeat external actions.

A useful step by step AI agent architecture starts with failure. Before choosing more models or drawing more boxes, decide what the system may change, what must survive a crash, and how an interrupted run will resume. That turns an AI agent architecture diagram into an operating design instead of a component inventory.

What belongs in a step by step AI agent architecture?

An agent harness connects model reasoning to tools, memory, execution environments, and guardrails. Use this recovery-backward matrix to turn those parts into an operating design:

For a broader view of topology choices, compare the patterns in our guide to AI agent architectures. The build sequence here is about making any chosen topology operable after interruption.

Turn the goal into instructions and explicit tools

Start by writing an instruction contract, not a personality sketch. Define the agent's role, goal, audience, tone, knowledge sources, workflow, boundaries, escalation rules, and output format. Those fields give the model a clear job and make its behavior easier to inspect. Planning steps should remain visible, while the tool interface needs thorough documentation and testing.

Then turn every business action into an explicit tool. A tool should accept typed inputs and return predictable outputs. The model can choose the tool and propose its parameters, but the tool contract determines what the execution layer can accept. That boundary is much easier to test than an open-ended instruction to "handle" an external system.

For example, the instruction contract can require a defined source set, a fixed workflow, an escalation condition, and a specified result shape. The matching tool contract can reject inputs outside its type definition and return a predictable result for the harness to record. The model remains responsible for the decision. The harness remains responsible for execution and enforcement.

Keep tool visibility separate from approval. Visibility defines which tools the agent can see. Approval defines which selected actions must wait for human review. This separation lets you expose a useful read operation without automatically granting every write operation beside it. Explicit business tools with typed inputs and predictable outputs make that authority visible in code and tests.

Constrain context, network access, and external data

More context is not automatically better context. Treat context as a finite resource and select the smallest high-signal set that is likely to support the desired result. That constraint also makes it clearer which knowledge influenced a decision.

The threat surface goes beyond a malicious user prompt. Agent architectures can face prompt injection, memory poisoning, semantic misuse of legitimate tool interfaces, and contamination through retrieved material. Apply zero-trust controls to tool access, memory systems, and external-data validation. A model-generated request or a retrieved passage does not gain authority merely because it arrived inside the harness.

Those threats reach different parts of the system. Prompt injection arrives through instructions or data. Memory poisoning can persist bad context. Semantic misuse can call a legitimate interface for the wrong purpose, while retrieval contamination can carry harmful material into the working context. Zero-trust controls across tools, memory, and external data give each surface an explicit validation point.

Network access deserves its own boundary. Combining powerful skills with open networking creates a high-risk path for data exfiltration. When a task requires networking, use a minimal allowlist for narrowly scoped requests and treat every tool result as untrusted data. The allowlist answers where the agent may connect. Validation answers what the system may do with the response.

These controls should be visible in the architecture, not hidden inside a general security box. Tool access, memory access, network reach, and external-data validation are separate surfaces with separate authority.

Memory is not a recovery record

A saved conversation can preserve what the model saw and said. It cannot prove which external actions ran, which approvals occurred, or whether another attempt would duplicate a side effect. Session memory is therefore not durable execution.

A durable system needs an execution journal. The journal records completed actions and approvals, while versioned prompts and tools identify the logic that governed each step. Idempotent tool boundaries make repetition safe where possible. Durable approvals and deliberate recovery tests preserve the control path across interruption.

Prompt and tool versions matter when a run spans a change. The journal should identify the versions attached to the completed work, so recovery does not silently treat a new prompt or tool definition as the one that produced the old state. The same record keeps an approval attached to the action it authorized after the runtime resumes.

The checkpointing boundary should match the safe rerun boundary. A recovery point objective defines how far back the pipeline can rerun without crossing an unsafe point. In practice, the journal must contain enough operational state to resume from that point without guessing from chat history. Durable execution persists completed boundaries so recovery does not repeat tool calls, external mutations, approvals, or outbound messages.

What should happen when a tool call fails?

Do not put every tool error through one retry loop. Recovery depends on what the operation was doing and what is known about its result. Workflow policy, authorization, and business rules retain control over recovery. The agent's judgment alone is not enough.

• Temporary network timeout: A retry may be appropriate. If the request could have been processed before the timeout, reconcile through its operation identifier or status endpoint before another attempt.
• Permission failure: Stop the workflow. Repeating the same call does not change the missing authority.
• Unknown side-effect result: Reconcile before choosing another action. The absence of a response does not establish whether the external change happened.
• Completed non-idempotent operation: Use the defined compensation action. A completed business operation may need compensation instead of rollback.
• High-risk failure: Bring in a human when the failure requires intervention. The human needs the context and authority to decide what happens next.

This recovery split matters because a transport signal can look healthy while the workflow duplicates an external action or continues a budget-consuming reasoning loop. Observe workflow state and side effects directly. A successful response is not a substitute for knowing which business operation completed.

Long-running recovery must inspect workflow state and side effects. If the external system reports an operation identifier, that identifier becomes the route to reconciliation after an uncertain result. The workflow can query status before it decides whether another call is a retry or an accidental duplicate.

The recovery branch should therefore return a controlled state: retry, stop, reconcile, compensate, or wait for human intervention. Each state should follow the semantics of the failed operation. That gives the harness a bounded response when the tool result is incomplete or ambiguous.

Make every retry replay-safe

A safe retry starts before the first call. Separate the model's nondeterministic decision phase from the deterministic execution phase. The first phase selects a tool and its parameters. The second validates those parameters, performs the external action, and records the result. Recovery can then inspect a specific execution record instead of asking the model to make the decision again.

Write operations need idempotency keys and must not be retried naively. The key lets the execution boundary identify a repeated request. Any step that may run again must either produce the same result when repeated or be safe to overwrite. If an action cannot meet that condition, define its compensation action before granting the agent access to it.

Before any replay, check the recorded operation against workflow policy, authorization, and business rules. Then follow one controlled path: repeat a safe operation, reconcile an uncertain result, or compensate a completed non-idempotent action. A fresh model proposal does not replace that check.

Recording sits inside this mechanism, not after it. Persist the execution result at the completed boundary, then let the workflow decide whether another attempt is safe. An unknown result goes to reconciliation. A known completed result is not executed again. A completed non-idempotent result follows its compensation path when reversal is required.

Approval gates and guardrails do different work

Guardrails inspect requests and outputs. Approval gates pause selected side effects before execution. Lifecycle callbacks capture logging, tracing, and audit events around the work. These controls can appear in the same harness, but they answer different questions.

Place guardrails across input filtering, tool use, and human intervention. Then choose approval points according to the action's consequence. Human checkpoints belong where an action is highly irreversible, model confidence is low, a result will become externally visible, or required context is missing.

An approval pause should preserve the proposed action and the context required to judge it. The person can then allow, reject, or intervene before the side effect runs. Human checkpoints belong at consequential boundaries, not as a substitute for routine guardrails on every request and output.

For high-risk actions, trained humans retain decision authority. They need timely context, the power to intervene, and a defensible rationale for the decision. The approval record must also be durable. Otherwise a resumed run cannot establish that the action was authorized.

Logging does not replace either control. It records what happened. A guardrail can reject a request or output, while an approval can prevent a risky side effect from running until a person decides.

How do you know the agent is ready to expand?

Expansion should wait for useful evaluation signal. Start the evaluation suite before it is perfect, then build tasks from failures you have actually observed. Each task needs an unambiguous success criterion and thoughtfully designed graders. Iterate on both the task and the graders when their signal is noisy.

Starting early matters because the first suite does not need to settle every possible behavior. It needs to turn a real failure into a repeatable task with a result you can judge. Later iterations improve the signal instead of postponing evaluation until the system has already grown.

Use a failed task as the unit of work. Describe the observed failure, write the exact condition that would count as success, and assign graders to the parts they can judge. Compare their judgments with the unambiguous criterion. If those judgments disagree or reward the wrong behavior, revise the grader design and run the task again. This follows the practical guidance to derive evaluations from observed failures and improve their signal-to-noise ratio over time.

The gate is not a perfect score. It is a useful evaluation that can distinguish the behavior you will accept from the failure that prompted the test. Broader capability comes after that signal exists.

When should one agent become many?

Keep one agent when the work remains one bounded task. Move to multiple agents when the work separates into genuinely distinct subtasks that require different tools or models. That is an orchestration requirement, not a claim that more agents are inherently better.

A single system can combine reasoning-and-action loops, multiple agents, and different degrees of autonomy according to the task. Start small, validate the system with real users, and expand its capabilities over time. The architecture can grow without treating every added capability as a new agent.

Multiple agents also add a specific failure mode. An incorrect output from one agent can become trusted input for every downstream agent that consumes it. Each handoff therefore creates another place to validate output, preserve state, and reconcile failure. If the work does not gain from separate tools, models, or subtasks, those coordination boundaries have no established reason to exist.

That risk makes the decomposition test concrete. Use multiple agents for genuinely separate subtasks that need different tools or models. Keep one bounded agent when the proposed split only moves the same context through more handoffs.

The bounded single-agent design remains the default until the decomposition is concrete. If you do split the work, assign each agent a distinct subtask and keep the authority of every tool boundary explicit.

Control cost per run before adding autonomy

Autonomy needs a budget boundary as well as a permission boundary. Per-run cost includes model input and output tokens, human-review time adjusted by the escalation rate, and infrastructure such as database reads, external API calls, and compute.

Write that as an operating formula:

run cost = model tokens + adjusted human-review time + infrastructure

Set a hard ceiling for the complete run. A circuit breaker aborts the run when the ceiling is exceeded. That stop condition prevents an agent from continuing a budget-consuming loop merely because individual requests still return successful transport signals.

Keep the three terms visible in run records. Token use shows the model portion. Escalation-adjusted review time shows the human portion. Database reads, API calls, and compute show the infrastructure portion. The ceiling applies to their combined run cost, so the circuit breaker has one enforceable stop condition.

Apply the recovery-backward matrix to your current design. Mark the first row where authority, failure behavior, or the completion test is still unclear, and fix that boundary before widening the system's reach. Then trace the execution cycle through our guide to the agent loop and check where each decision, tool call, observation, and stop condition belongs.