Tools
External services
Web retrieval
Run scripts
An AI agent is a system that plans multi-step tasks, calls external tools or APIs, and adjusts its actions based on results — without a human directing each step. Here's how that loop is actually built, and when it's the wrong tool for the job.
Tech Reforms
AI AGENT ARCHITECTURE
Tools
External services
Web retrieval
Run scripts
Planner
Analyze Q4 sales → identify growth opportunities
Executor
Memory
Session context
History & prefs
Domain rules
Output
Q4 Sales Analysis Report · PDF








AI agent architecture is the system design that lets a large language model go beyond answering a single question — planning a sequence of steps, calling tools or APIs to gather information or take action, evaluating the result, and deciding what to do next, in a loop, until the task is complete or it needs human input.
This distinguishes an agent from a standard LLM integration. A chatbot answers one prompt at a time. An agent decomposes a goal — "resolve this support ticket," "reconcile this invoice" — into steps, executes tools autonomously, and handles the branching that comes from real-world results not going as expected.
Agent architecture sits downstream of the integration patterns covered in our LLM Integration Guide — an agent typically combines prompt engineering, tool calling, and often a RAG layer for grounded, up-to-date context.
Every production agent, regardless of framework, runs some version of this four-step cycle. It repeats until the goal is met or a stopping condition is hit.
01 PERCEIVE
Take in the task, current state, and any retrieved context (docs, past steps, tool outputs) as input.
02 PLAN
Model reasons about what action or sequence will advance the goal — which tool to call, or whether to think.
03 ACT
Execute the chosen action — a software API call, a code execution, a search.
04 OBSERVE
Read the tool's output, check if it advances the goal, and feed it back into the next Perceive step.
The loop repeats — Observe feeds back into Perceive — until the goal is met, a stop limit is hit, or the agent escalates to a human.
Breaks the goal into an ordered or dynamic sequence of steps.
Typical Implementation
LLM reasoning step, often ReAct or a structured planning prompt.
Defines what actions the agent can take in the real world.
Typical Implementation
Function/tool calling — APIs, database queries, code execution.
Tracks what's already happened in this run, and across runs.
Typical Implementation
Short-term: conversation/step history. Long-term: vector store.
Coordinates multiple agents or sub-tasks in complex workflows.
Typical Implementation
Controller pattern routing tasks to specialized sub-agents.
Constrains what the agent is allowed to do without approval.
Typical Implementation
Permission scopes, human-in-the-loop checkpoints, step limits.
Most production systems start single-agent and only move to multi-agent when a real coordination problem shows up — not by default.
One agent runs the full loop with access to all relevant tools. Simpler to build, debug, and reason about failures.
Best for: bounded tasks with a clear tool set — ticket resolution, data lookups, report generation.
Failure mode: tool sprawl — too many tools available degrades planning accuracy.
Typical cost: $15K–$25K
An orchestrator agent breaks the goal into sub-tasks and routes them to specialized worker agents, each with a narrower tool set.
Best for: complex workflows spanning distinct domains — research + drafting + review.
Failure mode: coordination overhead — orchestrator errors compound across workers.
Typical cost: $30K–$50K
Even the best AI agents can hit dead ends. Production agents have design mechanisms that carry them forward.
On a failed tool call or unexpected result, the agent reflects on what went wrong, revises its plan, and tries a slightly different approach.
Hard caps on step count and token spend prevent runaway loops. When a limit is hit, the agent stops and escalates rather than burning budget.
Low-confidence decisions and irreversible actions pause for human approval — keeping the agent useful without giving it unchecked authority.
The path to completion depends on what happens at each step - you can't hardcode the sequence in advance.
If the same steps run in the same order every time, a deterministic script or standard automation is cheaper, faster, and easier to debug than an agent.
The task requires querying live systems, calling APIs, or taking actions - not just generating text from context.
If the task is "answer this from our docs," that's RAG, not an agent. Adding agent overhead here is unnecessary cost and failure surface.



