Agentic Architectures and Orchestration

This chapter treats agents as architectural components with explicit boundaries, not as a new kind of software that escapes the usual disciplines. It distinguishes a workflow from an agent, shows how tool use and the Model Context Protocol (MCP) connect a model to the enterprise, and bounds autonomy with permission manifests, approval gates, and audit trails in version control, before turning to the failure modes we see most often and their controls.

Chapter 10 described the foundation model as a probabilistic component behind a well-defined interface. Once that component may call tools and choose what to call next, we have changed the architecture, not merely the prompt. The distinction that matters is who owns the control flow.

In a workflow, the control flow is written in code: the sequence of model calls, the branching conditions, and the tools invoked at each step are fixed by the developer, and the model fills in content. Anthropic's practitioner guidance draws exactly this line and recommends starting with workflows because they are predictable, testable, and cheap to run (64, Anthropic, 2024). In an agent, the control flow is delegated to the model, which receives a goal, selects a tool, observes the result, and selects the next tool until the goal is met or a limit is reached. The ReAct pattern, which interleaves reasoning traces with actions and observations, is the canonical description of that loop (57, Yao et al., 2023). Toolformer showed that models can learn when to invoke external functions from relatively little supervision, which is why tool use has become a general capability rather than a bespoke integration (58, Schick et al., 2023).

Primary topics explored

1. Workflows and agents are different components
2. Tool use and the Model Context Protocol
3. Steps
4. Never
5. Multi-agent patterns that survive contact with production
6. Bounded autonomy as an architectural property