Agents and Tools — Overview

Phase 10 · Document 00 · Agents and Tools Prev: Phase 9 — RAG · Up: Phase 10 Index

Table of Contents

1. Why This Matters
2. Core Concept
3. Mental Model
4. Hitchhiker's Guide
5. Warmup Readings
6. Deep Readings and External References
7. Key Terms
8. Important Facts
9. Observations from Real Systems
10. Common Misconceptions
11. Engineering Decision Framework
12. Hands-On Lab
13. Verification Questions
14. Takeaways
15. Artifact Checklist

1. Why This Matters

An agent is what turns a text generator into something that can act — search the web, query a database, run code, edit files, call APIs — by wrapping the model in a loop where it proposes actions and your application executes them. Agents are the highest-leverage and highest-risk pattern in applied LLMs: the same loop that automates a multi-step workflow can also send 50 emails, delete a file, or run rm -rf if you don't engineer the guardrails. This phase teaches the anatomy of an agent (the loop, tool calling, structured output, planning, memory), the safety layer (sandboxing, approval, stop conditions), the applications (coding, research/browser agents), and the operations (observability, evaluation) — building directly on the lifecycle you already studied (what-happens §1.G). This overview is the map of Phase 10.

2. Core Concept

Plain-English primer: an agent is a loop around a stateless model

The model is a stateless tokens_in → next_token function (what-happens §0). It can't do anything — it can only emit text. An agent is the harness that gives it agency by running a loop: the model is told what tools it has, it proposes a tool call (as structured text), your application executes it, you feed the result back, and the model decides the next step — repeating until the goal is met or a stop condition fires (what-happens §1.G).

goal → [model: reason + propose tool_use] → APP validates + executes → tool_result
     → [model: reason + propose next] → … → [model: final answer]  (or stop condition)

The one law: the model proposes, the application executes

Burn this in, because all of agent safety follows from it:

The model never touches a database, file system, network, or API. It only emits text shaped like a tool call. Your application validates, permissions, executes, and can refuse. That boundary is where all safety, audit, and control live. (Phase 1.00 Law 6)

A tool_use block is a request, not an action. Treating it as trusted/auto-executed is how agents cause damage — the application is the trust boundary (05).

The anatomy (the map of this phase)

An agent decomposes into parts you'll build one (or a few) per doc:

• Tool calling (01) — the tool_use/tool_result protocol, the loop, validation, retries, parallel calls.
• Structured output / JSON Schema (02) — tools are schemas; constrained decoding guarantees shape, not correctness.
• Planning (03) — ReAct, plan-and-execute, reflection, decomposition, single vs multi-agent.
• Memory (04) — working/episodic/semantic/procedural; context management as the loop grows (agent-memory ref).
• Sandbox + approval (05) — the safety layer: isolation, risk tiers, human-in-the-loop, least privilege, rollback, audit.
• Code-editing agents (06) and browser/research agents (07) — the two dominant applications.
• Observability (08) and evaluation (09) — see and measure multi-step behavior; per-step reliability compounds (Phase 5.06).

Agent vs workflow vs chatbot (don't over-agent)

• Chatbot: one prompt → one answer. No actions.
• Workflow (chain): a fixed, predetermined sequence of LLM/tool steps you wrote. Predictable, debuggable, cheap.
• Agent: the model decides the next step dynamically in a loop. Flexible, but less predictable, pricier, and riskier.

A key seniority signal: use the least-agentic thing that works. Many "agent" problems are better solved by a fixed workflow with one or two LLM calls; reserve the open-ended agent loop for genuinely dynamic, multi-step tasks. (Anthropic's "building effective agents" makes exactly this distinction.)

Why per-step reliability is everything

A multi-step agent's success is roughly the product of its per-step reliabilities: 95% per step over 10 steps ≈ 60% end-to-end. So agent quality is dominated by per-step tool-call reliability, error recovery, and stop conditions — not by raw model IQ (Phase 5.06). This is why observability (08) and evaluation (09) matter so much, and why you start with read-only tools and add risk gradually.

3. Mental Model

   AGENT = LOOP around a stateless model:
     goal → [model proposes tool_use] → APP validates+permissions+EXECUTES → tool_result
          → [model proposes next] → … → final answer   (or STOP: max steps/tokens/time/loop)

   ★ LAW: the model PROPOSES (emits text shaped like a call); the APP EXECUTES (trust boundary) [1.00 Law 6]

   ANATOMY: tool-calling [01] · structured output [02] · planning [03] · memory [04]
            · sandbox/approval [05] · apps: code [06] / research [07] · observability [08] · eval [09]

   PICK THE LEAST-AGENTIC THING: chatbot < fixed WORKFLOW < AGENT (dynamic, flexible, riskier)
   ★ per-step reliability COMPOUNDS: 0.95^10 ≈ 0.60 → reliability/recovery/stops > model IQ [5.06]

Mnemonic: an agent is a loop where the model proposes and the app executes. Use the least-agentic option that works; per-step reliability compounds, so engineer the loop (validation, recovery, stops), not just the model.

4. Hitchhiker's Guide

What to look for first: is a loop actually needed, or would a fixed workflow do? Then the model-proposes/app-executes boundary and your stop conditions — those decide safety and whether it terminates.

What to ignore at first: multi-agent orchestration, elaborate planning frameworks, and exotic memory. Start with one model + a few read-only tools + a hard step limit; add write tools, planning, and approval as it proves reliable.

What misleads beginners:

• Trusting tool_use. The model only proposes — auto-executing without validation/permission is how agents cause damage (05).
• Over-agenting. Reaching for an autonomous loop when a fixed workflow is more reliable, cheaper, and debuggable.
• Ignoring compounding error. High per-step accuracy still fails long tasks — measure per-step reliability (09, Phase 5.06).
• No stop conditions. Loops run forever / repeat actions / blow cost without max-steps/tokens/time + loop detection.
• Starting with write tools. Read-only first; add irreversible actions behind approval only once reliable.

How experts reason: they minimize agency (workflow if possible), keep the app as the trust boundary (validate every tool call, permission risky ones), engineer for error recovery + termination (stops, loop detection, retries), gate risky actions behind sandbox/approval (05), and instrument + evaluate the trajectory (08/09). They start read-only and earn write access with measured reliability.

What matters in production: per-step tool-call reliability, task success rate, safe execution (no unapproved irreversible actions), termination guarantees, and full trace/cost observability — agents are where cost and risk both spike.

How to debug/verify: read the trace (08) — which tool calls, args, results, in what order; where did it loop, mis-call a tool, or fail to recover? Evaluate per-step and end-to-end (09).

Questions to ask: does this need an agent or a workflow? what's the trust boundary + permission model? what are the stop conditions? what's the per-step reliability and task success rate? are risky tools sandboxed/approved?

What silently gets expensive/unreliable: runaway loops (cost + actions), unguarded irreversible tools (damage), compounding per-step errors (low task success), and un-instrumented agents you can't debug.

5. Warmup Readings

6. Deep Readings and External References

7. Key Terms

8. Important Facts

• An agent is a loop around a stateless model: model proposes a tool call → app executes → result fed back → repeat (what-happens §1.G).
• The law: the model proposes, the application executes — the app is the trust/safety/audit boundary (Phase 1.00 Law 6).
• A tool_use block is a request, not an action — never auto-trust it (05).
• Prefer the least-agentic solution: chatbot < fixed workflow < agent — reserve the loop for genuinely dynamic tasks.
• Per-step reliability compounds (0.95¹⁰ ≈ 0.60) — task success is dominated by reliability/recovery/stops, not model IQ (Phase 5.06).
• Every agent needs stop conditions (max steps/tokens/time + loop detection) or it runs away.
• Start read-only; add write/irreversible tools behind sandbox + approval as reliability is proven (05).
• Observability + evaluation are mandatory — you debug and improve agents by their trajectory (08/09).

9. Observations from Real Systems

• Coding agents (Claude Code, Cursor agent mode) are the most successful production agents — read/edit/run loops with approval (06, Phase 11).
• Research/browser agents (Deep Research-style) decompose, search, read, and synthesize with citations (07, Phase 9.08).
• Anthropic's "building effective agents" explicitly pushes teams toward workflows over agents unless flexibility is needed — the field's hard-won lesson.
• Most agent failures are not model failures — they're loops, bad tool schemas, missing error recovery, or no stop conditions (01/09).
• MCP (Model Context Protocol) standardizes how tools/data are exposed to agents — an emerging interoperability layer (01).

10. Common Misconceptions

11. Engineering Decision Framework

DO I NEED AN AGENT?
  one-shot answer            → chatbot (no tools)
  fixed, known step sequence → WORKFLOW (chain) — more reliable/cheaper/debuggable
  dynamic, multi-step, model-decided next action → AGENT (this phase)   [least-agentic that works]

BUILD THE AGENT (safely):
 1. TOOLS: clear schemas [02]; start READ-ONLY; the app validates every call [01].
 2. LOOP: bound it — max steps/tokens/time + loop detection; error recovery/retries [01].
 3. SAFETY: risk-tier tools; sandbox + human approval for write/irreversible; least privilege; audit [05].
 4. PLAN/MEMORY as needed: planning [03], memory/context mgmt [04] — add only if required.
 5. OBSERVE + EVAL: trace every step [08]; measure per-step reliability + task success [09,5.06].
 6. SCALE RISK GRADUALLY: prove reliability on read-only, then grant writes behind approval.

12. Hands-On Lab

Goal

Build a minimal, bounded agent and feel the core dynamics: the propose/execute loop, the trust boundary, stop conditions, and compounding reliability.

Prerequisites

• pip install openai; an API key (or a local OpenAI-compatible endpoint, Phase 6.04).

Steps

1. Define 2 read-only tools with clear JSON schemas (e.g., web_search(query), read_page(url) — mock them) (01/02).
2. Implement the loop: model proposes tool_use → your code validates args → executes → appends tool_result → re-calls; stop on final answer (what-happens §1.G).
3. Add stop conditions: max_steps, a token budget, and a loop detector (same tool+args repeated) — confirm each can halt the agent.
4. Trust boundary: add a delete_file(path) tool but route it through an approval gate (prompt y/n); confirm the model can propose it but it never runs without approval (05).
5. Compounding reliability: give the agent a 5-step task; run it 10×; record the task success rate and where steps fail — observe how per-step errors compound (09, Phase 5.06).
6. Workflow contrast: re-solve one task as a fixed two-call workflow (no loop) and compare reliability/cost/predictability.

Expected output

A bounded agent that loops with read-only tools, halts on stop conditions, gates a destructive tool behind approval, plus a measured task-success rate and a workflow-vs-agent comparison.

Debugging tips

• Runs forever / repeats → no/weak stop conditions or loop detection.
• Destructive tool executed → you didn't route it through the trust boundary.

Extension task

Add a trace of every step (tool, args, result, latency) (08) and a simple per-step reliability metric (09).

Production extension

Front the model with a gateway (budgets/limits/policy, Phase 8), sandbox code/bash tools (05), and add full tracing + eval.

What to measure

Per-step reliability, task success rate (n runs), stop-condition firing, approval-gate enforcement, workflow-vs-agent reliability/cost.

Deliverables

• A bounded agent (read-only tools + stop conditions).
• An approval-gated destructive tool demonstration.
• A task-success-rate measurement + a workflow-vs-agent comparison.

13. Verification Questions

Basic

1. What is an agent, in terms of the model and the loop?
2. Who executes tool calls, and why does that boundary matter?
3. When should you use a workflow instead of an agent?

Applied 4. Why does a 95%-per-step agent fail a 10-step task ~40% of the time? Implication? 5. List the stop conditions every agent loop needs.

Debugging 6. An agent sent 50 emails in a loop. What went wrong, and three fixes? 7. An agent's task success is low despite a strong model. Where do you look?

System design 8. Design a safe agent: trust boundary, risk-tiered tools, approval, stops, observability, eval.

Startup / product 9. Why is "use the least-agentic thing that works" both a reliability and a cost strategy?

14. Takeaways

1. An agent is a loop around a stateless model: it proposes tool calls; your app executes — that boundary is where safety lives.
2. Prefer the least-agentic solution (chatbot < workflow < agent); reserve the loop for genuinely dynamic tasks.
3. Per-step reliability compounds — engineer the loop (validation, recovery, stop conditions), not just the model (Phase 5.06).
4. Start read-only; gate write/irreversible actions behind sandbox + approval (05).
5. Observe and evaluate the trajectory — agents are debugged and improved by their step traces (08/09).

15. Artifact Checklist

• A bounded agent (read-only tools + stop conditions + loop detection).
• An approval-gated destructive-tool demonstration (trust boundary).
• A task-success-rate measurement showing compounding.
• A workflow-vs-agent comparison (reliability/cost/predictability).
• A step trace + a per-step reliability metric.

Up: Phase 10 Index · Next: 01 — Tool Calling