Intermediate Agent Checks: A Watchdog Pattern and Its Limits

Published · Updated • news
AI AgentsMulti-Agent SystemsPythonLLM Evaluation

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.

Free interactive tools for the decisions this piece raises.

Related Reading