The agent loop describes the repeating cycle a single agent runs through. Agent architecture is the surrounding system that makes that loop safe, observable, and bounded in production — the runtime, tool registry, memory store, and guardrails that sit around the loop itself.

Planner

Breaks the goal into steps, upfront or dynamically — see the Planning lesson for the tradeoffs between the two.

Memory

Retains relevant information across steps or sessions — could be as simple as the current run's state, or persistent across sessions.

Tool registry and executor

Defines which tools exist, validates a requested call against its schema, executes it, and returns the result — see the Tool Use lesson for how the agent selects among them.

Guardrails

Enforces boundaries independent of the model's own decisions — which tools are allowed, what arguments are valid, what actions need human approval.

Evaluator

Assesses whether the agent is making progress or should stop, escalate, or retry — related to Reflection, but implemented as part of the surrounding system rather than left entirely to the model.

An agent loop without limits can run far longer than intended, repeat unproductive actions, or take an action nobody actually wants executed. Production agent architecture bounds execution explicitly:

• Maximum steps — a hard ceiling on how many loop iterations a single run can take.
• Tool allowlists and scoped permissions — an agent should only have access to the tools its task actually requires, following least privilege.
• Human-in-the-loop checkpoints — required approval before irreversible or high-stakes actions, as covered in its own lesson.
• Timeouts — both per tool call and for the run as a whole, so a stuck agent doesn't run indefinitely.

• Runaway loop — no step limit means a confused agent keeps going indefinitely, accumulating cost.
• Tool failure — a tool call errors or times out; the agent needs a defined path to recognize and recover, not silently continue on bad data.
• Prompt injection via tool results — content returned from a tool (a web page, a document) can attempt to redirect the agent; this is the same trust-boundary problem covered in the Prompt Injection lesson, now inside the agent loop itself.
• Excessive permissions — an agent with broad, unnecessary tool access turns any single mistake or injection into a much bigger problem.
• Silent failure — an agent that fails to make progress but reports success gives false confidence unless the evaluator or observability catches it.

A single, well-scoped agent is usually simpler to build, debug, and secure. Multi-agent orchestration — covered in the Agent Orchestration lesson — is worth the added coordination cost once a task genuinely spans multiple distinct specialties that don't fit well in one agent's toolset and instructions.

• No maximum step limit

  A stuck or confused agent can loop far longer than intended without a hard ceiling.

• Granting broad tool access by default

  An agent should have only the tools its specific task requires — not every tool the system happens to expose.

• Treating tool results as trusted by default

  Content returned from a tool can contain injected instructions and should be treated with the same caution as any other untrusted input.

• No human checkpoint for irreversible actions

  Sending messages, spending money, or deleting data deserves review, especially while an agent's reliability is unproven.

• No observability into agent decisions

  Without logging each step's reasoning, tool calls, and results, debugging why an agent did something is very difficult.

• Reaching for multi-agent orchestration before it's needed

  A single well-scoped agent is simpler to build and secure — orchestration adds coordination overhead that should be justified by a genuine multi-specialty need.