What are the main components of an AI agent?

A model that decides the next step, instructions that define the job, tools that let it read and change things, memory for what it needs now and later, a loop that runs tools and feeds results back until a stop condition, and guardrails such as permissions and approvals. The source of its work and the record of what it did sit outside it.

What is agentic AI architecture?

It is how those components are arranged. The common shapes are a single agent with tools, a workflow where code sets the steps and the model fills some in, a manager agent that calls specialist agents as tools, and a decentralized design where agents hand work to one another.

Do I need a framework to build this architecture?

No. With one model and a few tools, the loop is a few dozen lines in any provider’s SDK. A framework helps once you need resumable runs, several agents, approval pauses that last hours, or tracing that others will read.

Where should guardrails go in an AI agent?

In several layers: in the permissions of the tools the agent holds, in approval steps before high-risk actions, in checks on inputs and outputs, and in a sandbox for anything that runs code. Instructions in the prompt help, but they are the weakest layer because a model can be talked out of them.

AI Agent Architecture: The Parts Every Agent Has

Every AI agent, from a sixty-line script to a coding assistant, is built from the same six parts: a model, instructions, tools, memory, a loop and guardrails. What each part does, the decision you make for it, how it fails, the common multi-agent patterns, and the two things that sit outside the agent.

September 30, 20268 min read

An AI agent has six parts. A model decides what to do next. Instructions tell it what the job is and how to behave. Tools let it read and change things outside itself. Memory holds what it needs to know now and what it should keep for later. A loop runs the model, executes the tool it asks for, feeds the result back and stops at a set condition. Guardrails decide what it may do without a person, and check what goes in and comes out. Two more things sit outside the agent and matter as much: where its work comes from, and where the record of what it did is kept. Every framework and product arranges these same parts; the design work is choosing what goes in each.

Which framework runs these parts for you is compared in AI agent frameworks, and why the same model behaves differently depending on everything around it is in what is an AI agent harness. This page is the parts list.

The architecture on one page

        task in (from a person, a board, a schedule)
                          |
                          v
  +--------------------------------------------------+
  | instructions  ->  MODEL  <-  memory / context    |
  |                     |                            |
  |          asks for a tool call                    |
  |                     v                            |
  |   guardrails: allowed? needs approval? safe?     |
  |                     |                            |
  |                   TOOLS  --> real systems        |
  |                     |                            |
  |          result goes back to the model           |
  |        (the LOOP, until a stop condition)        |
  +--------------------------------------------------+
                          |
                          v
        report out (the record people read)

Where the parts list comes from

The vendors describe the same shape in different words. Anthropic’s guide to building effective agents (opens in a new tab) starts from an “augmented LLM”, a model enhanced with retrieval, tools and memory, and describes agents as “typically just LLMs using tools based on environmental feedback in a loop”. OpenAI’s practical guide to building agents (opens in a new tab) names three core components, model, tools and instructions, and treats the run loop and guardrails as the parts around them. Put together, you get the six below.

The six parts

1. The model

The model reads everything in its context and chooses the next step: answer, or call a tool with these inputs. The decision you make is which model for which step. A strong model for planning and a smaller, faster one for routine steps is a common split. How it fails: it picks the wrong tool, invents an input, or reports success too early. Every other part exists partly to catch these.

2. Instructions

The system prompt and any standing files the agent reads at the start: the job, the rules, the tone, what done looks like, and when to stop and ask. OpenAI’s guide suggests building them from the procedures and policy documents you already have, broken into small, explicit steps. How it fails: vague goals produce confident wandering, and long instructions get ignored in the middle. What to put in them is in AI agent instructions.

3. Tools

A tool is a function the model can ask the loop to run, with a name, a description and an input schema. OpenAI’s guide sorts them into three kinds: data tools that fetch context, action tools that change records or send messages, and orchestration tools, where another agent is itself the tool. MCP is the common way to plug tools in from outside; the glossary has the one-paragraph version. The decision: as few tools as the job needs, with plain descriptions, and read tools kept separate from write tools so they can be treated differently. How it fails: overlapping tools, vague descriptions and error messages that do not say what to try next. See MCP tool descriptions.

4. Memory

Short-term memory is the context window: the instructions, the conversation and every tool result so far. Long-term memory is whatever survives the session, such as files the agent reads at start-up, a searchable store, or records in another system. The decision is what goes in the window now, what is fetched only when needed, and what is written down for next time. How it fails: the window fills with old tool output, or the next session starts knowing nothing. The kinds are compared in what is agent memory, and choosing what goes in the window is context engineering.

5. The loop

The loop is the engine: call the model, run the tool it chose, append the result, repeat. The pattern of interleaving reasoning with actions was named in the ReAct paper (opens in a new tab) in 2022, and every framework now runs some version of it. The decision is the stop condition. OpenAI’s guide lists the common ones: a final answer or structured output, an error, or a maximum number of turns. Add a spending cap where your SDK has one. How it fails: an agent with no hard stop loops on a problem it cannot solve. Each step of the loop, and where it breaks, is in the steps an AI agent takes to complete a task.

6. Guardrails

Guardrails are everything that limits and checks the agent. OpenAI’s guide calls them a layered defense: no single one is enough, so you combine several.

Permissions: which tools the agent holds at all, and with what access. The strongest guardrail is a tool the agent was never given.
Approvals: a person confirms high-risk actions before they run. OpenAI’s guide suggests rating each tool low, medium or high by whether it writes, whether it can be undone, what access it needs and its financial impact. The MCP tools specification (opens in a new tab) says there should always be a human in the loop able to deny tool invocations.
Input checks: relevance and safety classifiers, and simple rules such as length limits and blocklists, before the model sees a request.
Output checks: filters for personal data and content, and validation of what the agent is about to send.
Containment: running tools that execute code in a sandbox, away from real credentials.

How it fails: guardrails that live only in the prompt. A model can be talked out of an instruction; it cannot use a tool it does not have. The risks guardrails exist for are cataloged in the OWASP Top 10 for Agentic Applications (opens in a new tab), from ASI01 Agent Goal Hijack to ASI10 Rogue Agents; the controls for each are in OWASP AI agent security.

Single agent, workflow, or several agents

The same parts can be arranged in a few standard shapes. Anthropic separates workflows, where your code sets the path and the model fills in steps, from agents, where the model directs its own process. OpenAI recommends getting the most out of a single agent before adding more, and describes two multi-agent shapes when you do.

Single agent: one model, one loop, a handful of tools. Start here; most jobs never need more.
Workflow: fixed steps such as a chain or a router, with the model inside some of them. Best when you already know the path. See agentic workflows.
Manager: a central agent calls specialist agents as tools and combines their results.
Decentralized: agents hand the whole job to one another, each taking over the conversation.

More agents mean more places for context to be lost at a handoff. How to split one job between several is in multi-agent workflows.

One agent, mapped to the parts

Take the bug-triage agent built in how to build an AI agent, which reads an error log and files a bug for each new problem.

Model: whichever Claude model the Claude Agent SDK is set to, for the whole run.
Instructions: the prompt, which says what done looks like and ends with “list what you filed and what you skipped”.
Tools: two read tools (read the log, search tasks) and one write tool (file a bug).
Memory: the context window only; the task list is the long-term record.
Loop: the SDK’s loop, stopped at twenty turns.
Guardrails: built-in tools switched off, read tools pre-approved, every write sent to a person for yes or no.

Architecture best practices

Start with one agent and the fewest tools that do the job. Add parts only when a test shows the simpler version failing.
Split read tools from write tools, and approve writes by default.
Give every loop a hard stop, in turns and in spend.
Put limits in permissions and code, not only in the prompt.
Give each agent its own credential, so its actions are distinguishable and it can be revoked alone.
Keep the work and its record outside the agent, where people can read them.
Test with fixed cases after every change to instructions, tools or model; see how to evaluate AI agents.

Outside the agent: the work and the record

The diagram starts and ends outside the box. Something hands the agent its job, and something keeps what it did after the session is gone. A board can do both. fenbs is an MCP server at https://fenbs.ai/api/mcp: an agent reads the standing rules and notes with fenbs_get_context, takes a pre-approved task with fenbs_next_approved_task, and reports with a comment, a test status and a move to Completed. Each change is recorded in History under the assistant’s name, and its access comes from the role of the person who connected it, narrowed by the scopes they ticked. That makes the board part of the guardrails too: an agent cannot move a task its role does not allow. What fenbs is not: a runtime. It does not run the loop, hold the model or sandbox tools.

New to agents: AI agents for beginners. Build the smallest version: how to build an AI agent. Watch it run: AI agent observability. Connect a board as a tool: the MCP docs.