
After studying this material, you should be able to:
Imagine two students both score 80% on a test. Does that mean they learned the same way? Not necessarily — one might have genuinely understood the material, while the other guessed strategically.
The same problem applies to LLM agents.
Agent A: Accuracy = 65%
Agent B: Accuracy = 65%
Are they equivalent? ❌ NOT NECESSARILY
Two agents with identical end-to-end accuracy can exhibit completely different production behaviors:
| Hidden Behavior | What It Means | Why It Matters |
|---|---|---|
| Silent argument hallucination | Agent invents tool inputs that look valid | Produces confident wrong answers |
| Infinite tool loops | Agent keeps calling tools repeatedly | Wastes resources, may never terminate |
| Redundant retries | Agent repeats the same failed call | Inefficient, fragile in production |
| Syntactically divergent queries | Same meaning, different format | Breaks downstream systems |
Two configurations can achieve identical end-to-end accuracy while exhibiting structurally different production behaviors.
This means ranking agents by accuracy alone systematically misranks them for real-world deployment.
The protocol decomposes agent quality into three layers, each capturing a different dimension of behavior.
┌─────────────────────────────────────────────────────┐
│ AGENT EVALUATION │
├─────────────────┬──────────────────┬────────────────┤
│ ANSWER LAYER │ TRAJECTORY LAYER │ EXECUTION LAYER│
│ │ │ │
│ What did the │ How did the agent│ How reliably │
│ agent say? │ plan its steps? │ did it run? │
└─────────────────┴──────────────────┴────────────────┘
Think of it like evaluating a surgeon:
These measure the quality of the final output.
Simple binary or percentage score
Did the agent get the right answer?
Example:
Expected: "Paris"
Agent A: "Paris" → Accuracy = 1.0 ✓
Agent B: "Lyon" → Accuracy = 0.0 ✗
Measures overlap of meaning, not exact words
Combines Precision and Recall of semantic content
Example:
Expected: "The revenue increased by 15% in Q3 2024"
Agent: "Q3 2024 saw a 15% revenue growth"
Exact match: FAIL ✗
Semantic F1: HIGH ✓ (same meaning captured)
Measures directional similarity in embedding space
Range: 0.0 (unrelated) → 1.0 (identical meaning)
Useful for catching:
- Paraphrased correct answers
- Near-miss responses
- Formatting-only differences
Why all three? Each catches different failure types:
Scenario: Agent gives correct info but wrong format
Accuracy: LOW (exact match fails)
Semantic F1: HIGH (content is correct)
Cosine Sim: HIGH (meaning preserved)
Diagnosis: FORMATTING FAILURE, not reasoning failure
These measure how the agent planned and executed its reasoning steps — the sequence of tool calls it made.
Key concept: A "trajectory" is the ordered sequence of tool calls an agent makes to reach its answer.
Example trajectory for "What is the CEO's salary at Company X?":
Step 1: search_company(name="Company X")
Step 2: get_executive_info(company_id=123, role="CEO")
Step 3: get_compensation(executive_id=456)
→ Answer: "$2.3M"
Did the agent use the RIGHT TOOLS? (order doesn't matter)
Expected tools: {search_company, get_executive_info, get_compensation}
Agent tools: {search_company, get_executive_info, get_compensation}
Set Match = 1.0 ✓
Agent B tools: {web_search, get_compensation}
Set Match = 0.5 ✗ (wrong tools selected)
Did the agent use tools in the RIGHT SEQUENCE?
Expected: [search → get_executive → get_compensation]
Agent A: [search → get_executive → get_compensation] → Order Match = 1.0 ✓
Agent B: [get_compensation → search → get_executive] → Order Match = LOW ✗
Did the agent pass the RIGHT ARGUMENTS to tools?
Expected: get_executive_info(company_id=123, role="CEO")
Agent A: get_executive_info(company_id=123, role="CEO") → Args Match = 1.0 ✓
Agent B: get_executive_info(company_id=999, role="CEO") → Args Match = LOW ✗
↑
HALLUCINATED company_id!
Args Match is critical — it catches silent argument hallucination, where the agent calls the right tool but with invented parameters.
Did the agent use ALL necessary tools?
(Penalizes missing tools even if some were correct)
Expected tools: 3 tools needed
Agent used: 2 tools (skipped one)
Tool Coverage = 2/3 = 0.67
High Set Match + Low Tool Coverage = agent used correct tools BUT missed some
How many tool call failures occurred on average?
Agent A: 0 failures across 50 queries → Avg Failures/Traj = 0.0
Agent B: 75 failures across 50 queries → Avg Failures/Traj = 1.5
Includes:
- API errors
- Timeout retries
- Invalid argument rejections
- Tool loop terminations
The declining pattern matters:
Query 1: 2 failures (agent retried, eventually succeeded)
Query 25: 1 failure (agent learning/adapting)
Query 50: 0 failures (agent stabilized)
Non-zero BUT DECLINING Avg Failures/Traj = "Resilient" behavior signature
This is where the framework's diagnostic power emerges. You don't read metrics individually — you read gap patterns across layers.
Set Match: HIGH ✓
Order Match: LOW ✗
Avg Failures: Non-zero but DECLINING
Interpretation:
Agent uses correct tools but reorders them adaptively
Encounters errors but recovers
Gets right answer through flexible, self-correcting path
This is GOOD behavior — adaptive, robust
Accuracy: HIGH ✓
Set Match: HIGH ✓
Order Match: HIGH ✓
Args Match: LOW ✗
Interpretation:
Agent follows the right plan on the surface
But passes wrong arguments to tools
Gets lucky with correct answers despite bad tool calls
This is DANGEROUS — works in testing, fails in production
Accuracy: LOW ✗
Semantic F1: HIGH ✓
Cosine Sim: HIGH ✓
Interpretation:
Agent has the RIGHT KNOWLEDGE
But outputs it in wrong format
Fix: Output formatting, not reasoning
Set Match: LOW ✗
Tool Coverage: LOW ✗
Accuracy: LOW ✗
Interpretation:
Agent selects wrong tools entirely
Reasoning about WHICH tool to use is broken
Fix: Tool selection logic, not answer generation
Accuracy: LOW ✗
Set Match: HIGH ✓
Args Match: HIGH ✓
Avg Failures: HIGH ✗
Interpretation:
Agent plans correctly and argues correctly
But tools keep failing (API down, timeouts, etc.)
Fix: Infrastructure, not agent logic
Start: Agent performing poorly
│
▼
Check Answer Layer
┌────────────────────────────────┐
│ Semantic F1 high, Accuracy low?│──YES──→ FORMATTING FAILURE
└────────────────────────────────┘
│NO
▼
Check Trajectory Layer
┌──────────────────────┐
│ Set Match low? │──YES──→ TOOL MISROUTING
└──────────────────────┘
│NO
┌──────────────────────┐
│ Args Match low? │──YES──→ ARGUMENT HALLUCINATION
└──────────────────────┘
│NO
▼
Check Execution Layer
┌──────────────────────┐
│ Avg Failures high? │──YES──→ ENVIRONMENT FAILURE
└──────────────────────┘
│NO
▼
Check Order Match
┌──────────────────────────────────────┐
│ Set Match high, Order Match low, │
│ Failures declining? │──YES──→ RESILIENT (GOOD!)
└──────────────────────────────────────┘
The paper tests this framework on five agent types:
┌─────────────────────────────────────────────────────────────┐
│ AGENT CONFIGURATIONS │
├──────────────────────┬──────────────────────────────────────┤
│ Configuration │ Description │
├──────────────────────┼──────────────────────────────────────┤
│ CoT (Zero-shot) │ Chain-of-Thought, no optimization │
│ CoT (DSPy-Simba) │ CoT with automated prompt tuning │
│ ReAct (Zero-shot) │ Reason+Act loop, no optimization │
│ ReAct (DSPy-Simba) │ ReAct with automated prompt tuning │
│ CodeAgent │ Generates and executes code │
└──────────────────────┴──────────────────────────────────────┘
Chain-of-Thought (CoT): Agent reasons step-by-step before answering
Think: "First I need X, then Y, then Z"
→ Execute plan
→ Answer
ReAct: Agent interleaves reasoning and acting
Reason → Act → Observe → Reason → Act → Observe → Answer
DSPy-Simba optimization: Automated system that tunes agent prompts using examples
ToolHop Benchmark:
ReAct (DSPy-Simba): 65% accuracy ← BEST
Production Set (50 real queries):
ReAct (DSPy-Simba): 86% accuracy ← BEST
But accuracy alone doesn't explain why it wins. The eight metrics show:
ReAct (DSPy-Simba) behavioral signature:
Set Match: HIGH → Uses right tools
Order Match: MEDIUM → Adapts sequence when needed
Args Match: HIGH → Correct arguments
Avg Failures: Low but non-zero, declining → Self-corrects
= RESILIENT signature
CoT (Zero-shot) vs CoT (DSPy-Simba):
Accuracy: Improves ✓
Semantic F1: Improves ✓
Args Match: Improves ✓ ← DSPy fixes syntax
Order Match: No change ✗ ← DSPy can't fix planning
Interpretation:
DSPy optimization patches FORMATTING problems in CoT
But cannot unlock ADAPTIVE REASONING
CoT is a "static planner" — it commits to a plan upfront
and cannot adapt when tools fail or return unexpected results
This is the "glass ceiling" — optimization improves surface compliance but hits a structural limit.
Synthetic benchmark (ToolHop):
ReAct shows: High Set Match, variable Order Match, declining failures
Real production queries (50 enterprise queries):
ReAct shows: SAME PATTERN
Conclusion: The behavioral signature is STABLE across contexts
Benchmark findings predict production behavior
This validates the protocol — metrics measured on benchmarks predict real deployment behavior.
The protocol is implemented as a stateful metric callable — a measurement system that:
Traditional evaluation:
Run agent → Get answer → Score answer → Done
Stateful metric callable:
Run agent → Capture full trace → Store trace → Score later
↑
Can re-score with NEW metrics
against OLD logged traffic
Why this matters: If you define a new metric tomorrow, you can apply it to yesterday's traffic without re-running the agent.
Agent execution produces:
┌─────────────────────────────────────┐
│ TRACE │
│ - Tool call 1: name, args, result │
│ - Tool call 2: name, args, result │
│ - Failures: timestamps, types │
│ - Final answer: text │
└─────────────────────────────────────┘
│
▼
Trace-extraction harness
(decouples measurement from deployment)
│
▼
Eight-metric scorer
The harness decouples measurement from deployment — you can score traces from any agent, any deployment, retroactively.
┌─────────────────────────────────────────────────────────────────┐
│ EIGHT-METRIC EVALUATION PROTOCOL │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ANSWER LAYER TRAJECTORY LAYER EXECUTION LAYER │
│ ┌─────────────┐ ┌─────────────────┐ ┌─────────────┐ │
│ │ 1. Accuracy │ │ 4. Set Match │ │ 8. Avg │ │
│ │ 2. Sem. F1 │ │ 5. Order Match │ │ Failures │ │
│ │ 3. Cos. Sim │ │ 6. Args Match │ │ /Traj │ │
│ └─────────────┘ │ 7. Tool Coverage│ └─────────────┘ │
│ └─────────────────┘ │
│ │
│ READ JOINTLY → Identify gap patterns → Diagnose failure mode │
│ │
│ Failure Modes: │
│ • Resilient Self-Correction (GOOD) │
│ • Compliant-but-Fragile Planning (DANGEROUS) │
│ • Formatting-Only Failures (EASY FIX) │
│ • Tool Misrouting (TOOL SELECTION BROKEN) │
│ • Execution Environment Failures (INFRASTRUCTURE) │
└─────────────────────────────────────────────────────────────────┘
| Concept | Core Idea |
|---|---|
| Single-metric failure | Accuracy alone misranks agents with structurally different behaviors |
| Three layers | Answer (what), Trajectory (how), Execution (reliability) |
| Eight metrics | Each captures a distinct behavioral dimension |
| Gap patterns | Differences between metrics localize specific failure modes |
| Resilient signature | High Set Match + variable Order Match + declining failures = adaptive, robust agent |
| Glass ceiling | Optimization can fix syntax but not structural reasoning limitations |
| Transferability | Behavioral signatures measured on benchmarks predict production behavior |
| Retroactive scoring | Trace-based measurement enables re-scoring historical traffic |
Two agents both achieve 70% accuracy. Agent A has high Semantic F1 but low Accuracy. Agent B has matching Accuracy and Semantic F1. What does this tell you about each agent?
An agent shows: Set Match = 0.9, Args Match = 0.3, Accuracy = 0.7. What failure mode is likely occurring? What should you fix?
Why is a "non-zero but declining" Avg Failures/Traj considered a positive behavioral signature?
What is the "glass ceiling" finding for CoT agents, and why can't DSPy optimization overcome it?
Why does decoupling measurement from deployment (via trace extraction) matter for production systems?