AI Agent Architecture: The 4 Components, How Each Fails, and How to Test It

AI agent architecture is the set of parts around a language model that let it take a goal, decide what to do, act on other systems, and pick up where it left off. A production agent needs four components: perception, reasoning, action, and memory. Each one fails in a different way, and each needs its own test.

I keep the classic four-part split because it still holds, once each part is redefined for language models. Below: how each component fails, how to catch it early, and a reference table to test your design against.

What is AI agent architecture, according to the model vendors?

The vendor guides do not use these four words. They describe the same parts with different labels.

Anthropic’s Building effective agents calls the basic building block “an LLM enhanced with augmentations such as retrieval, tools, and memory.” It defines agents as systems where “LLMs dynamically direct their own processes and tool usage,” and separates them from workflows, which run on predefined code paths. OpenAI’s practical guide to building agents (April 2025) names three core components: the model, tools, and instructions. Every run is “a loop that lets agents operate until an exit condition is reached.” Google’s Agent Development Kit adds the state side. A Session is “a single, ongoing interaction,” and Memory is a searchable store that can span “multiple past sessions.”

Here is how I map those terms onto the four components. The mapping is mine, not the vendors’.

Anthropic’s advice is to find “the simplest solution possible” and add complexity only when needed. My rule: if you can draw the steps as a flowchart, build a workflow and let the model make the judgment calls inside it. Use an agent loop only where the next step depends on what the last step returned.

Component 1: Perception decides what the model sees

In an LLM agent, perception is context assembly. On every step, something chooses which tokens go into the model: the user’s input, retrieved documents, earlier tool results, and conversation history. Cleaning raw input belongs here too, such as stripping email signatures and quoted threads.

Anthropic’s context engineering guide (September 2025) frames the goal as finding “the smallest set of high-signal tokens that maximize the likelihood of your desired outcome.” The mechanism is attention. Every token attends to every other token, which gives “n² pairwise relationships for n tokens,” so each added token spends part of a finite attention budget.

The failure mode is context rot. Chroma’s Context Rot report (July 2025) tested 18 models and found that “model performance varies significantly as input length changes, even on simple tasks.” It also found that “even a single distractor reduces performance relative to the baseline.” A distractor is text on the same topic that does not answer the question. That is exactly what a loose retriever returns.

Context rot is quiet. The agent still answers, just worse, and mostly on the long cases.

How to detect it. Log input tokens for every model call and plot success rate against input size. If accuracy drops in the top quartile of context length, you have it. How to test it. Take ten eval cases, add five retrieved chunks that are on topic but wrong, and compare the pass rate to the clean version. Trimming rules and token budgets live in the context engineering for AI agents guide.

Component 2: Reasoning is the model plus the loop around it

Reasoning is the model, its instructions, and the control loop that decides when to call the model again and when to stop. Anthropic describes agents as “LLMs using tools based on environmental feedback in a loop” and recommends “stopping conditions (such as a maximum number of iterations).” OpenAI lists the usual exit conditions: a tool call, a structured output, an error, or a maximum number of turns.

On model choice, OpenAI’s guide says to prototype with the most capable model “to establish a performance baseline,” then swap in smaller models where they still pass.

Two failure modes dominate. The first is a loop that ends wrong: it stops before the task is done, or it never stops. The MAST study annotated more than 1,600 traces from 7 multi-agent frameworks and grouped 14 failure modes into three categories: system design issues, inter-agent misalignment, and task verification. Watch the last one. It covers agents that end a task without checking the result.

The second is inconsistency. The τ-bench paper (June 2024) introduced pass^k, the chance that an agent succeeds on all k tries of the same task. Its gpt-4o agent succeeded on under 50% of tasks, with pass^8 under 25% in the retail domain. Those are 2024 models, but the metric still applies.

How to detect it. Track turns per run and the share of runs that hit the turn cap. How to test it. Run each eval case 8 times and report pass^8.

Split into multiple agents only after one agent fails. OpenAI’s guide says to “maximize a single agent’s capabilities first.” Anthropic’s multi-agent research system write-up shows the cost: multi-agent systems “use about 15× more tokens than chats.” The multi-agent systems post covers when the split pays.

Component 3: Action is tools, and the guard around each one

Action is every tool call that reads from or writes to another system. OpenAI sorts tools into three types: data tools that retrieve context, action tools that change things (send an email, update a CRM record), and orchestration tools, where other agents act as tools.

The architecture question is where the guard sits. OpenAI recommends rating each tool low, medium, or high risk “based on factors like read-only vs. write access, reversibility, required account permissions, and financial impact,” then using the rating to pause or escalate. The MCP tools spec, in the current 2026-07-28 revision, puts hard duties on servers: they MUST validate all tool inputs, implement access controls, rate limit tool invocations, and sanitize outputs. Clients SHOULD confirm sensitive operations, set timeouts, and log tool usage. Tool execution errors go back to the model with isError: true so it can “self-correct and retry with adjusted parameters.”

The failure mode is a legitimate tool used the wrong way. The OWASP Top 10 for Agentic Applications 2026 lists this as ASI02, Tool Misuse and Exploitation. The agent stays within its granted privileges but applies a tool unsafely, “for example deleting valuable data, over-invoking costly APIs, or exfiltrating information.” A permission check will not catch that, because no permission was broken.

How to detect it. Count tool calls per run by tool name and alert on outliers. Ten calls to a refund tool in one run is a signal, whatever the reason. How to test it. Build a tool-selection eval: a set of requests with the expected tool and arguments, scored on exact match. Schema habits, error wording, and idempotency keys are in AI agent tool design.

Component 4: Memory is two different stores

Memory gets treated as one thing. It is two, and they fail differently.

Run state is where the agent is in the current task: which steps finished, what each tool returned, what is waiting on a human. ADK calls this the session and its state, and warns that in-memory storage is “lost when your application restarts.” That is fine for development and wrong for production. Long-term memory is what survives across sessions: user preferences, past cases, saved notes. ADK keeps it in a separate MemoryService.

Run state fails on crashes. A durable runtime saves progress so a restart resumes instead of starting over. LangGraph’s checkpointer docs show the trade-off as three durability modes. With "exit", “intermediate state is not saved.” With "async", there is “a small risk” of a lost checkpoint if the process crashes. With "sync", LangGraph writes “every checkpoint before continuing execution.” Resume has a catch: “Nodes after the checkpoint re-execute, including any LLM calls, API requests, or interrupts.” Temporal warns that Activities “may be retried” and suggests the Workflow Run ID plus the Activity ID as an idempotency key.

Long-term memory fails on poisoning. OWASP’s ASI06, Memory and Context Poisoning, covers adversaries who “corrupt or seed this context with malicious or misleading data,” which then shapes later sessions. One listed mitigation is to stop the agent’s own outputs from being re-ingested into trusted memory automatically.

How to test both. Kill the worker mid-run and confirm the resume does not repeat a write. Then plant one false fact through a normal conversation and check whether a later session acts on it. Crash drills are in durable execution for AI agents. Retention and deletion are in AI agent memory and data retention.

The layer the four components leave out: tracing

The four components describe what the agent does. None of them tells you what it did. That takes a cross-cutting layer: traces that follow one run through all four.

The OpenTelemetry GenAI agent span conventions give each component a span. invoke_agent covers a run, plan covers “agent planning or task decomposition,” and execute_tool covers a tool call and requires the tool name. Spans carry token counts such as gen_ai.usage.input_tokens, which is the number the context-rot check needs.

Two cautions. The conventions are in Development status, so names can still change. And message content, tool arguments, and tool results are Opt-In attributes. Turn them on only where you need them, and treat them as customer data when you do.

Anthropic’s research team put it plainly: “Adding full production tracing let us diagnose why agents failed and fix issues systematically.” My recommendation is to emit these spans from the first pilot. For tool choices, see AI agent observability tools.

AI agent architecture reference table

Use this as a design review. Options are common choices, not endorsements. The tests are what I would require before production. The thresholds are mine, not from a standard.

Wire these tests into the release gate described in agent evals in CI.

A worked example: one refund, four places to break

Hypothetical: an agent handles refund requests by email. It reads the email, looks up the order, checks policy, issues the refund, and stores a note.

Perception breaks if retrieval pulls old policy versions next to the current one. Reasoning breaks if the agent calls the refund done without reading the payment status. Action breaks if the refund tool has no amount cap. Memory breaks in the crash case, which is worth putting numbers on.

Say the agent handles 2,000 refunds a month, and 0.5% of runs crash after the payment call but before the checkpoint. That is 10 runs. On resume, the payment step runs again. With no idempotency key, that is 10 duplicate refunds a month. At an average of $80, that is $800 a month. At a 1% crash rate, it is 20 duplicates and $1,600. The fix is one key per payment call.

The pass^k math matters too. If one try of a case succeeds 95% of the time and tries are independent, eight in a row succeed 0.95^8, or about 66%, of the time. At 99% per try, pass^8 is about 92%. Real tries are not fully independent, so treat these as rough.

Bottom Line

The four components still hold: perception, reasoning, action, and memory. What changed is what each means for an LLM agent, and that memory is really two stores.

Design each component around its failure mode: context rot, bad stops, tool misuse, repeated writes, and poisoned memory.

Add tracing before the first pilot user. Then run the reference table as a design review. Any row without a passing test is not ready for production.

FAQ

Do I need an agent framework to build this architecture?

No. Anthropic suggests developers “start by using LLM APIs directly,” and if they use a framework, “ensure you understand the underlying code.” Google’s ADK, for example, added graph workflows in version 2.0, can resume stopped runs, and has SDKs for Python, TypeScript, Go, Java, and Kotlin. The framework selection guide has a two-day spike to decide.

How many tools can one agent handle?

There is no fixed number. OpenAI’s guide says “some implementations successfully manage more than 15 well-defined, distinct tools while others struggle with fewer than 10 overlapping tools.” Anthropic’s test: if a human engineer cannot say which tool fits a situation, the agent will not do better.

Where does RAG fit in the four components?

It depends on who decides to retrieve. If your code retrieves before the model call, retrieval is part of perception. If the model calls a search tool when it decides it needs facts, retrieval is a data tool in the action component. Anthropic calls the second approach “just in time” retrieval, where the agent keeps “lightweight identifiers” such as file paths and loads data at runtime.

Does MCP change AI agent architecture?

MCP standardizes part of the action component: how an agent discovers and calls tools on other servers. In the 2026-07-28 revision, MCP has no protocol-level session. A server that needs state across calls returns an explicit handle, such as a basket ID, that the model passes back on later calls.

Is the OpenTelemetry GenAI convention stable enough to adopt now?

Not stable, but usable. Every agent span is marked Development, and the GenAI conventions moved out of the main semantic-conventions repository into a dedicated one in June 2026 (v1.42.0). I would adopt it and pin the version your instrumentation library emits, so a rename does not quietly break dashboards.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect