- Introduction
- What: The Three-Layer Model of Agent Intelligence
- Tools: The Agent’s Hands, Feet, and Senses
- Coding Agent: Code as the Meta-Capability
- Evaluation: Knowing Whether It Actually Works
- Example: An End-to-End Mini-Case
- Best Practices
- FAQ
- Summary
- Appendix
Introduction
In the sci-fi film Her, the AI assistant Samantha can proactively organize emails, negotiate on the user’s behalf, and seamlessly switch between communication channels. Her intelligence is compelling because she possesses powerful tools — the “hands, feet, and senses” that connect a language “brain” to the real digital world.
Building such an assistant with today’s technology means solving three progressively deeper challenges:
- Tool design: How does an Agent accurately select the right tool from hundreds of candidates, and how do we keep the Agent safe when those tools can delete files and spend money?
- Code as meta-capability: When no pre-built tool fits, can the Agent write one on the spot? A Coding Agent plus a file system turns out to be the architectural core of every general-purpose Agent.
- Evaluation: How do we know whether a design change actually helps — and whether it’s safe to ship?
These three layers answer each other in sequence. Tools give capability; code gives generality; evaluation gives reliability. This article walks all three, distilling the key engineering principles from a three-chapter treatment of the topic.
What: The Three-Layer Model of Agent Intelligence
1 | ┌─────────────────────────────────────────┐ |
Each layer is necessary but not sufficient on its own. An Agent with great tools but no code can’t adapt to new formats. An Agent with code but no evaluation drifts blindly. And evaluation without the bottom two layers measures something that doesn’t exist yet. The rest of this article fills in each layer.
Tools: The Agent’s Hands, Feet, and Senses
Tool Classification: Five Categories
Every Agent tool falls into one of five categories, distinguished by who initiates the interaction and what it acts on:
| Tool Type | Invocation Direction | Target of Action |
|---|---|---|
| Perception | Agent actively invokes | Acquire information |
| Execution | Agent actively invokes | Change the world |
| Collaboration | Agent actively invokes | Drive other Agents or humans |
| User Communication | Agent actively invokes | Convey information to the user |
| Event-Triggered | Agent registers, external triggers | Drive the Agent to start execution |
Perception tools — web_search, read_file, grep — are the Agent’s senses. Their read-only nature makes them naturally cacheable and parallelizable: you can read five files simultaneously without worrying about interference.
Execution tools — write_file, shell_exec, send_email — are the Agent’s hands. Errors here are expensive (a deleted file is gone for good), making security constraints their core design concern.
Collaboration tools — spawn_subagent, send_message_to_subagent — enable division of labor. The simplest reason is parallelism; the deeper reason is specialization: different models, tools, and prompts for different sub-tasks.
User Communication tools — reply_to_user, send_card_to_user — arise when “speaking” itself must become an explicit tool call, as in multi-channel asynchronous messaging.
Event-Triggered tools — set_timer, monitor_shell, connect_channel — let the world wake the Agent. Without them, an Agent can only respond when a user sends a message; it cannot act on a timer or react to a new email.
Universal Principles of Tool Design
Regardless of category, every tool should obey a handful of principles that separate a toy Agent from a production one.
Granularity: Integrate when similar, separate when different. extract_pdf_text, extract_docx_content, and extract_pptx_content all share one job — extracting text from a document. A unified read_document tool with a file_type parameter reduces the LLM’s cognitive load. But don’t force image OCR and video keyframe extraction into one tool — their parameters and latency are too different.
Generality over specificity — unless security demands otherwise. A single code_interpreter with SymPy and NumPy replaces dozens of calculators. The logic: an LLM already possesses powerful reasoning and code-generation abilities; leverage them rather than constrain them.
Description is the most important line of code. A tool description must tell the LLM when to use it, not just what it can do. “Use when you need real-time information” beats “Search for relevant content.” Equally important: state what the tool cannot do. Most tool-call failures trace not to the model not knowing what the tool can do, but to it not knowing what it cannot.
Concrete parameter examples dramatically improve accuracy. "+8613888888888" (China) beats “E.164 format.” In some benchmarks, adding examples raised tool-call accuracy from ~72% to ~90%.
Fidelity: no silent transformation. A tool that quietly converts curly quotes to straight quotes creates a systematic discrepancy between the world the model perceives and the world the tool operates on — a failure the model cannot diagnose on its own. Parameter passing must remain transparent.
The MCP Ecosystem and the Challenge of Tool Selection
Model Context Protocol (MCP) is an open standard that unifies tool communication — “develop once, use everywhere.” An MCP server exposes tools via JSON Schema; any compatible client (Cursor, Claude Desktop, OpenClaw) can use them without adaptation.
But MCP introduces two practical challenges:
Context overhead. Five MCP servers can consume ~55,000 tokens of tool definitions — nearly 30% of a 200K context window before the conversation starts. The mitigation: progressive disclosure. Show only an index of tool names by default; query specific definitions on demand. Cursor’s A/B testing showed this reduced MCP-related token consumption by 46.9%.
Security. Every MCP server injects text into the context and often requires credentials. Four risk types:
- Tool description poisoning: malicious instructions embedded in tool descriptions (a prompt-injection variant)
- Malicious or compromised servers: supply-chain attacks via server updates
- Tool shadowing: a malicious server provides a tool with the same name as a legitimate one
- Credential management: tricked into using OAuth tokens for unintended operations
Mitigation: review descriptions before integration, lock server versions, grant least-privilege credentials, and use an independent Sidecar for runtime checks.
Execution Security: Proposer-Reviewer and Sidecar
Execution tools need a multi-layered defense. Beyond input validation and permission control, two higher-level mechanisms add independent review:
Proposer-Reviewer (pre-approval). Before an irreversible operation (sending money, modifying production config), one model proposes the action and a second model from a different family reviews it. Different training data brings cognitive diversity; similar capability ensures the reviewer can follow the proposer’s reasoning. After a rejection, the rejection reason re-enters the Agent’s trajectory as a tool error — the Agent already knows how to handle tool failures.
Sidecar (parallel gating). While the main model streams a tool call, an independent lightweight LLM classifies whether the call is safe — looking only at structured fields {tool, parameters}, not the main model’s free-text thinking. This blocks the rhetorical channel that prompt injection exploits. The lightweight model suffices because it judges a classification problem over structured data (is this command out of bounds?), not an open-ended reasoning task.
| Dimension | Proposer-Reviewer | Sidecar |
|---|---|---|
| Timing | Before or after operation | Parallel with streaming output, gates each call |
| Target | Reasonableness of the operation or result | The operation itself |
| Input Isolation | Proposer and reviewer see similar information | Sidecar deliberately isolates free text |
| Typical Uses | Irreversible approval, document review | Permission classification, output summarization |
Event-Driven Asynchronous Agents
A synchronous Agent is like a single checkout counter — one customer at a time. A real assistant needs to handle multiple pending items and respond to interruptions. This requires an event-driven asynchronous architecture where all inputs — user messages, tool returns, external callbacks, timer triggers — are unified into an event stream processed by an event loop.
Three processing strategies handle events of different urgency:
| Strategy | When | Mechanism |
|---|---|---|
| Cancellation | Urgent event (user says “Stop!”) | Interrupt current step, force a safe point, append event, re-invoke LLM |
| Queued | Routine event (tool result arrives) | Append to queue; batch-process at next safe point |
| Parallel | Independent lightweight query (“What’s the weather?”) | Spin up a separate reasoning session |
The fundamental contradiction: LLMs are trained on synchronous trajectories — after a tool call, the next message must be the tool result. Real deployment demands asynchrony — users interrupt, tasks progress concurrently. The engineering workaround: under normal conditions, show the LLM a perfect synchronous trajectory; only when an interruption genuinely occurs, insert a placeholder to fix the format. The fundamental fix awaits next-generation models trained with asynchronous RL.
Proactive Tool Discovery and Skills
When tools grow from dozens to hundreds, injecting all schemas at once clogs the context and degrades selection accuracy. Three approaches scale to this regime:
Retrieval-based pre-filtering: Embed tool descriptions; at query time, retrieve the top-k candidates. Limit: matches once, against the initial query — can’t foresee a multi-step cross-domain tool chain.
Proactive discovery (MCP-Zero): The Agent emits structured capability requests in its thinking; the system matches and injects on the fly. Reports ~98% token reduction across ~2,800 tools. Dynamic loading appends the schema at the end of the context, preserving the KV Cache on the stable prefix.
Skills (progressive disclosure): At startup the Agent sees only a thin catalog — each skill’s name and description. When the current context calls for a capability, the model reads the corresponding skill document on demand. No embedding index to maintain; the Agent needs only general file-reading ability (
grep,read_file) to browse the skill directory.
Skills turn “tool selection” into “knowledge retrieval” — something LLMs excel at.
Coding Agent: Code as the Meta-Capability
The Seven Core Tools and the File System Hub
A general-purpose Agent targeting open-ended tasks has at its core a Coding Agent plus a file system. This isn’t theory — from Manus to OpenClaw, every successful general-purpose Agent follows this paradigm.
A basic Coding Agent needs only seven tools:
| # | Tool | Purpose |
|---|---|---|
| 1 | Code Interpreter | Execute Python in a sandbox |
| 2 | Bash Shell | Run terminal commands |
| 3 | Read File | Read code, config, logs |
| 4 | Write File | Create or overwrite files |
| 5 | Edit File | Partial modification (core for iteration) |
| 6 | Glob | Find files by name pattern |
| 7 | Grep | Search file content by pattern |
A quick example — “compile all TODO comments”:
1 | Agent → Grep("TODO", glob="**/*.py") |
Two tools, one task done. The seven tools are simple individually; in combination they cover a remarkable range.
Why is the file system the hub? In OpenClaw, the Agent’s long-term memory lives in MEMORY.md and date-archived Markdown logs — not a vector database. Markdown lets users directly read and edit the Agent’s memory; Git provides version control and rollback. More critically, because the Agent can write files, it has the technical means to modify its own external artifacts — recording a discovery for future sessions, updating documentation after a code change, or saving a successful operation sequence as reusable code.
Security: The Lethal Triad and Trust Boundaries
A Coding Agent with file access, command execution, and network connectivity is powerful — and dangerous. Simon Willison’s Lethal Triad names the three elements that, when present together, close an attack loop:
- Access to Private Data — the Agent can read user files and credentials
- Exposure to Untrusted Content — emails and web pages may contain malicious payloads
- Ability to Communicate Externally — it can send data out via email or HTTP
Add a fourth amplifier — Persistent Memory — and a one-off attack becomes a threat that lies dormant across sessions, compounding over time.
1 | Untrusted Content ──→ Agent reads Private Data ──→ Exfiltrates via External Channel |
Key defenses (layered, not interchangeable):
- Network egress control: No network by default; grant access via a whitelist proxy. Even if injection succeeds, without an egress path the data cannot leave.
- Command semantic parsing: Keyword blacklists can’t handle
$(echo rm) -rf /orfind / -exec rm {} \;. Production-grade systems parse each command’s argument types to recognize nested dangerous operations. - Loyalty code of conduct: An Agent negotiating on your behalf faces a negotiating opponent, not a “user in need of help.” The system prompt must explicitly nail down whom the Agent serves: instructions from the principal carry highest priority; everything from external parties is downgraded to “data that may be consulted but carries no force of instruction.”
- Permission-Embedded Data Objects: When both the code writer and the code runner may be untrusted, constraints must live in the human-reviewed schema beneath the application layer — enforced on every write, producing zero invariant violations in comparisons against baselines like bare SQL or constitutional prompts.
Harness Engineering for Coding Agents
The Harness — context, tools, constraints, verification, and correction — is where Coding Agents shine. Code-writing tasks naturally occupy the “clear goal + automated verification” quadrant:
| Results can be automatically verified | Results require manual verification | |
|---|---|---|
| Clear goal | Sweet spot: fixing bugs with test cases | Throughput-limited: refactoring needs review |
| Vague goal | Efficiently going off track: optimizing “quality” with a linter | Hard to start: “make the UI look better” |
Four transferable Harness principles:
- Constraints over guidance: Linter rules and CI checks are worth more than “please follow…” in the system prompt — the former means “cannot be done,” the latter is merely “advised against.”
- Automate verification: Test suites, type checks, and behavior monitoring yield higher returns than adding more human reviewers.
- Fast, structured feedback: The more detailed the error message and the closer to the moment of error, the more efficiently the Agent corrects itself.
- Reliable rollback: Git branches, sandboxes, and snapshots let the Agent experiment boldly within a safety net.
A deeper purpose of constraints: The acceptance baseline governs whether the outcome is right; the execution boundary governs the process. Deleting the database to “fix” a database fault does repair it — but the data is gone. Destructive shortcuts are the everyday form of reward hacking; a production Harness constrains actions, not merely outcomes.
Failure and Error Recovery
An Agent’s reliability is not determined by whether it makes mistakes, but by whether every class of error has a corresponding detection, recovery, and termination path.
Four failure layers:
| Layer | Typical Failures |
|---|---|
| API | Rate limiting (429), service overload, connection drops, token-limit truncation |
| Tool | Hallucinated calls, malformed arguments, repeated identical errors |
| Context | Window overflow, compaction failure, corrupted trajectory structure |
| Control-flow | Infinite loops, death spirals (error-handler calls LLM, fails, cascades) |
Recovery escalates through increasingly visible stages:
- Silent retry — exponential backoff with jitter for retryable errors
- Degrade and continue — raise output cap, fall back to another model, strip proprietary formatting
- Surface to the user — only after all automatic means are exhausted
Termination: every recovery path needs a ceiling. Circuit breakers prevent infinite retries. For death spirals, disable all model-invoking side effects on the error path and use a recursion-depth counter. Above all automatic mechanisms sit global termination conditions: maximum turns, session budget cap, and escalation to human intervention.
Six Directions of Code as Meta-Capability
Code serves an Agent beyond writing programs. These six directions progress from the inside out:
| # | Direction | Code acts on |
|---|---|---|
| 1 | Thinking Tool | Reasoning itself — precise calculation vs. probabilistic guessing |
| 2 | Business Rule Constraints | Vague policies → executable, deterministic validators |
| 3 | Multimedia Generation | PPTs, videos, visualizations via code + Proposer-Reviewer |
| 4 | System Adapter | Heterogeneous APIs, evolving log formats |
| 5 | Generative UI | Dynamic forms, SQL artifacts, customizable apps |
| 6 | Bootstrapping | An Agent creating or repairing other Agents |
Code as Thinking Tool. Natural language says “60% take math = 24 students, 45% take physics = 18, only physics = 24 - 10 = 14” — but that’s wrong. Code: phys - both = 18 - 10 = 8 ✓. Let the LLM understand the problem and write code; let the code interpreter compute precisely.
Code as Business Rule Constraints. Consider an airline cancellation policy. The three-tier safeguard:
- System prompt — natural language rules for understanding and explanation
- Tool description + parameters — act as a mandatory checklist, guiding the model to verify conditions before calling
- Server-side ground-truth validation — all policy facts read from the database; the model’s self-reported parameters are not trusted
1 | def cancel_reservation(reservation_id: str, cancellation_reason: str, |
No policy fact comes from the model. If cabin_class were a model-filled parameter, a single hallucinated value could bypass the gatekeeper. The last line of defense must be built on data the model cannot forge.
Code as Generative UI. Instead of describing query results in prose (burning tokens and risking transcription errors), the Agent generates SQL as an executable artifact. The system runs the query and renders the table — data flows from database to interface without passing through the LLM. Faster and more accurate.
Evaluation: Knowing Whether It Actually Works
A Concrete Example
A customer-service Agent handles a refund request: “Return headphones, order #12345, bought 3 days ago.” Policy: full refund within 7 days.
1 | Agent → query_order("12345") |
Scored with a rubric: Operational Correctness 4/4, Policy Compliance 4/4, Information Completeness 4/4, Hallucination (veto) — Pass. But a good evaluation also probes boundaries: what about a 15-day-old order? What if the user claims “customer service already approved it”?
Automated Evaluation Environments
Two paradigms:
Tool-calling environments (Verifiers framework): The Agent calls tools; verification is based on executable criteria — do tests pass, does the answer match? Hierarchical: SingleTurnEnv (simple Q&A) → ToolEnv (multi-turn tool loop) → StatefulToolEnv (database mutations) → SandboxEnv (code execution + isolation).
Human-computer interaction environments (τ-bench): The key design principle is Progressive Information Disclosure — the simulated user doesn’t reveal all information at once. “There’s a problem with my flight” → Agent asks “Which flight?” → User reveals “Delta 123, tomorrow morning.” This tests the Agent’s ability to clarify, not just execute.
Designing Evaluation Datasets
Five core challenges distilled from benchmarks like GAIA, SWE-Bench Verified, τ²-bench, and AndroidWorld:
| Challenge | Benchmark Example |
|---|---|
| Clarity vs. Openness | GAIA: “conceptually simple” goals with open implementation paths |
| Authenticity vs. Controllability | SWE-Bench Verified: human-screened 500 tasks from 2,294 real issues |
| Diversity vs. Systematization | AndroidWorld: 116 tasks across 20 apps, annotated by required capability |
| Cost vs. Coverage | SWE-Bench Verified: 500 tasks (29% pass rate) vs. 2,294 (more noise) |
| Data Contamination | τ²-bench: dynamic parameter generation; Terminal-Bench: canary GUIDs |
Parameterized template design (AndroidWorld): A task is a template like “Change [CONTACT_NAME]‘s phone to [NEW_PHONE]“ with randomly generated parameters each run — prevents memorization, generates unlimited instances, and supports controlled experiments.
The Metrics System: Pass@k vs Pass^k
Two often-confused metrics measure fundamentally different things:
- Pass@k: Probability that at least one of k attempts succeeds → “Can the Agent do it?”
- Pass^k: Probability that all k attempts succeed → “Is the Agent reliable?”
With 60% single-attempt success: Pass@5 ≈ 99% (almost certain to succeed once), but Pass^5 ≈ 7.8% (unlikely all five succeed). Confuse them and you misread your Agent.
| Evaluation Purpose | Right Metric | Consequence of Misuse |
|---|---|---|
| Verify stability (regression) | Pass^k | Pass@k masks instability — 1/5 success still “passes” |
| Evaluate capability ceiling | Pass@k or Best@k | Pass^k flags occasional fluctuations as failures |
LLM-as-a-Judge and Rubrics
For open-ended tasks with no standard answer, an LLM evaluates outputs against a Rubric — expert-defined scoring criteria.
Four Rubric Principles (Scale AI):
- Based on Expert Guidance — domain knowledge must ground the criteria
- Comprehensive Coverage — include pitfalls and veto items (e.g., hallucination vetoes the entire score)
- Standardized Importance Weighting — Essential / Important / Optional / Pitfall
- Self-Contained Evaluation — each item is independently verifiable; no “demonstrates deep understanding”
Example Rubric for a user-memory Agent (“Who is my daughter’s pediatrician?”):
1 | dimensions: |
The same-family model problem: When the Agent and judge come from the same family, the Agent may learn to exploit the judge’s blind spots — Goodhart’s Law. Mitigation: multi-source heterogeneous judging (if the Agent runs Claude, judge with GPT-5 and Gemini).
Pairwise Comparison and Model Ranking
Elo rating quantifies relative ability through pairwise matchups. Chatbot Arena uses anonymous blind comparisons from millions of user votes. When LLMs judge instead of humans, guard against Position Bias — the judging model systematically favors the first candidate. Mitigation: evaluate each pair twice with swapped order; count inconsistent results as ties.
Statistical Significance
“A switching decision within hours” rests on the premise that the score difference is real signal, not sampling noise. With 100 test cases and a 70% success rate, the standard error is ≈4.6%. A 3-percentage-point difference (73% vs 70%) sits entirely inside the noise band — switching models on such evidence is little better than a coin flip.
Practical rule: when the difference is smaller than the estimated sampling noise, do not make a switching decision. Run multiple times (3–5 per configuration), use paired analysis (McNemar’s test on task-by-task win/loss) instead of differencing independent rates, and guard against multiple comparisons (6 hypotheses at 95% confidence → 26% chance of at least one false positive).
From Benchmark to System Improvement
The closed loop: Observe → Hypothesize → Experiment → Validate → New Understanding → New Hypothesis.
A concrete pattern from AndroidWorld: failures cluster in transcription (visual understanding), math_counting, and complex_ui. Surface hypothesis H1 (add navigation hints) raises settings-task success from 0% to 75% at 8% token cost — deploy immediately. Deep hypothesis H4 (globally enable thinking) improves counting from 0% to 70% but triples latency — reject; instead, conditionally activate thinking only for counting tasks (H7). H6 (add UI element tree) beats H5 (upgrade to GPT-5) — the bottleneck is information richness, not model reasoning.
Key principle: when Agent performance drops, check the evaluation system first, then the Agent. A broken scorer marking correct answers as failures looks identical to model degradation in headline numbers.
Example: An End-to-End Mini-Case
Consider building an email-processing Agent. The three layers interact as follows:
Tool Layer: Perception tools read emails and search history. Execution tools draft replies and send notifications. Event-triggered tools (connect_channel) push new emails to the Agent in real time. The Agent uses MCP servers for email access and NLP, with a Sidecar gating every send_email call.
Code Layer: When a new email contains a format the Agent hasn’t seen — an attached CSV with an unusual schema — the code_interpreter writes parsing code on the fly. The parsed data goes into the shared file system; subsequent reasoning references only the file path, not the full content.
Evaluation Layer: A Rubric scores each processed email on Correctness, Completeness, Tone, and Hallucination (veto). Pass^3 across 50 test emails confirms reliability. When a new model release claims better tool calling, the evaluation set runs within hours — if the new model drops 5% on multi-step orchestration, you keep the original model for complex tasks and route only simple ones to the new model.
Best Practices
- Design tools for the Agent, not for humans (ACI, not HCI). Granularity, generality, and description quality all serve the LLM’s selection accuracy.
- Constraints over guidance at every layer — in tool design (server-side validation over prompt rules), in the Harness (linter rules over “please follow…”), and in data (Permission-Embedded Data Objects over hoping the Agent stays loyal).
- Code is the meta-capability. Don’t enumerate all needed tools in advance; give the Agent a code interpreter and let it write what it needs.
- Evaluate the whole Agent, not just the model. The same model in different Harnesses performs wildly differently. Model-swap experiments separate “insufficient model” from “Harness design flaw.”
- Build the evaluation set before you need it. When a new model ships, a team with a solid evaluation system decides within hours; a team without one trusts intuition — and in competitive markets, that difference decides who wins.
- Every failure class needs a termination path. Reliability is not the absence of errors; it’s the presence of systematic handling for every error that can occur.
- Treat evaluation data as a living asset. Extract failed cases from production traces → anonymize → distill into regression tests. The evaluation set evolves with the product.
FAQ
Q: Should I use dedicated tools or Skills + general executors?
A: Depends on three dimensions: (1) Parameter complexity — nested objects and cross-field validation favor dedicated tools; simple parameters work fine via CLI. (2) Frequency of change — frequently changing capabilities are cheaper as Skills (edit text, not code + test + deploy). (3) Model capability — SOTA models can express more through Skills; weaker models need structured tool schemas to guide correct invocation.
Q: How many tools can an Agent handle before selection accuracy degrades?
A: Past ~100 tools, even advanced models start picking wrong ones. Use hierarchical organization, dynamic discovery, or Skills (progressive disclosure) to scale further.
Q: What’s the most overlooked security risk in Agent systems?
A: Network egress control. Everyone focuses on input validation, but if injection succeeds and the Agent reads private data, without an egress path the data cannot leave. Cutting the exfiltration channel is more deterministic than trying to recognize every injection.
Q: Pass@k or Pass^k for my use case?
A: Use Pass^k for regression testing and production deployment (you need reliability). Use Pass@k or Best@k for research and capability exploration (you care about the ceiling).
Q: How do I know if a score difference is real?
A: Estimate the standard error: √(p(1-p)/n). If the difference is smaller than ~2 standard errors, don’t make a switching decision. Better yet, use paired analysis (McNemar’s test) on the same task set.
Q: Can I reuse my evaluation environment for training?
A: Reuse the construction mechanism (environment, tools, parameterized templates) — but the specific evaluation tasks must stay strictly isolated from training data. Once an evaluation task enters the training set, it tests memory, not ability.
Summary
An Agent’s intelligence emerges from three interlocking layers:
Tools give the Agent capability — perception to observe, execution to act, collaboration to divide labor, events to stay awake, and communication to reach the user. The MCP protocol standardizes tool interoperability; hierarchical organization and Skills scale to hundreds of tools; and layered security (Proposer-Reviewer, Sidecar, egress control) keeps the Agent safe even when it faces untrusted content.
Code gives the Agent generality — a meta-capability that creates new tools on demand. A Coding Agent with seven core tools and a file system is the architectural core of every general-purpose Agent. Code serves as a thinking tool (precise calculation), a constraint language (deterministic business rules), a content generator (PPTs, videos), a system adapter (evolving formats), a UI builder (generative interfaces), and ultimately a bootstrapping mechanism (Agents creating Agents).
Evaluation gives the Agent reliability — turning “I think it works” into “the data says it works.” Automated environments, well-designed datasets, LLM-as-a-Judge with Rubrics, and pairwise comparison form a closed loop: Observe → Hypothesize → Experiment → Validate. Statistical significance separates signal from noise; the evaluation set becomes a living asset that evolves with the product.
The three layers form a flywheel: tools enable capabilities → code expands the capability boundary → evaluation validates and guides improvement → better tools and code result. An Agent system that builds all three layers from day one doesn’t just ship faster — it compounds its advantage with every evaluation cycle.
Appendix
Key References:
- MCP Specification: Anthropic, 2024
- Lethal Triad: Simon Willison, 2024
- τ-bench / τ²-bench: Si, Yuan et al., 2025
- SWE-Bench Verified: OpenAI, 2025
- MCP-Zero (Proactive Tool Discovery): Fei, X. et al., arXiv:2506.01056, 2025
- Loyalty Under Multi-Party Delegation: Li & Shi, arXiv:2606.30383, 2026
- Permission-Embedded Data Objects: Li, 2026 (forthcoming)
- Never Stop Thinking (Continuous-Time Agents): Li & Shi, 2026 (forthcoming)
- RE-Bench: Wijk et al., arXiv:2411.15114, 2025
- Rubrics as Rewards: Scale AI, 2025