Articulate. Reliability log The research Who solves it Home
← back to the reliability log
Reliability log · v2 · Who solves it

Who Solves the "Agent Asserts False Completion" Problem Best

Question: Who solves the "AI agents assert false/unverified completion" + reliability/verification problem best today, exactly how, and what is a solo AI-marketing operator (Claude-based agent stack, client deliverables) likely missing?

Compiled: 2026-06-19. Every claim below is grounded in a datable 2024–2026 source listed in Sources. Where a claim could not be independently verified it is flagged inline.

The core failure being solved

Agents emit a confident "done" that is not grounded in any check. The mature field treats this as an evaluation and verification problem, not a prompting problem. The single most repeated principle across every serious player below: don't trust the model's self-report — get ground truth from the environment, and grade against it. Anthropic states it directly — "it's crucial for agents to gain 'ground truth' from the environment at each step (such as tool call results or code execution) to assess progress" (Writing effective tools for AI agents, Anthropic Engineering, 2025).

1. WHO SOLVES IT BEST — leading approaches, named

A. Frontier labs' own agent-reliability practice

Anthropic — eval-driven tool/agent development + tiered grading. Method: Re-orient from deterministic to non-deterministic development; build evals from real-world tasks first, then iterate prompts/tools against measured results. Their Jan 2026 "Demystifying evals for AI agents" lays out three grader tiers — (1) code-based unit tests / static analysis (deterministic), (2) model-based rubric & pairwise scoring (LLM-judge, calibrated), (3) human SME review — plus trajectory-vs-outcome metrics and "evals as CI." - Source: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents - Source: https://www.anthropic.com/engineering/writing-tools-for-agents

Anthropic — multi-agent review with verification in production. Claude Code's Code Review dispatches multiple agents in parallel on each PR; internally "fewer than 1% of findings were marked incorrect by engineers." Demonstrates verifier-as-product, not verifier-as-aspiration. - Source: https://www.infoq.com/news/2026/04/claude-code-review/ - Source: https://www.anthropic.com/engineering/multi-agent-research-system

OpenAI — Agents SDK: guardrails + tracing + human-in-the-loop as first-class. Input/output guardrails run validation in parallel with execution; built-in tracing for debugging/monitoring; built-in mechanisms to pause for human approval mid-run; integrates with OpenAI Evals. - Source: https://openai.github.io/openai-agents-python/

(Google DeepMind: no single canonical production "agent-reliability practice" post surfaced in this pass that matches the specificity of the Anthropic/OpenAI engineering writing. Flagged as not independently verified here — do not cite a specific DeepMind method without a direct source.)

B. Eval / observability tooling

Braintrust — evaluation-first. Strongest for systematic pre-deployment experiments: define a dataset, run prompt/model variations against it, compare side by side. Tracing/logging present but the experiment framework is the differentiator. - Source: https://www.braintrust.dev/articles/best-llm-evaluation-platforms-2025

LangSmith (LangChain/LangGraph) — path of least resistance for tracing if you're in that stack: one env var instruments chains, agents, tool calls automatically. Value drops sharply off-stack. - Source: https://latitude.so/blog/best-llm-observability-tools-agents-latitude-vs-langfuse-langsmith

Arize Phoenix — open-source observability with research-backed metrics. Built-in eval metrics, drift detection, trace analytics; 50+ metrics covering faithfulness, relevance, safety, toxicity, hallucination. - Source: https://arize.com/llm-evaluation-platforms-top-frameworks/

Langfuse — strongest free / self-hosted option. Prompt management, call logging, annotation workflows at no cost — relevant for a solo operator avoiding per-seat SaaS. - Source: https://www.firecrawl.dev/blog/best-llm-observability-tools

Galileo / OpenAI Evals / Humanloop sit in the same field (agent simulation, monitoring, human-in-the-loop review). Treat the category as "tracing + a labelled dataset + experiment runner," not any single brand. - Source: https://www.getmaxim.ai/articles/5-ai-observability-platforms-compared-maxim-ai-arize-helicone-braintrust-langfuse/

Who's strongest, and why: for a solo operator the honest ranking is Braintrust (eval rigor) ≈ Langfuse (free, self-host) > LangSmith (only if in LangChain) > Phoenix (heavier, ML-monitoring heritage). The strength that matters is the experiment + labelled-dataset loop, not the dashboard.

C. The evals-practitioner school ("look at your data")

Hamel Husain & Shreya Shankar — error analysis + validated LLM judges. Method: stop "vibe checking." Read real traces, open-code failures into categories (error analysis), build task-specific evals (not generic metrics), and validate the LLM judge against human labels before trusting it. LLM-judge evaluators need 100+ labelled examples and ongoing maintenance — build them only for failures you'll iterate on repeatedly. - Source: https://hamel.dev/blog/posts/evals-faq/ - Source: https://hamel.dev/blog/posts/evals-faq/why-is-error-analysis-so-important-in-llm-evals-and-how-is-it-performed.html - Source (podcast, Oct 2025): https://www.lennysnewsletter.com/p/evals-error-analysis-and-better-prompts

Shreya Shankar — "Who Validates the Validators?" / EvalGen / criteria drift (UIST 2024). Core insight: you can't fix the criteria before grading, because grading the outputs is how you discover the criteria ("criteria drift"). EvalGen generates candidate graders (code assertions + LLM-judge prompts) and aligns them to a human-graded subset. - Source: https://arxiv.org/abs/2404.12272

Eugene Yan — task-specific evals + eval-driven development. "Task-Specific LLM Evals that Do & Don't Work" (Mar 2024); "An LLM-as-Judge Won't Save the Product — Fixing Your Process Will" (Apr 2025): evals are a practice (scientific method + eval-driven dev + output monitoring), not a one-off artifact. - Source: https://eugeneyan.com/writing/evals/ - Source: https://eugeneyan.com/writing/eval-process/ - Source: https://eugeneyan.com/writing/llm-evaluators/

Measuring judge-vs-human agreement is a real, reportable discipline: Cohen's kappa for categorical agreement (0.3–0.5 is only "fair"; substantial alignment looks like ~0.8+), plus true-positive / true-negative rates per judge. - Source: https://arxiv.org/html/2606.00093 - Source: https://medium.com/@saschametzger/3-metrics-to-judge-your-llm-as-a-judge-c0c98c185068

D. Verifier / deterministic-check approaches

RLVR (Reinforcement Learning with Verifiable Rewards). Reward comes from an automated, rule-based verifier, not human preference: code validated by unit tests, math by symbolic checkers, factual QA by exact-match/programmatic validators. This is the training-time version of the same instinct the operator already has at runtime: a deterministic gate decides pass/fail, the model doesn't grade itself. - Source: https://www.emergentmind.com/topics/reinforcement-learning-with-verifiable-rewards-rlvr - Source: https://github.com/opendilab/awesome-RLVR

Transferable runtime lesson: wherever a check can be deterministic (a number is right, a file exists, a link resolves, a dimension matches), use a deterministic verifier — it's cheaper and more reliable than an LLM judge. Reserve LLM judges and humans for the genuinely subjective.

E. Agent-harness design (context engineering, single-thread, human interrupts)

Cognition — "Don't Build Multi-Agents" (Walden Yan, June 2025). Strongest stated position against multi-agent designs. Reliability comes from context engineering: a single agent owns the full context; ephemeral subagents run in fresh windows, do one isolated task, and return a single summary string — no peer-to-peer channel, no shared mutable state. Naive multi-agent setups fail because sub-agents lack each other's context and make conflicting decisions. - Source: https://cognition.ai/blog/dont-build-multi-agents

Anthropic — multi-agent research system (June 2025). The counterweight: multi-agent can work for parallelisable search/research, but only with heavy investment in coordination, evaluation, and reliability. - Source: https://www.anthropic.com/engineering/multi-agent-research-system

LangGraph / OpenAI SDK — human-in-the-loop interrupts as a designed primitive: agents pause at checkpoints or blockers for human feedback, rather than barreling to a false "done." - Source: https://openai.github.io/openai-agents-python/

2. HOW THEY DO IT — the shared playbook, ranked by leverage

The best converge on one method. Ranked by leverage for a solo operator:

  1. Ground truth over self-report. Never accept the agent's "done." Pull an observable fact from the environment (tool result, code execution, file check) and grade against it. (Anthropic, RLVR — highest leverage; it's the whole problem.)
  2. Cheap deterministic gates first. Anything checkable by code (exact match, file exists, dimensions, link resolves, schema valid) is a unit-test-style gate — faster and more reliable than any judge. (RLVR, Anthropic code-graders.)
  3. Error analysis on real traces. Read actual outputs, open-code failures into categories, fix the biggest bucket. This is where the real defects live. (Hamel/Shreya/Eugene.)
  4. A labelled eval set with metrics. A golden dataset of tasks with known-good answers, scored repeatedly. Turns "quality" into a number. (Anthropic, Braintrust, Eugene.)
  5. LLM-judge only for the subjective — and validate it. Build a judge only for failures you'll iterate on; then measure its agreement with your own labels (kappa / TPR) before trusting it. An unvalidated judge is just a second opinion that can't be audited. (Shreya "Who Validates the Validators?", Hamel.)
  6. Human gates for taste. Keep a human checkpoint for brand/taste/subtlety that automation can't catch. (OpenAI SDK, LangGraph interrupts, Anthropic SME tier.)
  7. Regression suite + evals-as-CI. Every past failure becomes a permanent test; the suite runs on every change so fixes don't silently regress. (Anthropic "evals as CI", Eugene "eval-driven development.")
  8. Tracing / observability underneath it all. You can't do error analysis on traces you didn't capture. Structured logging of every run is the substrate for 3–7. (LangSmith, Phoenix, Langfuse, Braintrust.)
  9. Harness discipline. Single-thread + context engineering + designed human interrupts beats sprawling multi-agent for reliability. (Cognition; Anthropic for the parallel-search exception.)

3. WHAT THE OPERATOR IS MISSING

Current setup: pre-send truth-check rule; gated build pipeline with human sign-off; deterministic visual QC script (qc.py); regression suite of past failures.

That setup already nails playbook items 1, 2, 6, and 7 — ground truth, deterministic gates, human taste gate, regression suite. That is genuinely the hard-won core; most operators don't have it. The gaps are in measurement, traceability, and the judge layer. Prioritised:

  1. Tracing / observability (highest leverage gap). There's no structured capture of every agent run. Without traces you can't do error analysis, can't see why a check failed, can't spot slow drift. Add a Langfuse (free/self-host) or Braintrust trace on every deliverable run. This is the substrate everything else sits on.
  2. A labelled eval set with metrics — not just a pass/fail regression suite. The regression suite catches known past failures. It does not give a score on new work. Build a small golden set (20–50 representative deliverable tasks with known-good outputs) and track a number over time. Turns "is it good" into a trend.
  3. Systematic error analysis on real traces. Once (1) exists: periodically read a sample of real runs, open-code the failures into categories, and fix the largest bucket. This is the single highest-ROI habit in the practitioner school — and it's currently absent.
  4. An LLM-judge for the subjective layer — validated against your own labels. qc.py covers the deterministic-visual layer. It cannot judge "is this on-brand / well-written / persuasive." Add a calibrated LLM judge for those — but only after measuring its agreement with your own sign-off decisions (Cohen's kappa / true-positive rate). An unvalidated judge is worse than none.
  5. Judge-vs-human agreement measurement. Directly: log your human sign-off verdicts, run the judge on the same items, compute agreement. If kappa is low, the judge isn't ready. This is the discipline that separates "we have evals" from "we have evals we can trust."
  6. CI on evals, not just on regressions. Wire the golden-set eval to run automatically on every change to a skill/prompt/pipeline — fail the build on score regression, the way Anthropic runs evals as CI. The regression suite is reactive; eval-CI is preventive.
  7. Trajectory metrics, not just outcome. Current gates are outcome-only (final artifact passes/fails). Add lightweight trajectory checks — did the agent take a wrong turn, retry excessively, or burn anomalous tokens mid-run — to catch silent-failure modes before the final gate. (Anthropic: trajectory vs outcome metrics.)
  8. Harness audit. Confirm the stack follows single-thread + context-engineering discipline (Cognition) rather than ad-hoc multi-agent fan-out, which is a known reliability sink. If any persona spawns peer agents with shared mutable state, that's a fragility to retire.

Net: the operator has built the gates; the best also build the measurement and traceability around the gates — tracing, a scored golden set, error analysis, a validated judge, and eval-CI. Add those five and the stack moves from "stops known bad output" to "measurably improving and self-auditing."

Sources

Flagged / unverified