--- title: "Build Agents" description: "What this part covers, how it relates to the core guide, and the design defaults that apply across every topic below." url: "https://agentsurface.dev/docs/agents" lastVerified: 2026-09-24 lastModified: 2026-09-25T09:56:33.000Z --- ## Summary [#summary] Part 1 of this guide makes an existing product usable by agents: discovery, APIs, tools, CLIs, MCP 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 sandbox access. Each page states what good practice is right now and points at the tools and platforms that implement it, in [the tooling catalog](/docs/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 [#how-this-part-is-organized] | Page | Covers | | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | [Frameworks](/docs/agents/frameworks) | Where agent work should run, and which runtime or framework fits | | [Platforms](/docs/agents/platforms) | Anthropic and OpenAI platform surfaces: hosted tools, MCP, skills, models | | [Orchestration](/docs/agents/orchestration) | Multi-agent patterns: sequential, concurrent, handoff, supervisor, council | | [Memory](/docs/agents/memory) | Message history, working memory, semantic recall, observational and procedural memory | | [Durable Execution](/docs/agents/durable-execution) | Running non-deterministic agent loops inside replay-safe workflow engines | | [Browser and Sandboxes](/docs/agents/browser-and-sandboxes) | Browser access and isolated code execution as high-risk, bounded tools | | [Guardrails](/docs/agents/guardrails) | Runtime input/output processors that stand in front of the model | | [Prompts and Configuration](/docs/agents/prompts-and-configuration) | Treating the system prompt as versioned, testable configuration | | [Channels](/docs/agents/channels) | Reaching users on Slack, WhatsApp, Telegram, and other messaging surfaces | | [Background Agents](/docs/agents/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](/docs/tooling-catalog). ## Scoping Before Patterns [#scoping-before-patterns] Before picking an orchestration pattern, scope 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 [#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 [#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](/docs/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](/docs/agents/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 message history, then working memory, then semantic recall only when the product need is concrete - see [Memory](/docs/agents/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](/docs/testing/evaluation-framework) in Part 1. ## Related [#related] * [Getting Started](/docs/getting-started) * [Tool Design](/docs/tool-design) * [Testing](/docs/testing) * [Tooling Catalog](/docs/tooling-catalog) * [Agent Retrieval](/docs/agent-retrieval)