Rung 4 — agent SDKs (the OpenAI Agents SDK, the Claude Agent SDK), and rung 5, the harness
Build the lead router as a capped agent, price its caps from one trace, total what the step up costs a month, and put the agent back inside a step.
On this page
On rung 4 the SDK owns the loop: the model picks each next step from a list of tools, and your code sets the tools, the caps and where a capped run goes. It is the right rung when the next step depends on the last result in a way nobody can list before the run, and the most expensive rung to choose for a task whose steps you can list. Built as an agent, the lead router shows both, and rung 5 puts the agent back inside a step that code controls.
What the SDK owns, and what you still write
Both SDKs run the loop taught in agent loops and stop conditions: call the model, run the tools it asks for, append the results, and repeat until it answers without a tool call.
In the OpenAI Agents SDK a turn is one model call; max_turns caps them and raises MaxTurnsExceeded when a run goes past (Running agents (opens in a new tab)). The SDK counts tokens per run but leaves any spend limit to your code (Usage (opens in a new tab)).
The Claude Agent SDK takes max_turns and max_budget_usd, and stops a run when its estimated cost reaches the budget; the reference notes the estimate can pass the figure, so leave headroom (Agent SDK reference - Python (opens in a new tab)).
What you write is the same in either:
result = run_agent(
instructions=LEAD_PROMPT, # the workflow's 1,200 tokens
tools=[find_customer, get_history, save_draft], # about 800 tokens of schemas
input=lead, # about 250 tokens
max_turns=10,
max_spend_usd=0.08,
)
if result.status != "done":
person_queue.post(lead, reason=result.status) # "turn_cap" or "spend_cap"
The names differ between SDKs; the four decisions do not: tools, instructions, two caps, and who gets a capped lead.
The trace of one run, and the price of a cap
Scripts, workflows and agents gave the typical run: turn n sends 2,250 + 300 × (n − 1) tokens and returns about 100, eight turns in all.
Six of the eight turns are lookups. Only the save and the reply in it needed judgment.
A $0.05 spend cap looks generous beside the workflow's half cent, and it is wrong. The run has spent $0.0497 after turn 7 and $0.059 after turn 8, so an ordinary lead trips the cap on the turn that confirms its draft and lands in the person queue with the draft already saved: 400 false alarms a month, and an account manager who learns to ignore the queue.
Set the spend cap from the run you are willing to allow. Ten turns cost 10 × 2,250 + 300 × 45 = 36,000 tokens in and 1,000 out, $0.072 + $0.008 = $0.08. With the turn cap at 10 and the spend cap at $0.08, the two agree on an ordinary run, and the spend cap fires first only when a tool returns far more than usual. The worst month is 400 × $0.08 = $32, the figure the virtual employee frame wrote into the role's budget.
What choosing rung 4 costs here
Module 0 derived the multiple: 27,200 tokens a lead against the workflow's 1,950, about 14 times, and three failure modes the graph does not have: loops, tool misuse and unbounded spend. The caps bound the third. Priced as lines on the two sums, the step up from rung 2 costs:
- Tokens: $0.059 against $0.0054 a lead, $23.68 against $2.16 a month: +$21.52 a month.
- The test: the workflow's draft step is tested on saved leads with a known input each. The agent takes a different path on the same lead from run to run, so each case must accept a set of outcomes: which record, at most one
save_draft, no other client's project in the reply, under ten turns. Writing that for 60 past leads at about 4 founder minutes each is 240 minutes, 4 hours: $400 once, the eval set evals as the unit test of LLM work teaches. - Review: the launch sample's 80 replies are now read with their traces, to check the record the model chose and the calls it made. Assume 5 minutes each instead of 3: 160 minutes more, +$80 a month.
Against that, module 0 found the agent's one gain: about 20 of the 40 unmatched leads are customers known under another address, 2 hours of a person, $60 a month. The step up costs $101.52 a month and $400 once to win $60 a month. It loses about $42 a month before a single wrong reply, and the same $60 is available on rung 2 for one more node, a search by domain when the email misses, about an hour's build.
When rung 4 is the right rung
Ask for twenty traces from a week of shadow runs and write down each run's sequence of tool calls. If they fall into two or three patterns, those are branches, and the task belongs on a graph. If each result decides what to look at next, the task is an agent's. Reconciling a payment that matches no invoice is the course's example: amount, then client, then the memo's reference, in an order nobody can fix in advance.
The router's trace has one pattern: look up, read, save. That is a graph.
Rung 5: the agent inside a step
Rung 5, the harness, wraps the model's judgment back inside steps that code picks; deterministic first builds it in full. For the router it is a small change to the rung 3 graph. Where lookup returns no match, a capped agent step with two read-only tools tries to find the customer, at most 4 turns. Assume a 600-token prompt and 500 tokens for the two tool schemas: about 7,200 tokens in and 400 out, under 2 cents a try and under $1 a month for 40 leads. Code then checks the proposal, that the record's domain matches the sender's, before draft runs, and a failed check goes to a person.
The model judges inside one step; code owns the order, the check, the caps and the send. The arithmetic for why is in why reliability lives in the harness: five model steps at 95% each finish a task 77% of the time, and a code check with one retry per step lifts that to about 99%.
In practice
To a vendor demonstrating an agent: ask for twenty traces, the price of the typical run, and how the caps were set. A spend cap below the typical run means nobody priced it. To the team: an agent ships with its eval set, its two caps and its person queue, or it does not ship.
The mistake that costs money is choosing rung 4 for steps you could have listed. Here it is $101.52 a month and $400 once to win back $60 that one rung-2 node wins for an hour's work.
Check yourself
1. For large clients get_history returns 2,000 tokens instead of 200. On the typical run, where does the $0.08 cap fire, and what do you change?
Turns 3 to 6 read history, so from turn 4 each input grows by 2,100 instead of 300. Inputs run 2,250, 2,550, 2,850, 4,950, 7,050, 9,150, then 11,250 on turn 7. Cumulative spend is $0.062 after turn 6 and $0.086 after turn 7, so the cap fires on the save turn and no draft is saved. Do not raise the cap; make
get_historyreturn the 200 tokens a reply needs.
2. Twenty shadow traces: 17 go email lookup, history, save; 3 go email lookup, domain lookup, history, save. Which rung?
Rung 2. Two patterns are one branch: when the email misses, search by domain. That is one node in the existing graph, about an hour of building, no extra tokens, and a path a test can assert.
3. Each week the agency wants, for any of its 40 projects whose traffic or spend moved more than 20%, an explanation drawn from ads, analytics and the project log, where each finding decides the next query. Assume 8 projects move a week. Which rung?
Rung 4 inside rung 5. The investigation cannot be listed in advance; finding the 8 projects, fetching the standard figures and filing the report are code. Cap each run from shadow traces: turns at twice the p95, spend at the price of a run at that turn cap. At, say, $0.15 a run, 8 × 4.33 = 35 runs cost about $5 a month.