Intermediate Agent Checks: A Watchdog Pattern and Its Limits
In this article
Correction, 22 October 2026: this article previously misread Datadog's report as evidence that 40% of production AI failures return semantically wrong HTTP 200 responses. The cited report measures reported call-span errors and the share caused by rate limits; it does not establish that silent-failure rate. Intermediate semantic checks can still be useful, but their accuracy requires a separate evaluation. For engineers building pipelines with no shared contract between agent layers, this is the failure mode that erodes trust before anyone knows what to diagnose.
The canonical example from Benjamin Nweke's analysis is a three-node support-ticket triage pipeline: a classifier, an account-history retrieval node, and a resolution drafter. When upstream account ID corruption causes the billing API to return an empty-but-valid result set, the drafting node receives a well-formed JSON object with zero billing records, interprets it as "no billing history exists," and generates a polished, grammatically correct email declining a refund. No exception is raised. No log entry flags the corruption. Output-level evaluation scores the email well — clear, professional, on topic — because the rubric inspects only the final text layer.
Why Output-Level Eval Is Structurally Blind
Grading the compiled output is equivalent to testing a compiled application by confirming the login screen renders. The query backing that login, the token it issues, and the permission check it triggers are all invisible to surface-level inspection. In a multi-agent pipeline, the analogous invisible layer is the JSON handoff between nodes: tool calls, intermediate reasoning state, and payload contents that flow across seams the final text scorer never touches.
A 500-level error gets caught because the system already has a plan for that shape of failure. The expensive failure is the 200 that carries a structurally valid but semantically garbage payload — exactly what output eval is built to reward.
The Watchdog Pattern: Architecture and Implementation
The fix is to move evaluation into the pipeline itself, at each handoff seam, rather than appending another rubric to the end. Nweke calls this Intermediate State Eval. A lightweight watchdog function sits between agent nodes and asks one narrow binary question before the next node consumes the payload: does this handoff look plausible?
Implementation starts with a Pydantic schema that gives the watchdog something concrete to check:
from pydantic import BaseModel, Field
CONFIDENCE_FLOOR = 0.35 # tuned down from 0.5 after false-halt rate in staging
class AccountHistoryPayload(BaseModel):
account_id: str
subscription_status: str
billing_records: list[dict] = Field(default_factory=list)
lookup_source: str
class HandoffVerdict(BaseModel):
is_plausible: bool
reason: str
confidence: float
The CONFIDENCE_FLOOR of 0.35 started at 0.5 and was moved down after low-confidence-but-correct handoffs in staging generated false halts. The grading function sends a narrow structured prompt to a distilled 1B-parameter model running on the same box as the pipeline, then parses the response into a HandoffVerdict. If the grader itself returns unparseable output, the watchdog blocks the handoff rather than defaulting to pass-through:
def grade_handoff(request_account_id, payload, local_grader):
prompt = GRADER_PROMPT.format(
payload=payload.model_dump_json(),
account_id=request_account_id
)
raw_response = local_grader(prompt)
try:
verdict = HandoffVerdict.model_validate_json(raw_response)
except ValueError:
logger.error("Grader returned unparseable output, blocking handoff: %r", raw_response[:200])
return HandoffVerdict(is_plausible=False, reason="grader output unparseable", confidence=0.0)
if not verdict.is_plausible or verdict.confidence < CONFIDENCE_FLOOR:
logger.warning("Handoff rejected for account_id=%s ...", request_account_id, ...)
return verdict
Orchestration replaces a silent pass-through with a raised HandoffRejectedError, converting a wrong email dispatched to a customer into a halted pipeline with the bad payload attached to the alert.
Costs and Placement Tradeoffs
| Cost dimension | Mechanism | Mitigation |
|---|---|---|
| Latency | Two extra inference calls on the critical path for a three-node pipeline | Use a 1B-class local model on the same host to minimise round-trip overhead |
| New failure surface | Miscalibrated watchdog generates false halts requiring manual triage | Iterative threshold tuning; CONFIDENCE_FLOOR required staging iteration to reach 0.35 |
| Judgment cost | Deciding which handoffs warrant a watchdog vs. pure overhead | Instrument only the last internal handoff before an external action fires first |
The recommended deployment sequence is not to instrument every node simultaneously. Start at the final internal handoff before something external occurs — an email send, a record write, a financial action — and run that checkpoint for one to two weeks before deciding whether to push the watchdog further back. This directly addresses where oversight should sit in agent infrastructure without requiring an architectural overhaul on day one.
Evaluation methodology is a systems-design decision, not a post-hoc quality check. As agent chains grow longer, the gap between what output-level scoring can see and what actually happened inside the pipeline compounds with every additional node. A 1B local model running a narrow plausibility check at each seam is not a sophisticated solution — its value is entirely in placement, not cleverness. Engineers who instrument the middle of their pipelines before something external fires will catch some intermediate failure cases if the evaluator is accurate; Datadog's report does not measure their prevalence. Those who grade only the final output are testing the login screen.
Frequently asked questions
What percentage of production AI failures are silent successes that return HTTP 200?
Datadog does not report that statistic. Its February 2026 telemetry says 60 percent of reported LLM call errors were rate limits. The complement is not identified as silent semantic failures.
What size model does the watchdog pattern require?
The implementation described uses a distilled 1B-parameter model running on the same host as the pipeline. The model does not need to be large or sophisticated; it only needs to return a fast binary plausibility verdict per handoff.
What is the CONFIDENCE_FLOOR threshold in the watchdog pattern, and why was it lowered?
The CONFIDENCE_FLOOR is set to 0.35. It started at 0.5 and was moved down after low-confidence-but-correct handoffs in staging were generating false halts that required manual triage.
Where in a multi-agent pipeline should the watchdog be deployed first?
The recommended starting point is the last internal handoff before something external fires — an email send, a record write, or a financial action. Running that single checkpoint for one to two weeks before deciding whether to push the watchdog further back avoids an architectural overhaul on day one.
What happens if the watchdog's grader itself returns unparseable output?
The implementation blocks the handoff rather than defaulting to pass-through. A HandoffVerdict with is_plausible=False and confidence=0.0 is returned, and the rejection is logged — preventing a misconfigured grader from silently allowing corrupt payloads through.
Related Reading
Codex Subagents: Three Specialist Agents, One Synthesised Answer
A hands-on guide to defining Codex CLI subagents via TOML, running them in parallel, and letting a main agent synthesise competing findings.
Risk-Scored Routing Cuts Human Review to High-Signal Queries Only
A text-to-SQL team replaced blanket approval gates with a four-signal risk router, sending only genuinely ambiguous actions to human reviewers.
Build Stateful Web Research Agents with Claude Agent SDK
Run one-off and stateful Claude research agents that search the web, cite sources, and read multimodal inputs with the Anthropic Cookbook pattern.