Build agents
Build Agents
What this part covers, how it relates to the core guide, and the design defaults that apply across every topic below.
Last verified 2026-09-24
Summary
Part 1 of this guide makes an existing product usable by agents: discovery, , tools, , servers, authentication, error handling, and retrieval. This part is different. It is a condensed, current-practice reference for teams building agents of their own - choosing a runtime, wiring memory, running multi-agent systems, and giving agents browser or access.
Each page states what good practice is right now and points at the tools and platforms that implement it, in the tooling catalog. Framework ecosystem lists (Mastra's integrations, for example) are used as sources without being treated as the authority.
How This Part Is Organized
| Page | Covers |
|---|---|
| Frameworks | Where agent work should run, and which runtime or framework fits |
| Platforms | Anthropic and OpenAI platform surfaces: hosted tools, MCP, skills, models |
| Orchestration | Multi-agent patterns: sequential, concurrent, , supervisor, council |
| Memory | Message history, , , observational and |
| Durable Execution | Running non-deterministic agent loops inside replay-safe workflow engines |
| Browser and Sandboxes | Browser access and isolated code execution as high-risk, bounded tools |
| Guardrails | Runtime input/output processors that stand in front of the model |
| Prompts and Configuration | Treating the system prompt as versioned, testable configuration |
| Channels | Reaching users on Slack, WhatsApp, Telegram, and other messaging surfaces |
| Background Agents | Scheduled, proactive work that runs without a user waiting on it |
For vendor lists and comparison tables behind any of these topics, see the tooling catalog.
Scoping Before Patterns
Before picking an orchestration pattern, the work: list every capability the system needs, group the list by shared data source, shared actor, or shared task type, then map each group to a candidate agent boundary. Start with one agent. Split it only when a capability is genuinely separate - a different data source, a different actor, a different kind of task - not because the prompt has grown long. Add routing once there are two or more agents to route between; routing logic with only one destination is dead weight.
Autonomy Ladder
Agent autonomy comes in degrees. Placing a system on this ladder before building it clarifies how much structure the loop needs and how much can be left to the model:
- Low - the model picks between a fixed set of options; there is no open-ended tool loop.
- Medium - the model calls tools in a loop, carrying memory forward between calls, until it reaches a stop condition.
- High - the model plans multi-step work and delegates parts of it to other agents or workflows.
Most production systems should sit at the lowest rung that satisfies the task. Reaching for "high" by default is how a system ends up with an unbounded loop and no clear owner for any one decision - see Bounded loops only, below.
Design Defaults
A handful of defaults apply regardless of which framework or platform a team picks. They come up on nearly every page below, so they are stated once here.
- Tools over knowledge. Business state, retrieval, and side effects belong in tools, not in the prompt. If a value could change tomorrow, it should not live only in the system prompt - see Tool Design.
- Narrow ownership. An agent should own one decision boundary, not a department. A "billing dispute triage agent" is easier to evaluate and less likely to hallucinate tool usage than a "customer operations agent."
- Workflow before agent. If the sequence is predictable, scaffold a deterministic workflow and drop an agent in only at the steps that need judgment: classifying intent, synthesizing tradeoffs, choosing among candidates.
- Bounded loops only. Every production agent needs an explicit step budget, a stop condition, and a failure path for when the budget runs out. A loop that needs more than 10 steps is usually a sign the boundary is wrong, not that the budget should grow.
- Prompt as configuration. See Prompts and Configuration for the pattern; keep tenant selection, branching business logic, and access decisions out of prompt text entirely.
- Memory is earned. Start with none. Add , then working memory, then semantic recall only when the product need is concrete - see Memory.
- Eval-first. A scaffold that creates an agent without a success case, a wrong-tool case, and a malformed-arguments case is incomplete. See Evaluation Framework in Part 1.