保留正文与补采附件。源页面当前未重新核验；具体限制见交付清单。

Revisit consent button We value your privacy We use cookies to enhance your browsing experience, serve personalised ads or content, and analyse our traffic. By clicking "Accept All", you consent to our use of cookies. Customise Reject All Accept All Customise Consent Preferences We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below. The cookies that are categorised as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... Show more NecessaryAlways Active Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

Functional Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

Analytics Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

Performance Performance cookies are used to understand and analyse the key performance indexes of the website which helps in delivering a better user experience for the visitors.

Advertisement Advertisement cookies are used to provide visitors with customised advertisements based on the pages you visited previously and to analyse the effectiveness of the ad campaigns.

Uncategorised Other uncategorised cookies are those that are being analysed and have not been classified into a category as yet. No cookies to display. Reject All Save My Preferences Accept All Toggle SearchToggle Mobile Navigation Publish AI, ML & data-science insights to a global community of data professionals. Sign inSubmit an Article LatestEditor's PicksNewsletterShipAI

Write For TDS LinkedInXToggle Search Agentic AI

Why Most Multi-Agent Systems Fail Even When Evaluation Passes

How to catch a payload that looks correct but isn't, using a watchdog pattern with working Python. Benjamin Nweke September 7, 202610 min read Two robotic arms pass a glowing golden cube. A crack in the cube reveals chaotic, broken code inside, representing a hidden failure in an otherwise successful agent handoff. Image by author (Generated with ChatGPT) Two robotic agents exchange a glowing golden data cube that appears perfect on the outside but contains broken code, illustrating how silent failures can pass unnoticed between agents in a multi-agent system. I keep running into some version of this failure wherever agents get chained together, in one shape or another. Take a support-ticket triage system, for example, that is three nodes deep. One classifies the incoming ticket, one pulls the customer's account history from an internal API, and another one drafts the resolution or escalation based on both. Then, it ships. It works well in the demo, which honestly, from my experience, doesn't tell you much. It works for the first few days in production too; again, that tells you slightly more but still not enough. Along the line, a complaint comes in about a canceled subscription refund. The account-history node calls the billing API, gets back a 200, and passes the payload downstream as if nothing happened. The payload is empty. No malformed data, no timeout, nothing that would even show up as a 500. Just an empty result set, formatted exactly as a valid response would be, because the account ID got messed up two steps upstream and the billing service quietly returned nothing for an account it couldn't match. The drafting node never sees an error. It sees a well-formed JSON object with no records in it, decides that means "no billing history," and writes a perfectly polite email explaining there's nothing to refund. It goes out, wrong refund decision and all. But still nobody catches it, because nothing about the process ever crashed. As far as the system's concerned, it did its job. I don't think this exact scenario needs to have happened to you specifically for it to be worth your time. If you've spent any real stretch of time around multi-agent systems in production, you've either already seen a version of this, or you're going to eventually. None of this is anecdotal, either. Datadog's 2026 State of AI Engineering report puts production failure rates for AI requests at around 5 percent, and only about 60 percent of that comes from the loud, capacity-driven failures you'd actually notice through an error code. The rest is closer to what happened above, a request that completes and still gets it wrong. One pipeline, three steps, one blind spot. Image by author.

Why nothing catches it

Run this pipeline through a standard evaluation suite, and it sails through. The final output reads well, is grammatically clean, and is professionally worded. A human skimming it for tone has no reason to flag anything, not unless they happen to go cross-reference the actual account, which kind of defeats the point of automating the check in the first place. If you score it against a rubric for resolution quality, it probably does well too. Clear, polite, and on topic. It passes because each of those checks looks at the same layer: the final text. None of them ask what happened between node two and node three. The account-history node didn't fail loudly; it failed by succeeding at returning the wrong thing, and succeeding is exactly what output-level eval is built to reward. This is the part I think is worth sitting with longer than feels natural, before jumping to a fix. Grading only the compiled output makes you structurally blind to intermediate states that look correct but aren't. That's not a gap you patch with a better prompt on the last node. It's a blind spot that comes baked into where you decided to look in the first place.

Grading the UI instead of the application underneath it

There's an old comparison here that I keep coming back to. Nobody ships a compiled application and calls it tested because the login screen renders. You test the layer beneath it, the query that backs the login, the token it issues, and even the permission check it triggers along the way. The UI is the last place a bug shows itself, not the first place you'd think to look for one. Most production agent eval right now is UI-only testing bolted onto a system that doesn't even have a UI in the traditional sense. The final text response is the only thing getting graded, mostly because it's the only thing that's easy to grade. You can run it through a rubric, compare it line-by-line against a known-good answer, or have someone skim it over coffee. The tool calls, the JSON handoffs between nodes, the partial reasoning getting passed forward: none of that gets watched unless something crashes hard enough to leave a trace in a log somewhere. And the expensive failure mode was never the loud one. A 500, a server admitting outright that something broke, gets caught and escalated, because the system already expects that shape of failure and has some plan for it. The one that costs you is the 200, the response that says everything's fine, attached to a payload that's structurally fine and semantically garbage.

An architecture for watching the middle

So the fix isn't another rubric bolted onto the end. It's moving some of the evaluation into the pipeline itself, right at the seams where one agent's output becomes another agent's input. I've been calling this an Intermediate State Eval architecture , mostly because it needed a name and that one stuck. The idea is a lightweight grader sitting between agent nodes, not waiting for the whole chain to finish. In the ticket-triage case we talked about earlier, that's a checkpoint between the account-history node and the drafting node, and its only job is asking whether the handoff looks plausible.

Does the account ID in the payload actually match the one that was requested? Does this look like a real lookup result, or like the kind of default value a system quietly falls back to when it can't find what it's looking for? A watchdog grades each handoff before it's allowed to reach the next node, halting on anything implausible instead of letting it pass through. Image by author. You don't need a large model doing this judgment call, and honestly I'd argue against it. A small local model serving as a watchdog between nodes, the same basic idea behind using a model to judge another model's output, is enough to catch shape-level and plausibility-level problems, and keeping it local prevents the added latency and cost from becoming a second version of the exact problem you're trying to solve. Its verdict doesn't actually need to be clever. It just needs to be fast and binary: does this handoff look sane enough to move forward, or does it need to get flagged and stopped before the next node builds anything on top of it? That's the whole job, nothing more. Here's what that actually looks like in code. Start with the shape of the handoff itself. Defining it as a real schema with Pydantic instead of a loose dict is what makes the watchdog's job possible at all, since it gives the grader something concrete to check against instead of guessing at structure fresh on every call. python

from pydantic import BaseModel, Field
import logging

logger = logging.getLogger("pipeline.handoff")

# below this, the watchdog treats a "plausible" verdict as implausible anyway -
# started at 0.5, got burned by a bunch of low-confidence-but-correct handoffs
# in staging, moved it down until the false-halt rate stopped annoying people
CONFIDENCE_FLOOR = 0.35


class AccountHistoryPayload(BaseModel):
    account_id: str
    subscription_status: str
    billing_records: list[dict] = Field(default_factory=list)
    lookup_source: str  # which upstream system actually answered - saved us more than once when this was the only clue


class HandoffVerdict(BaseModel):
    is_plausible: bool
    reason: str
    confidence: float

The watchdog itself is just a small function, not some new service you need to stand up and maintain. It takes the outgoing payload, the request that produced it, and asks a local model one narrow question instead of an open-ended one. Keeping the question narrow is the whole trick, honestly, that's what keeps this cheap enough to actually sit on the critical path instead of becoming its own bottleneck. python

import textwrap

# local_grader: anything callable that takes a prompt and returns text.
# we're running a distilled 1B model on the same box as the pipeline -
# it doesn't need to be smart, it needs to be fast and not fall over

GRADER_PROMPT = textwrap.dedent("""\
    A downstream agent is about to receive this account history payload:
    {payload}

    It was requested for account_id: {account_id}

    Answer strictly as JSON: {{"is_plausible": bool, "reason": str, "confidence": float}}
    Flag it as implausible if the account_id doesn't match, if billing_records
    is empty for a subscription marked active, or if the payload looks like
    a default/fallback value rather than a real lookup result.
""")


def grade_handoff(request_account_id: str, payload: AccountHistoryPayload, local_grader) -> HandoffVerdict:
    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:
        # the grader itself can return garbage - if we can't parse its verdict,
        # don't just shrug and let the handoff through, that defeats the point
        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: %s (confidence=%.2f)\npayload=%s",
            request_account_id, verdict.reason, verdict.confidence, payload.model_dump_json(),
        )
    return verdict

And yeah, the orchestration wiring is about as unglamorous as it gets; that's done on purpose, by the way. Somewhere in your pipeline you already have functions handling classification and drafting the final resolution. The only new piece here is the gate sitting between them, grading the handoff and raising instead of quietly letting a bad payload flow through to whatever writes the customer-facing response. python

class HandoffRejectedError(Exception):
    pass


def run_pipeline(account_id: str, account_data: dict, local_grader) -> AccountHistoryPayload:
    payload = AccountHistoryPayload(**account_data)
    verdict = grade_handoff(account_id, payload, local_grader)

    if not verdict.is_plausible:
        # this replaces what used to be a wrong email going out quietly -
        # a raised exception here is annoying, a refund that shouldn't exist isn't
        raise HandoffRejectedError(f"account_id={account_id}: {verdict.reason}")

    return payload  # safe to hand off to whatever drafts the resolution

None of this is fancy, and I'd be a little suspicious of anyone who dressed it up to sound like it was. It's a schema, one narrow grading call, and an exception where there used to be a silent pass-through. The value was never in the sophistication of any single piece. It's entirely in where you decided to put the check. The practical payoff is that failures stop happening in silence. Instead of a wrong email going out three steps downstream of the real problem, the pipeline stops right at the point of corruption, with the actual bad handoff attached to whatever alert fires. That turns a support escalation that costs you trust into a debugging session that costs you a few minutes.

What this costs you

None of this is free, and I'd rather be upfront about that than sell you a strict improvement with no downside, because there isn't one, but three costs, specifically:

Not every node needs a watchdog sitting on it. The ones that sit right before something external-facing, an email going out or a refund actually firing, are the ones where the cost of catching a bad handoff clearly beats the cost of the extra hop. Everywhere else, you're probably just adding latency for the sake of feeling thorough. ···

Final thoughts

If you're running a multi-agent pipeline today and want to try this without tearing the whole thing apart, don't start at the front of the chain. Trust me. Start at the last internal handoff before something external actually happens, right before an email sends, a record gets written, a decision gets acted on. That's the one boundary worth instrumenting first. Give it a week or two, see what the watchdog actually catches, and let that tell you whether it's worth pushing further back into the pipeline. You don't need the full architecture on day one to get something out of this. Next time something breaks in a pipeline you own, ask yourself whether your evals would have caught it before the output itself looked wrong. Most of the time, if you're honest, the answer's no. That gap is exactly where the riskiest handoff in your system has been sitting the whole time, waiting for someone to look. Your final output can lie to you. The trajectory can't. ···

Before you go!

I write about the engineering decisions that decide whether an AI system holds up in production. You can subscribe to my newsletter if you'd like more of that. Connect With Me

Register Now to Continue Reading

Unlock Towards Data Science with a Free Account

All articles on Towards Data Science are available to registered users. Create a free account today to access this article and thousands more. Register for freeSign in to your account

Written By

Benjamin Nweke

Benjamin Nweke is a Computer Science graduate and technical writer exploring AI, machine learning, and data science. He writes about building reliable AI systems, model evaluation, agentic architectures, and the practical challenges that appear when machine learning moves beyond experiments. His work focuses on making technically complex ideas clear, useful, and grounded in real implementation. See all from Benjamin Nweke AI AgentsArtificial IntelligenceLlmMachine LearningPython Share This Article

Towards Data Science is a community publication. Submit your insights to reach our global audience and earn through the TDS Author Payment Program. Write for TDS

Related Articles

How to Scale Your LLM Usage

Agentic AI Learn how to increase LLM usage to achieve increased productivity Eivind Kjosbakken November 29, 20256 min read

Agentic AI from First Principles: Reflection

Agentic AI From theory to code: building feedback loops that improve LLM accuracy Mariya Mansurova October 24, 202520 min read

Building Video Game Recommender Systems with FastAPI, PostgreSQL, and Render: Part 1

Data Science Designing a video game recommendations service with Steams API Lucas See September 25, 202521 min read

Automatic Notification to Email with Python

Machine Learning Automate your notification system with Python Cornellius Wijaya June 13, 20204 min read

I Built an AI Data Agent Which Can Query Data and Answer Business Questions. Here’s How.

Agentic AI A step-by-step guide to building a data agent and conversational interface that let business users to explore data in natural language without SQL Jiayan Yin August 6, 202610 min read

How to Automate Workflows with AI

Agentic AI Learn how to take a manual process and optimize it using AI Eivind Kjosbakken November 15, 20256 min read

BI Is Dead, Long Live BI

Agentic AI The true bottleneck was never the analysis. Mahdi Karabiben June 11, 20268 min read

AgentOps Is Not MLOps: What Breaks in Your Monitoring Stack When Agents Go to Production

Agentic AI The five MLOps monitoring assumptions agents break, and which inherited signals now pass failed runs as healthy. Mostafa Ibrahim August 31, 202610 min read

Deploy an OpenAI Agent Builder Chatbot to your Website

Agentic AI Using OpenAI’s Agent Builder ChatKit Thomas Reid October 24, 202510 min read

Your home for data science and AI. The world's leading publication for data science, data analytics, data engineering, machine learning, and artificial intelligence professionals. Subscribe to Our NewsletterWrite For TDS•About•Advertise•Privacy Policy•Terms of Use © Insight Media Group, LLC 2026•The New Stack•roadmap.sh•Creator Network

Recommended Articles

Close