AI agents and tool use

The reasoning-loops lesson ended with a model critiquing and refining its own text. Give that loop hands — the ability to call tools, observe real results, and act again — and you have an agent: the pattern that moved from research demo to the industry’s center of gravity in about eighteen months. This lesson builds it from parts you already own: the loop is a policy acting in an environment (this track’s oldest object), tool schemas are typed contracts (the multi-repo lesson’s discipline), and the failure modes are RL’s failure modes wearing production clothes.

From reasoning loop to agent loop

An LLM alone maps text to text — frozen knowledge, no side effects. The agent construction wraps it in the loop this track has drawn since its first MDP:

— reason about the task, emit a tool call instead of (or alongside) prose, execute it against the world, append the result to context, repeat until done. Read it with RL eyes: context is state, tool calls are actions, tool results are observations, the model is a policy — the ReAct insight was precisely that interleaving reasoning tokens with actions makes that policy dramatically better at choosing them. What is different from this track’s RL: no gradient updates in the loop (the policy is frozen; learning happened at training time), horizons are short, and the “reward” is usually a task-level judgment after the fact — which is why the evaluation lesson that follows this one exists.

Tools: typed interfaces to the world

A tool is a function signature the model can see and invoke: name, description, typed parameters (JSON Schema in every major API). The model emits a structured call; your code validates and executes it; the result returns as text. Three design rules carry most of the craft:

• The description is prompt engineering — the model chooses tools by reading them. “search_orders(query): search the order database” loses to a description stating when to use it, when not to, and what it returns. Treat tool docs as an interface for a very literal reader.
• Validate at the boundary, execute least-privileged. Schema-check every argument (the bad-args scenario), and give the executing code the IAM lesson’s treatment: an agent that can only read the tables it needs converts “model hallucinated a delete” from incident to log line. Blast-radius thinking transfers verbatim — an agent’s tool set IS its blast radius.
• Design tool outputs for the model: concise, structured, with errors that explain (the copy rule from this platform’s own design guidance — the model is a user too). A tool that dumps 40KB of JSON into context is spending the budget the serving lesson priced.

MCP (Model Context Protocol) is this idea standardized: tools, resources and prompts exposed by servers any agent client can connect to — USB for tools, replacing per-app integrations. Its arrival is why “agent that can use your company’s systems” went from a custom build to configuration, and its security surface (a tool description is untrusted input to your agent — injection lives there) is why the boundary rules above became urgent rather than pedantic.

Orchestration: from one loop to systems

Above the single loop sit composition patterns, in increasing order of autonomy — and the engineering rule is to sit as LOW on this ladder as the task allows:

1. Workflows (fixed DAGs with LLM steps): deterministic control flow, model only where judgment is needed. The CI-pipeline of agent patterns — most “agent” products in production are actually this, on purpose.
2. Router + specialists: one model classifies, hands off to focused sub-agents with narrow tool sets — bounded autonomy per specialist, the multi-repo lesson’s isolation argument applied to cognition.
3. The full loop (this lesson’s diagram): the model plans its own path. Needed exactly when the path genuinely can’t be enumerated — debugging, research, open-ended tasks.
4. Multi-agent (planner/worker, debate, crews): powerful when sub-tasks parallelize; also multiplies every failure mode, and the compounding arithmetic of the next lesson applies to the product of the agents involved. The honest current summary: multi-agent systems win benchmarks in papers and lose to a well-built single loop in most production settings, so far.

Context is the loop’s binding constraint — each turn appends, and the KV-cache lesson priced what that costs. Mature loops manage it actively: summarize old turns, keep tool results terse, externalize memory to retrieval (the RAG lesson’s machinery, now serving the agent itself).

# the loop, in the fewest honest lines (Anthropic-style tool use)
import anthropic, json
client = anthropic.Anthropic()

TOOLS = [{
    "name": "get_order",
    "description": "Look up ONE order by its exact id (format ord_...). "
                   "Use search_orders first if you only have a customer name.",
    "input_schema": {"type": "object",
                     "properties": {"order_id": {"type": "string", "pattern": "^ord_"}},
                     "required": ["order_id"]},
}]

def run_agent(task, max_turns=8):                 # ← the budget guardrail
    messages = [{"role": "user", "content": task}]
    for _ in range(max_turns):
        r = client.messages.create(model="claude-sonnet-5", max_tokens=1024,
                                   tools=TOOLS, messages=messages)
        if r.stop_reason != "tool_use":
            return r.content[0].text              # done: prose answer
        call = next(b for b in r.content if b.type == "tool_use")
        try:
            result = execute_validated(call.name, call.input)   # schema + IAM here
        except Exception as e:
            result = f"ERROR: {e}"                # errors are observations
        messages += [{"role": "assistant", "content": r.content},
                     {"role": "user", "content": [{"type": "tool_result",
                       "tool_use_id": call.id, "content": str(result)}]}]
    return "halted: turn budget exhausted"        # runaway defense

Exercises