Anatomy of an Agentic Loop

Every agent I ship runs the same loop: observe the world, think about what changed, act through a tool, repeat. Master that loop and the rest of the 2026 vocabulary — MCP, orchestration, evals, guardrails — falls into place.

The loop: observe → think → act

Strip away the framework branding and an agent is a while-loop wrapped around a model. Each iteration, the model observes state — tool results, files, error output — thinks about the next step, and acts by calling a tool. The output of the action becomes the observation of the next turn. The loop exits when the task is verified done or a budget runs out. That is the whole trick; everything else is engineering around it.

The design decisions live at the edges. Decide what the agent sees each iteration, because too much context degrades reasoning. Decide what it may do: tool allowlists and permission tiers. Decide when it must stop: step limits, cost caps, wall-clock timeouts. I spend more time on exit conditions than on prompts — an agent that cannot stop is worse than an agent that cannot start.

Tools are contracts (MCP)

A tool call is an API call the model composes on its own. Treat the definition as a contract: typed inputs, documented behavior, predictable errors. The Model Context Protocol (MCP) standardizes that contract, so one tool server plugs into any client — a coding agent, an IDE, a CI pipeline — without a rewrite. My test: if a junior developer cannot use the tool correctly from its description alone, neither can the model.

{"name": "search_orders", "description": "Find orders by customer email. Read-only.", "inputSchema": {"type": "object", "properties": {"email": {"type": "string"}}, "required": ["email"]}}

Orchestration: one agent is never enough

Real tasks outgrow a single context window fast. So I split the work: a supervisor owns the plan and dispatches focused subagents that return compact results instead of raw noise. Four patterns cover most systems I build:

• Supervisor: one agent plans, delegates, and merges; it never touches raw data itself.
• Fan-out / fan-in: run independent subtasks in parallel, then combine the results in a single pass.
• Subagents as context firewalls: each worker burns its own tokens and reports back a short summary.
• Checkpoints: persist state between steps, so a crashed run resumes instead of restarting from zero.

Context engineering beats bigger prompts

The biggest quality gains come from controlling what enters the window, not from writing a longer prompt. Retrieval (RAG) pulls in only the documents the current step needs. Prompt caching keeps the stable prefix — system rules, tool schemas — cheap and fast across turns. Memory files carry decisions between sessions, so the agent stops re-discovering the codebase every morning. Budget context like money: every token in the window must earn its place.

If you cannot measure it, it is a demo

Agents fail probabilistically, so measure them statistically. Two numbers rule my dashboard: task success rate — did the run produce a verified, correct result? — and human-intervention rate — how often did a person have to step in? Every prompt or tool change runs against a fixed eval set before it ships; otherwise you trade known behavior for vibes and call it progress. Guardrails complete the picture: destructive actions wait for human approval (HITL), and every action lands in a log someone can audit.

• Build the loop small: clear observations, contracted tools, hard exit conditions.
• Split work across agents and engineer the context — never inflate one giant prompt.
• Ship with evals and guardrails; a demo becomes a product the day you start measuring it.