Selecting Agent Models

Phase 5 · Document 06 · Model Selection Prev: 05 — RAG Models · Next: 07 — Structured-Output Models

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

Agents — models that call tools in a loop to accomplish multi-step tasks — are the hardest selection case because small per-step error rates compound: a model that emits a valid tool call 95% of the time fails a 10-step task ~40% of the time. Selecting an agent model is about reliability under iteration, not single-shot brilliance: valid tool calls, multi-step coherence, error recovery, and not looping forever. Pick wrong and your agent silently burns tokens, mangles tool arguments, or gives up. This doc applies the framework to agents, building on tool calling (Phase 1.04) and feeding the full agent build (Phase 10).

2. Core Concept

Plain-English primer

• Agent — an LLM in a loop: it reads the goal + state, proposes a tool call (an action), your code runs it, the result is appended, and it goes again until done (Phase 10). The model proposes; your app executes (Phase 1.00, Law 6).
• Tool / function calling — the model emits a structured request (name + JSON arguments) to invoke one of your functions (Phase 1.04).
• Valid-tool-call rate — fraction of tool calls that parse and match the schema. The single most predictive agent metric.
• Multi-step / agentic coherence — staying on-task across many steps without forgetting the goal or looping.
• Error recovery — when a tool returns an error, does the model adapt (fix args, try another path) or flail?
• Step limit / stop condition — a cap on loop iterations so a confused agent can't run (and bill) forever.

Why reliability compounds (the core selection insight)

A task of n steps succeeds only if (roughly) every step succeeds. If per-step reliability is r:

task_success ≈ r^n
  r=0.95, n=10  → 0.95^10 ≈ 0.60   (40% of tasks fail!)
  r=0.99, n=10  → 0.99^10 ≈ 0.90

So a model that's "95% good at tool calls" is not good enough for long agent tasks. Agent selection is dominated by per-step reliability, which compounds — a 4-point reliability gain can halve task failure.

What to optimize for (agent-specific axes)

1. Tool-call validity & accuracy — valid JSON matching the schema, with the right tool and right arguments.
2. Multi-step coherence — decompose, track state, and progress over a long, growing context (agents accumulate history → context + KV cost grow, Phase 2.06).
3. Error recovery — handle tool failures gracefully.
4. Instruction/format following — respect tool schemas and constraints reliably (07).
5. Planning quality — for hard tasks, decompose well (often a reasoning model, 04).
6. Cost/latency per task — agents make many calls; per-task cost = per-call cost × steps.

Selection is usually role-split routing

Real agents route by sub-role (Phase 10/11):

PLANNING / decomposition → strongest (often reasoning) model
TOOL-CALLING steps        → reliable tool-caller (can be cheaper) — reliability > raw IQ here
SUMMARIZE / synthesize    → mid-tier
ROUTING / classify        → cheapest that's accurate

So "select an agent model" = pick a reliable tool-caller for the loop, a strong planner for decomposition, and wire guardrails (validation, step limits, approval gates) that the application owns regardless of model.

3. Mental Model

AGENT = LLM in a LOOP:  goal+state → propose TOOL CALL → app executes → append result → repeat → stop
        (model PROPOSES, app EXECUTES + validates + limits — Law 6)

RELIABILITY COMPOUNDS:  task_success ≈ r^n   (r=0.95,n=10 → 60%!) → select on PER-STEP reliability.

OPTIMIZE: valid-tool-call rate · multi-step coherence · error recovery · format-following · planning · cost/task
ROUTE by sub-role: planning→reasoning · tool steps→reliable caller · synthesis→mid · routing→cheapest
GUARDRAILS are the APP's job: schema validation · step limits · approval gates (Phase 10/14)

4. Hitchhiker's Guide

What to measure first: valid-tool-call rate and multi-step task success on your tools — single-shot benchmark quality barely predicts agent reliability.

What to ignore at first: general chat-quality leaderboards; they don't measure tool reliability or loop coherence.

What misleads beginners:

• Picking the "smartest" model and assuming it's a good agent (reliability ≠ IQ).
• Trusting a "tool calling: yes" flag without measuring the valid-call rate (Phase 1.04).
• Ignoring compounding (95% per step looks fine, fails long tasks).
• No step limit → runaway loops that burn tokens.

How experts reason: measure per-step reliability and multi-step success on real tools; route planning→reasoning and tool-steps→reliable caller; and put guardrails in the application (validate every tool call, cap steps, gate risky actions) so model choice isn't the only safety net.

What matters in production: valid-tool-call rate, task-success rate, steps-to-completion, error-recovery rate, cost/task, and hard step/approval limits.

How to verify: run agentic tasks end-to-end against your tools; measure valid-call rate, success, steps, and recovery on tool errors (Phase 10/Phase 12).

Questions to ask: Measured valid-tool-call rate? Parallel tool calls? Multi-step coherence over long context? Reasoning available for planning? Cost per typical task (calls × price)?

What silently gets expensive/unreliable: compounding step failures; runaway loops (no step limit); invalid tool args mangling actions; long accumulated context exploding cost/latency; no error recovery.

5. Warmup Readings

6. Deep Readings and External References

7. Key Terms

8. Important Facts

• Reliability compounds: task_success ≈ r^n — 95% per step → ~60% over 10 steps. Select on per-step reliability.
• The model proposes; the application executes, validates, limits, and audits (Phase 1.00 Law 6).
• Valid-tool-call rate is the most predictive agent metric — and "tool calling: yes" doesn't guarantee it.
• Agents accumulate context → context/KV cost grows per step (Phase 2.06).
• Always set a step limit (and approval gates for risky actions) — the app's job, not the model's.
• Route by sub-role: planning→reasoning, tool steps→reliable caller, synthesis→mid, routing→cheapest.
• Cost/task = per-call cost × steps — agents are multi-call, so this can be large.
• Error recovery materially changes success — test it by injecting tool failures.

9. Observations from Real Systems

• Coding agents (Cursor, Claude Code, etc.) route planning to a strong/reasoning model and execution/edits to reliable callers, with strict step limits and approval for risky actions (Phase 11).
• Function-calling leaderboards (Berkeley BFCL) and τ-bench measure tool-call accuracy / multi-step success — closer to agent reality than chat benchmarks.
• Runaway-loop incidents (no step limit) are a classic agent failure that burns tokens and money.
• Guardrails live in the application — gateways/agent frameworks validate tool calls and enforce limits regardless of model (Phase 14).
• Compounding failure is why teams prefer slightly-pricier high-reliability callers for long tasks.

10. Common Misconceptions

11. Engineering Decision Framework

Select for agents:
  1. Filter to models with tool calling; MEASURE valid-tool-call rate on YOUR tools (Phase 1.04).
  2. Run MULTI-STEP tasks end-to-end: success rate, steps-to-done, error recovery (inject failures).
  3. Select the tool-loop model on PER-STEP RELIABILITY (it compounds) — not raw IQ.
  4. ROUTE sub-roles: planning→reasoning (04) · tool steps→reliable caller · synthesis→mid · routing→cheapest.
  5. APP GUARDRAILS (always): schema validation · step limit · approval gates (Phase 10/14).
  6. Cost model: per-call cost × expected steps; memo (3.07).

12. Hands-On Lab

Goal

Measure what actually predicts agent success: valid-tool-call rate and multi-step task success across 2 models, including error-recovery behavior.

Prerequisites

• 2–3 simple tools (e.g. calculator, mock search, a fake DB); a basic agent loop; 10 multi-step tasks; access to 2 models.

Steps

1. Define tools with JSON schemas and a small agent loop (propose call → validate → execute → append → repeat, with a step limit).
2. Valid-call rate: over many single tool prompts, measure % of calls that parse + match schema + pick the right tool/args.
3. Multi-step success: run the 10 tasks end-to-end per model; record success, steps-to-done, and total cost (calls × price).
4. Error recovery: make a tool return an error sometimes; measure whether the model adapts.
5. Compounding check: compute observed per-step reliability r and compare r^n to observed task success.
6. Decide + route: pick the loop model on reliability; consider a reasoning planner; memo it.

def run_task(model, task, tools, max_steps=8):
    state, steps = task.initial, 0
    while steps < max_steps:                       # STEP LIMIT (guardrail)
        call = model.propose_tool_call(state, tools)
        if not valid(call, tools):                 # APP validates
            state = note_invalid(state); steps += 1; continue
        result = execute(call)                     # APP executes
        state = append(state, result); steps += 1
        if task.is_done(state): return True, steps
    return False, steps

Expected output

• A table per model: valid-call rate, task-success, mean steps, cost/task, recovery rate — and confirmation that task success ≈ r^n (reliability compounds).

Debugging tips

• High valid-call rate but low task success? Multi-step coherence or error recovery is the gap, not tool syntax.
• Runaway costs? Your step limit is too high or missing.

Extension task

Add a reasoning planner that decomposes the task first, then a reliable caller executes; measure success/cost vs single-model.

Production extension

Move guardrails (validation, step limits, approval gates) into a reusable agent harness and log per-step traces — the seed of Phase 10's agent + Phase 14 controls.

What to measure

Valid-tool-call rate, multi-step success, steps-to-done, error-recovery rate, cost/task; r^n vs observed success.

Deliverables

• An agent loop with tools + guardrails.
• A 2-model reliability comparison (valid-call, success, steps, cost).
• A routing recommendation (planner vs caller) + memo.

13. Verification Questions

Basic

1. Why does per-step reliability dominate agent selection? Show the compounding math.
2. Who executes a tool call — the model or your app — and why does that matter for safety?
3. What's the most predictive single agent metric?

Applied 4. Two models: A is smarter single-shot, B has a higher valid-tool-call rate. Which for a 12-step agent, and why? 5. How do you test error recovery during selection?

Debugging 6. Your agent occasionally runs forever and racks up cost. What guardrail is missing? 7. Tool calls are valid but tasks still fail. Where's the gap?

System design 8. Design model selection + routing + guardrails for a multi-step research agent.

Startup / product 9. Explain agent cost (per-call × steps) and reliability compounding to justify a slightly pricier, more reliable caller.

14. Takeaways

1. Reliability compounds (r^n) — select agents on per-step reliability, not single-shot IQ.
2. Valid-tool-call rate is the most predictive metric — measure it; don't trust the flag.
3. The model proposes; the app executes, validates, limits, audits.
4. Route by sub-role: planning→reasoning, tool steps→reliable caller, synthesis→mid, routing→cheapest.
5. Always set step limits + approval gates (app's job).
6. Cost/task = per-call × steps — agents are multi-call.

15. Artifact Checklist

• Agent loop with tools + step-limit + validation.
• Valid-tool-call rate measurement for 2 models.
• Multi-step success + recovery comparison.
• Compounding check (r^n vs observed).
• Routing recommendation (planner vs caller) + memo.
• Notes: compounding + "app owns guardrails."

Next: 07 — Structured-Output Models