An AI agent turns a language model from a responder into a system that can pursue a task. The model interprets a request; the surrounding system supplies tools, context, and controls so the agent can retrieve current information, decide what to do next, and act in external systems. Asking for a flight illustrates the difference: suggesting an airline is an answer, while checking schedules and making a reservation requires an agent. section 6.0 section 6.1.4
A practical agent needs several cooperating parts:
- Tools connect it to APIs, databases, and services. Retrieval supplies information; an action tool can change external state, such as booking a flight or updating a calendar. section 6.1.4 section 6.2.3
- A decision loop selects a step, executes it, observes the result, and adapts. Planning breaks larger tasks into steps; short-term and persistent memory retain relevant context. section 1.4.2 section 6.5
- A harness manages state, tool routing, approvals, and tracing. When an agent executes code, an isolated sandbox keeps that execution separate from credentials held by the harness. section 7.9.1
From an answer to an action
For “Schedule a meeting with my team tomorrow at 3 PM,” an agent can check calendar availability, send invitations, and report what happened. For “What’s the weather in Paris right now?”, it can query a weather API instead of guessing from training data. A tool call provides a source for the answer, but the agent must still handle tool results and failures reliably. section 6.1.4 section 6.2.3 section 1.4.2
Action raises the cost of mistakes. Booking the wrong destination can cost money; deleting customer records can cause lasting damage. Errors also compound across a workflow: at 85% reliability per step, a ten-step task succeeds end to end only about 20% of the time. Permissions, approvals, reversibility, tool robustness, and failure containment therefore matter alongside answer quality. Decision-flow controls and monitoring help detect loops that repeatedly call a tool without progress. section 1.4.2 section 1.2.4 section 6.0
For complex tasks, specialized agents can share work rather than relying on one agent for everything. A supervisor can coordinate them; a shared-state workflow can route requests and preserve context. Test the coordination as well as each component: ambiguous requests, blended tasks, failures, and state continuity can expose problems that isolated agent tests miss. section 1.4.2 section 8.4
Figure 7.4 The harness owns the agent loop, memory, and LLM communication. The sandbox executes code in isolation with no direct model access. Tasks flow right; results flow left. If the sandbox crashes, the harness recovers.
The architecture diagram separates the harness that manages the agent loop and memory from the sandbox that executes code in isolation and returns results. section 7.9.1
