Before turn one: system prompt, tools, budget

Lesson 1 of 5 in Anatomy of a Real Agent: One Run, Every Part Named.

You have studied the agent loop as a diagram and tools as schemas. This module does something different: you will read one complete, realistic agent run from first token to final stop, and by the end you will be able to name every part of it the way a mechanic names engine parts.

The artifact: a customer-support agent for Fernway Outfitters, an online outdoor-gear retailer, handling the most ordinary ticket in e-commerce — "my order never arrived." Six turns. One tool error. One recovery. One irreversible action. We will call each model invocation a turn: the LLM receives the accumulated transcript, produces either a tool call or a final message, and the runtime acts on whichever it got. Everything an agent is lives inside that rhythm.

But no run starts at turn one. It starts with three artifacts someone wrote before any customer typed a word.

Read the system prompt as a job description, not a program. It routes ("resolve delivery issues"), it constrains ("carrier confirms loss"), it sets tone, and it encodes policy — the $100 threshold, the no-invention rule. But notice what it cannot do: it cannot enforce any of this. A prompt is advice to a probabilistic system. Because of non-determinism, the model will follow it almost always — and "almost" is the word every later domain of this site exists to handle. Real enforcement lives in the runtime, and you will watch it earn its keep in turn 4.

Run trace — setup 2 of 2: toolset and budget

Tools registered for this agent:

lookup_order(order_id?, email?)        → order record
carrier_track(tracking_id)             → shipment status from carrier API
issue_refund(order_id, amount, reason) → refund; gated: amount ≤ $100
escalate_to_human(summary)             → opens a case for a human agent
close_ticket(order_id, resolution)     → closes the support ticket

Budget: max 10 tool calls per conversation · 40,000-token context ceiling · 120-second wall clock. Exceeding any limit ends the run and escalates to a human.

The toolset, read the way a security reviewer reads it
Tool	Read or write?	Reversible?	Blast radius if misused
`lookup_order`	Read	n/a	Leaks one customer’s order data — a privacy risk, not a money risk
`carrier_track`	Read (external)	n/a	None directly — but its output is third-party text entering the context
`issue_refund`	Write	No — money moves	Real dollars; this is why it carries a runtime gate, not just a prompt rule
`escalate_to_human`	Write (internal)	Yes	A wasted human’s time — cheap, which is why it is the designated safe exit
`close_ticket`	Write (internal)	Yes	A prematurely closed ticket — annoying, recoverable

Two design choices deserve a pause. First, exactly one tool is dangerous — issue_refund — and it is the only one wearing a runtime gate. That is least privilege in miniature: match the friction to the blast radius. Second, the budget is a stopping condition of last resort. The happy path ends when the model decides it is done; the budget exists for the runs where it never decides. An agent without a budget is an agent that can loop forever at your expense.

Key terms: system prompt, tool, agent loop, stopping condition, agent runtime, blast radius

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.