What are the 5 parts of an AI agent?

An AI agent has a reasoning model that interprets the task and chooses actions, memory that carries context within and across runs, tools that read from and write to external systems, a planning step that decomposes a goal into ordered subtasks, and a control loop that decides whether to act again, escalate, or stop. Remove any one and a specific, predictable failure appears.

What are the 5 types of agent in AI?

This question usually refers to the classical AI taxonomy, which predates LLM agents: simple reflex, model-based reflex, goal-based, utility-based, and learning agents. That taxonomy sorts agents by how much internal world model they keep. Modern agent architecture is usually sorted differently, by what is inside one agent and how several agents coordinate.

Is ChatGPT an agent or an LLM?

A model is a component. An agent is a system built around one that plans, calls tools, and acts on external systems. ChatGPT ships as both, depending on the mode: the underlying model on its own is an LLM, and the product features that browse, run code, and call connectors make it an agent wrapped around that model.

What is the difference between single-agent and multi-agent architecture?

A single agent reasons and picks from its own tools. Multi-agent architecture splits the work across specialised agents that coordinate through patterns like sequential, handoff, or group chat. Microsoft calls one agent with tools "often the right default for enterprise use cases." Multi-agent adds coordination overhead, latency, and new failure modes you then have to debug.

Should every step of an agent workflow run through the model?

No. Steps that need judgment every time belong in the model. Steps whose sequence you already know should run as code the agent calls, because code behaves the same on every run, holds its own state and logs, and costs nothing in tokens. The proportion should shift toward code as the system learns the work.

AI Agent Architecture: Components, Patterns, and the App Layer

Most agent architecture diagrams show components that reason on every single run. That is one layer, not the whole picture. The missing one is where work stops being reasoning and becomes software the agent calls instead.

Rahul RamakrishnanSeptember 8, 2026Updated October 22, 2026

Engineer drawing a system architecture diagram on a whiteboard

AI agent architecture is the arrangement of five parts: a model that reasons, a planning step that breaks a goal into subtasks, memory that carries state, tools that act on external systems, and a control loop that decides whether to act again, escalate, or stop. Teams then coordinate several agents with patterns such as sequential, concurrent, group chat, handoff, and magentic. Most diagrams stop there. The layer they leave out is the one that decides your cost and your audit trail: the boundary where repeatable work leaves the model and runs as deterministic code the agent calls.

Major is built around that third layer. On Major, an agent that works out a repeatable step builds an app for it, then runs the app instead of reasoning through the step again. This article covers the two layers everyone draws, then makes the case for the one they skip.

What are the parts of an AI agent?

Each part is easiest to understand by what breaks without it.

Reasoning model. Interprets the task and picks the next action. Without it you have a fixed script that fails on any input nobody anticipated.
Planning. Decomposes a goal into ordered subtasks. Without it the agent acts one step at a time and thrashes on tasks with several dependent steps.
Memory. Carries results and context across steps and sessions. Without it every run starts cold and the agent contradicts its own earlier answers.
Tools. Read from and write to APIs, databases, and file systems. Without them the agent can describe an action but cannot take one.
Control loop. Decides when to continue, escalate, or stop. Without it you get endless tool-call loops or premature stops that leave work half done.

Look at where each part keeps its state. The model's reasoning is discarded after each call. The plan and the critique live in the prompt. Short-term memory lives in the context window. Google Cloud's guidance is blunt about the consequence: with in-memory storage, session state is not persistent, and an application restart loses all conversation history. State that lives in a context window is expensive to refill and gone when the run ends.

How do agents coordinate in multi-agent systems?

Microsoft's Azure Architecture Center publishes the strongest primary reference on this layer, its guide to AI agent orchestration patterns. Use its vocabulary.

Sequential. A linear pipeline where each agent processes the previous agent's output. Good for multistage work with clear dependencies.
Concurrent. Fan-out and fan-in, with agents working independently on the same input. Good for independent perspectives and latency-sensitive work.
Group chat. Agents contribute to one accumulating thread under a chat manager. Good for review and maker-checker loops.
Handoff. One agent holds control and transfers it when it hits its limit. Good when the right specialist only becomes clear mid-task.
Magentic. A manager agent builds and revises a task ledger, then delegates against it. Good for open-ended problems with no known path.

The most useful part of that page is the complexity ladder before the patterns. A direct model call comes first, because "if prompt engineering can solve the problem, you don't need an agent." A single agent with tools is, in Microsoft's words, "often the right default for enterprise use cases." Multiagent orchestration "adds coordination overhead, latency, and failure modes."

That advice is correct and widely ignored. Teams reach for five specialized agents on a problem one agent with six tools would handle, then spend a quarter debugging handoffs. Start on the lowest rung that works.

The layer most architectures leave out: the app layer

The ladder starts one rung too high. Plain deterministic software, a function that does the job without asking a model, is not on it.

Microsoft's own sequential pattern shows the assumption. It says the pattern resembles Pipes and Filters, "but it uses AI agents instead of custom-coded processing components." Custom code is treated as the old thing that agents replace. We think good agent architecture runs the other direction. A stage that reformats a payment file, checks it against contract terms, and writes the result to a ledger should stop being an agent and become code. Swapping code for an agent buys variance, token cost, and an audit trail you reconstruct from a prompt.

Microsoft's antipattern list warns against "using nondeterministic patterns for workflows that are inherently deterministic." The word doing the work is inherently. Most workflows are not born deterministic. They start as judgment, and by the tenth time you handle one, you know the steps. A build-time rule like "if you can draw the decision tree on a whiteboard, don't use an agent" is sound advice, but it is a one-time fork. What is missing is a lifecycle where work begins as reasoning, gets figured out, and becomes software.

The app layer is durable software that handles the parts of a task the system has already worked out. It holds its own data in a managed database, keeps its own logs, and is called by the agent rather than reasoned through by it. Three properties follow.

Determinism. The step behaves the same on run 500 as on run 1, and you can test it with exact-match assertions instead of scoring rubrics.
Statefulness. The app holds the state a context window used to carry, so work persists and resumes after an interruption.
Governability. The action is code running under scoped credentials, so it can be inspected, attributed, and controlled.

Microsoft's testing guidance says agent outputs are nondeterministic, so use scoring rubrics or model-as-judge evaluation instead of exact-match assertions. For the reasoning layer, that is true. As a settlement for the whole system, it gives up too early. A system six months old should grade a smaller share of each run by rubric than it did on day one.

How to build this on Major

Take a hybrid workflow: a renewal-risk review that crosses Salesforce, Postgres, and Slack, with judgment somewhere in the middle.

Connectors. The agent reaches Salesforce, your Postgres database, and Slack through Major's connectors. It never holds raw keys; credentials are scoped per connector and injected at the point of the call.
The app that holds state. The agent builds a renewals app with tables for accounts, risk signals, and review history. Pulling the pipeline, joining usage data, and scoring against known rules run as code inside that app.
The judgment the agent keeps. Whether a quiet account is a risk or a seasonal lull, and how to word the outreach, stay with the model. That is the part that needs reasoning every time.
The trigger. A Major workflow runs the app on a schedule or on a Salesforce event, and routes high-risk cases to an owner in Slack for approval.
Governance. Role-based access decides who can run or edit the app. Every call is logged, so you can answer what the agent did in March: which tools it had, what it decided, what side effects landed, and under whose credentials.

Reason once, run forever. The first run is the expensive one. Later runs call the app, and the model spends tokens only on the judgment calls. Start building free to try it on a workflow you already run.

Which steps belong in the model, and which in the app?

Sort each step of a workflow by how often it needs judgment.

Judgment every time. Keep it in the model. Ambiguous customer intent and novel exceptions live here. Grade with rubrics and accept the variance.
Judgment sometimes. Keep it in the model with a deterministic fast path. Known cases run as code and the rest escalate. Most classification and routing sits here.
Never judgment, steps known. Move it to the app layer.

Revisit the sort quarterly, because steps migrate from the first bucket to the third as the system learns the work.

What this does not solve

The model still does real work. It reasons about judgment calls, and it writes the apps in the first place. Genuinely novel judgment stays in the model permanently, and a system that tries to compile away judgment produces confident wrong answers on exactly the cases that matter.

The app layer also has a cost. Code an agent wrote needs versioning, tests, an owner, and a retirement path when the process changes. You trade token cost and variance for maintenance surface. For work that runs a thousand times, that trade is clearly right. For work that runs twice, it is clearly wrong. Major keeps the apps in one governed place so the maintenance has an owner, and it does not remove the need for one.

Start building on Major

Draw the third layer first for any system you will have to operate. Describe a workflow your team already runs, and Major's agents build the deterministic app for the repeatable steps, with state, permissions, and audit built in.

Frequently asked questions

What are the 5 parts of an AI agent?: An AI agent has a reasoning model that interprets the task and chooses actions, memory that carries context within and across runs, tools that read from and write to external systems, a planning step that decomposes a goal into ordered subtasks, and a control loop that decides whether to act again, escalate, or stop. Remove any one and a specific, predictable failure appears.
What are the 5 types of agent in AI?: This question usually refers to the classical AI taxonomy, which predates LLM agents: simple reflex, model-based reflex, goal-based, utility-based, and learning agents. That taxonomy sorts agents by how much internal world model they keep. Modern agent architecture is usually sorted differently, by what is inside one agent and how several agents coordinate.
Is ChatGPT an agent or an LLM?: A model is a component. An agent is a system built around one that plans, calls tools, and acts on external systems. ChatGPT ships as both, depending on the mode: the underlying model on its own is an LLM, and the product features that browse, run code, and call connectors make it an agent wrapped around that model.
What is the difference between single-agent and multi-agent architecture?: A single agent reasons and picks from its own tools. Multi-agent architecture splits the work across specialised agents that coordinate through patterns like sequential, handoff, or group chat. Microsoft calls one agent with tools "often the right default for enterprise use cases." Multi-agent adds coordination overhead, latency, and new failure modes you then have to debug.
Should every step of an agent workflow run through the model?: No. Steps that need judgment every time belong in the model. Steps whose sequence you already know should run as code the agent calls, because code behaves the same on every run, holds its own state and logs, and costs nothing in tokens. The proportion should shift toward code as the system learns the work.