Ch.1 · The Anatomy of an Agent — The Agentic Platform

FND · Foundations Chapter 1

The Anatomy of an Agent

Strip away the marketing and an agent is a strikingly simple object: a loop that lets a language model observe, decide, act, and observe again until a goal is met. Everything else in this book exists to make that loop dependable. So we start here, with no products and no frameworks, and build the agent up from what it must necessarily contain.

1.1 What distinguishes an agent from a pipeline

A traditional LLM application is a workflow: a fixed, developer-authored sequence of steps, perhaps with branches, where the LLM fills in text at predetermined points. The control flow is decided in advance by a human. An agent inverts this. The LLM itself decides what to do next, in a loop, choosing among available tools based on what it observes — and that control flow is determined at runtime by the model, not the developer.

This single property — the model steers its own control flow — is the source of both the power and every difficulty in this book. A workflow's behavior is bounded and predictable; an agent's is open-ended and emergent. The platform's job is to grant that autonomy while containing its consequences.

First principle · Autonomy is the defining trait

An agent is software in which a language model directs control flow at runtime. The more steps the model decides for itself, the more "agentic" the system — and the more the surrounding platform must compensate for the model's non-determinism, latency, and fallibility.

1.2 The agent loop, derived

What must the loop contain? Consider the minimum required to pursue a goal through actions. The agent must perceive its situation (the goal plus any new observations), reason about what to do, act on that decision, and incorporate the result before deciding again. This is the same observe–orient–decide–act structure found in any control system; in agents it is most often called the ReAct loop (reason + act), and it is the irreducible core.

Fig 1.1 · The agent loop. The reasoner receives goal and context, emits a control decision (which tool to call), the tool produces an observation, and the loop repeats — appending to memory each turn — until the goal is met or a budget (steps, tokens, time, cost) is exhausted. The termination budget is non-negotiable: an unbounded loop is an unbounded bill.

1.3 The four faculties every agent needs

From the loop, four faculties are required by construction. Remove any one and the loop cannot run.

Reasoning — the model that interprets context and selects the next action. This is the only irreplaceable component; everything else is scaffolding around it. Its quality, latency, and cost set the platform's envelope.

Action — a mechanism to affect the world and gather information: tool/function calling, code execution, API requests, retrieval. Without action the model can only talk; with it, the model can do.

Memory — state that persists across the loop's turns (short-term working context) and across sessions (long-term episodic, semantic, and procedural memory). Without memory each turn is amnesiac and no multi-step goal can complete.

Orchestration — the loop itself plus its termination, error handling, and budgeting. This is the seam where a single agent becomes a platform concern, because the loop must survive crashes, scale, and be observed.

Map these four onto the layers of the rest of the book and you have the table of contents in miniature: reasoning becomes the model gateway and context engineering layers (Ch. 6–7); action becomes tools, MCP, and sandboxes (Ch. 8–9); memory becomes memory systems and retrieval (Ch. 10–11); orchestration becomes durable execution and the control loop (Ch. 4–5). The remaining layers — coordination, trust, observability, evaluation, FinOps, and scaling — are what emerge when you run many such agents in production.

1.4 A taxonomy of agentic systems

"Agent" spans a spectrum from barely-agentic to fully autonomous. Naming the points on that spectrum prevents the most common architectural error: over-engineering a workflow into an agent, or under-engineering an agent as a workflow. Anthropic's widely-cited distinction — workflows orchestrate LLMs through predefined code paths, while agents let the LLM dynamically direct its own process — anchors the table below.

Table 1.1 — The agency spectrum, from least to most autonomous
Pattern	Who decides control flow	Typical structure	When to use
Single LLM call	Developer (none)	Prompt → completion	Classification, extraction, simple generation
Chain / prompt pipeline	Developer	Fixed sequence of calls	Decompose a known task into known steps
Router	Model picks a branch, once	Classify → dispatch	Heterogeneous inputs to specialized handlers
Orchestrator–worker	Model plans, then delegates	Planner spawns sub-tasks	Tasks decomposable at runtime into parallel parts
Autonomous agent	Model, every turn, in a loop	ReAct loop with tools + memory	Open-ended goals; steps unknowable in advance
Multi-agent system	Multiple models negotiate	Network of cooperating agents	Genuinely separable concerns or roles (Ch. 12)

Hazard · Reach for the simplest pattern that works

Each step down this table adds non-determinism, cost, and failure surface. The most reliable production "agents" are often the least agentic structure that still solves the problem. Use a workflow when the steps are known; reserve the full autonomous loop for problems whose solution path genuinely cannot be enumerated in advance. We return to this discipline repeatedly — it is the single highest-leverage decision in the platform.

1.5 The state that must be carried

An agent's runtime state is larger than it first appears, and a platform must persist all of it to survive failure (Ch. 4). The minimum state of an in-flight agent run is: the goal; the message history (the running transcript of reasoning, tool calls, and observations); the scratchpad / working memory; the tool registry and permissions currently in scope; the budget counters (steps taken, tokens spent, wall-clock elapsed, cost accrued); and a checkpoint cursor marking the last durably-recorded step. Lose any of these on a crash and the run cannot resume correctly — it must restart, wasting tokens and possibly repeating side effects.

This observation — that an agent run is a long-lived, stateful, side-effecting, crash-prone computation — is precisely why the next chapter argues that a durable execution engine, not a web framework, is the correct foundation. But first we must enumerate exactly which problems separate the demo from the platform.

· · ·