![Revisit consent button](../images/body-df29beacd7496220cc94.svg) 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 ![](../images/body-2159bb67f3de8ad870eb.svg) 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. * Cookie BCTempID * Duration 10 minutes * Description No description available. * Cookie __cf_bm * Duration 1 hour * Description This cookie, set by Cloudflare, is used to support Cloudflare Bot Management. * Cookie AWSALBCORS * Duration 7 days * Description Amazon Web Services set this cookie for load balancing. * Cookie _cfuvid * Duration session * Description Cloudflare sets this cookie to track users across sessions to optimize user experience by maintaining session consistency and providing personalized services * Cookie li_gc * Duration 6 months * Description Linkedin set this cookie for storing visitor's consent regarding using cookies for non-essential purposes. * Cookie __hssrc * Duration session * Description This cookie is set by Hubspot whenever it changes the session cookie. The __hssrc cookie set to 1 indicates that the user has restarted the browser, and if the cookie does not exist, it is assumed to be a new session. * Cookie __hssc * Duration 1 hour * Description HubSpot sets this cookie to keep track of sessions and to determine if HubSpot should increment the session number and timestamps in the __hstc cookie. * Cookie wpEmojiSettingsSupports * Duration session * Description WordPress sets this cookie when a user interacts with emojis on a WordPress site. It helps determine if the user's browser can display emojis properly. * Cookie BCSessionID * Duration 1 year 1 month 4 days * Description Blueconic sets this cookie as a unique identifier for the BlueConic profile. * Cookie _octo * Duration 1 year * Description No description available. * Cookie logged_in * Duration 1 year * Description No description available. * Cookie __Secure-YEC * Duration past * Description YouTube sets this cookie to stores the user's video player preferences using embedded YouTube video * Cookie __eoi * Duration 6 months * Description Description is currently not available. * Cookie AWSALBTGCORS * Duration 7 days * Description No description available. * Cookie login-status-p * Duration past * Description Description is currently not available. * Cookie AWSALBTG * Duration 7 days * Description No description available. * Cookie csrf_token * Duration session * Description No description available. * Cookie token_v2 * Duration 1 day * Description Description is currently not available. * Cookie D * Duration 1 year * Description Description is currently not available. * Cookie PHPSESSID * Duration session * Description This cookie is native to PHP applications. The cookie stores and identifies a user's unique session ID to manage user sessions on the website. The cookie is a session cookie and will be deleted when all the browser windows are closed. * Cookie VISITOR_PRIVACY_METADATA * Duration 6 months * Description YouTube sets this cookie to store the user's cookie consent state for the current domain. * Cookie cookietest * Duration session * Description The cookietest cookie is typically used to determine whether the user's browser accepts cookies, essential for website functionality and user experience. * Cookie __Host-airtable-session * Duration 1 year * Description This cookie is used to enable us to integrate the services of Airtable. * Cookie __Host-airtable-session.sig * Duration 1 year * Description This cookie is used to enable us to integrate the services of Airtable. * Cookie m * Duration 1 year 1 month 4 days * Description Stripe sets this cookie for fraud prevention purposes. It identifies the device used to access the website, allowing the website to be formatted accordingly. * Cookie BIGipServer* * Duration session * Description Marketo sets this cookie to collect information about the user's online activity and build a profile about their interests to provide advertisements relevant to the user. * Cookie __cfruid * Duration session * Description Cloudflare sets this cookie to identify trusted web traffic. * Cookie _GRECAPTCHA * Duration 6 months * Description Google Recaptcha service sets this cookie to identify bots to protect the website against malicious spam attacks. * Cookie __Secure-YNID * Duration 6 months * Description Google cookie used to protect user security and prevent fraud, especially during the login process. * Cookie cookieyes-consent * Duration 1 year * Description CookieYes sets this cookie to remember users' consent preferences so that their preferences are respected on subsequent visits to this site. It does not collect or store any personal information about the site visitors. 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. * Cookie lidc * Duration 1 day * Description LinkedIn sets the lidc cookie to facilitate data center selection. * Cookie brw * Duration 1 year * Description No description available. * Cookie brwConsent * Duration 5 minutes * Description Description is currently not available. * Cookie WMF-Uniq * Duration 1 year * Description Description is currently not available. * Cookie loom_anon_comment * Duration 1 year * Description No description available. * Cookie loom_referral_video * Duration session * Description Description is currently not available. * Cookie VISITOR_INFO1_LIVE * Duration 6 months * Description A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface. * Cookie yt-remote-connected-devices * Duration Never Expires * Description YouTube sets this cookie to store the user's video preferences using embedded YouTube videos. * Cookie ytidb::LAST_RESULT_ENTRY_KEY * Duration Never Expires * Description The cookie ytidb::LAST_RESULT_ENTRY_KEY is used by YouTube to store the last search result entry that was clicked by the user. This information is used to improve the user experience by providing more relevant search results in the future. * Cookie yt-remote-device-id * Duration Never Expires * Description YouTube sets this cookie to store the user's video preferences using embedded YouTube videos. * Cookie yt-remote-session-name * Duration session * Description The yt-remote-session-name cookie is used by YouTube to store the user's video player preferences using embedded YouTube video. * Cookie yt-remote-fast-check-period * Duration session * Description The yt-remote-fast-check-period cookie is used by YouTube to store the user's video player preferences for embedded YouTube videos. * Cookie yt-remote-session-app * Duration session * Description The yt-remote-session-app cookie is used by YouTube to store user preferences and information about the interface of the embedded YouTube video player. * Cookie yt-remote-cast-available * Duration session * Description The yt-remote-cast-available cookie is used to store the user's preferences regarding whether casting is available on their YouTube video player. * Cookie yt-remote-cast-installed * Duration session * Description The yt-remote-cast-installed cookie is used to store the user's video player preferences using embedded YouTube video. * Cookie cp_session * Duration 3 months * Description Codepen sets this cookie for Help systems found in the website. * Cookie loid * Duration 1 year 1 month 4 days * Description This cookie is set by the Reddit. The cookie enables the sharing of content from the website onto the social media platform. 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. * Cookie __hstc * Duration 6 months * Description Hubspot set this main cookie for tracking visitors. It contains the domain, initial timestamp (first visit), last timestamp (last visit), current timestamp (this visit), and session number (increments for each subsequent session). * Cookie hubspotutk * Duration 6 months * Description HubSpot sets this cookie to keep track of the visitors to the website. This cookie is passed to HubSpot on form submission and used when deduplicating contacts. * Cookie _ga * Duration 1 year 1 month 4 days * Description Google Analytics sets this cookie to calculate visitor, session and campaign data and track site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognise unique visitors. * Cookie _ga_* * Duration 1 year 1 month 4 days * Description Google Analytics sets this cookie to store and count page views. * Cookie __Host-psifi.analyticsTrace * Duration 6 hours * Description Description is currently not available. * Cookie __Host-psifi.analyticsTraceV2 * Duration 6 hours * Description Description is currently not available. * Cookie _gh_sess * Duration session * Description GitHub sets this cookie for temporary application and framework state between pages like what step the user is on in a multiple step form. * Cookie YSC * Duration session * Description YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages. * Cookie ajs_anonymous_id * Duration 1 year * Description This cookie is set by Segment to count the number of people who visit a certain site by tracking if they have visited before. * Cookie vuid * Duration 1 year 1 month 4 days * Description Vimeo installs this cookie to collect tracking information by setting a unique ID to embed videos on the website. 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. * Cookie AWSALB * Duration 7 days * Description AWSALB is an application load balancer cookie set by Amazon Web Services to map the session to the target. * Cookie acq * Duration past * Description Description is currently not available. * Cookie acq.sig * Duration past * Description Description is currently not available. * Cookie ptc * Duration 2 years * Description No description available. 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. * Cookie muc_ads * Duration 1 year 1 month 4 days * Description Twitter sets this cookie to collect user behaviour and interaction data to optimize the website. * Cookie guest_id_marketing * Duration 1 year 1 month 4 days * Description Twitter sets this cookie to identify and track the website visitor. * Cookie guest_id_ads * Duration 1 year 1 month 4 days * Description Twitter sets this cookie to identify and track the website visitor. * Cookie personalization_id * Duration 1 year 1 month 4 days * Description Twitter sets this cookie to integrate and share features for social media and also store information about how the user uses the website, for tracking and targeting. * Cookie guest_id * Duration 1 year 1 month 4 days * Description Twitter sets this cookie to identify and track the website visitor. It registers if a user is signed in to the Twitter platform and collects information about ad preferences. * Cookie bcookie * Duration 1 year * Description LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser IDs. * Cookie __Secure-ROLLOUT_TOKEN * Duration 6 months * Description YouTube sets this cookie to manage feature rollout and experimentation. It helps Google control which new features or interface changes are shown to users as part of testing and staged rollouts, ensuring consistent experience for a given user during an experiment. * Cookie yt.innertube::nextId * Duration Never Expires * Description YouTube sets this cookie to register a unique ID to store data on what videos from YouTube the user has seen. * Cookie yt.innertube::requests * Duration Never Expires * Description YouTube sets this cookie to register a unique ID to store data on what videos from YouTube the user has seen. * Cookie session_tracker * Duration session * Description This cookie is set by the Reddit. This cookie is used to identify trusted web traffic. It also helps in adverstising on the website. * Cookie edgebucket * Duration session * Description Reddit sets this cookie to save the information about a log-on Reddit user, for the purpose of advertisement recommendations and updating the content. * Cookie did * Duration 1 year * Description Arbor sets this cookie to show targeted ads to site visitors.This cookie expires after 2 months or 1 year. 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 Search[](https://towardsdatascience.com/)Toggle Mobile Navigation [](https://towardsdatascience.com/) Publish AI, ML & data-science insights to a global community of data professionals. Sign in[Submit an Article](https://write.insightmediagroup.io) [Latest](https://towardsdatascience.com/latest/)[Editor's Picks](https://towardsdatascience.com/tag/editors-pick/)[Newsletter](https://towardsdatascience.com/tag/the-variable/)[ShipAI](https://towardsdatascience.com/shipai/) * * * [Write For TDS](https://towardsdatascience.com/submissions/) [LinkedIn](https://www.linkedin.com/company/towards-data-science/)[X](https://x.com/TDataScience)Toggle Search [Agentic AI](https://towardsdatascience.com/category/artificial-intelligence/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](https://towardsdatascience.com/author/benjaminnweke/) 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.](../images/000.webp) 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](https://www.datadoghq.com/about/latest-news/press-releases/datadog-state-of-ai-engineering-report-2026/) 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. ![](../images/001.png) 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?_ ![](../images/body-68a09cf383089aa9a320.png) 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](https://arxiv.org/abs/2306.05685), 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](https://docs.pydantic.dev/latest/concepts/models/) 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: * **Latency:** Plain and simple. For a three-node pipeline, that's two extra inference calls sitting right on the critical path, and it adds up fast if you're building something where response time actually matters. * **A new failure surface:** A miscalibrated watchdog starts rejecting perfectly good handoffs, trading silent corruption for a different annoyance, false halts that somebody now has to triage by hand. Getting that threshold right takes real iteration, not a set-it-once number. * **Judgment:** Deciding where a handoff is actually worth grading, versus where you'd just be adding overhead for its own sake, depends entirely on how expensive being wrong is at that specific point. 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](https://thatcsguy.substack.com/?r=79lldp&utm_campaign=pub-share-checklist) if you'd like more of that. **Connect With Me** * [LinkedIn](http://www.linkedin.com/in/nwekebenjamin) * [Substack](https://thatcsguy.substack.com/) ## 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 * * * ![](../images/body-4ad89a2fc5e69dde007d.jpeg) Written By ## [Benjamin Nweke](https://towardsdatascience.com/author/benjaminnweke/) 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](https://towardsdatascience.com/author/benjaminnweke/) [AI Agents](https://towardsdatascience.com/tag/ai-agents-2/)[Artificial Intelligence](https://towardsdatascience.com/tag/artificial-intelligence/)[Llm](https://towardsdatascience.com/tag/llm/)[Machine Learning](https://towardsdatascience.com/tag/machine-learning/)[Python](https://towardsdatascience.com/tag/python/) Share This Article * [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Ftowardsdatascience.com%2Fwhy-most-multi-agent-systems-fail-even-when-evaluation-passes%2F&title=Why%20Most%20Multi-Agent%20Systems%20Fail%20Even%20When%20Evaluation%20Passes) * [](https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Ftowardsdatascience.com%2Fwhy-most-multi-agent-systems-fail-even-when-evaluation-passes%2F&title=Why%20Most%20Multi-Agent%20Systems%20Fail%20Even%20When%20Evaluation%20Passes) * [](https://x.com/share?url=https%3A%2F%2Ftowardsdatascience.com%2Fwhy-most-multi-agent-systems-fail-even-when-evaluation-passes%2F&text=Why%20Most%20Multi-Agent%20Systems%20Fail%20Even%20When%20Evaluation%20Passes) 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](https://towardsdatascience.com/submissions/) ## Related Articles * [![](../images/002.jpg)](https://towardsdatascience.com/how-to-scale-your-llm-usage/) ## [How to Scale Your LLM Usage](https://towardsdatascience.com/how-to-scale-your-llm-usage/) [Agentic AI](https://towardsdatascience.com/category/artificial-intelligence/agentic-ai/) Learn how to increase LLM usage to achieve increased productivity [Eivind Kjosbakken](https://towardsdatascience.com/author/oieivind/) November 29, 20256 min read * [![](../images/003.jpg)](https://towardsdatascience.com/agentic-ai-from-first-principles-reflection/) ## [Agentic AI from First Principles: Reflection](https://towardsdatascience.com/agentic-ai-from-first-principles-reflection/) [Agentic AI](https://towardsdatascience.com/category/artificial-intelligence/agentic-ai/) From theory to code: building feedback loops that improve LLM accuracy [Mariya Mansurova](https://towardsdatascience.com/author/miptgirl/) October 24, 202520 min read * [![](../images/004.jpg)](https://towardsdatascience.com/building-video-game-recommender-systems-with-fastapi-postgresql-and-render-part-1/) ## [Building Video Game Recommender Systems with FastAPI, PostgreSQL, and Render: Part 1](https://towardsdatascience.com/building-video-game-recommender-systems-with-fastapi-postgresql-and-render-part-1/) [Data Science](https://towardsdatascience.com/category/data-science/) Designing a video game recommendations service with Steams API [Lucas See](https://towardsdatascience.com/author/seelcs12/) September 25, 202521 min read * [![](../images/005.jpg)](https://towardsdatascience.com/automatic-notification-to-email-with-python-810fd357d89c/) ## [Automatic Notification to Email with Python](https://towardsdatascience.com/automatic-notification-to-email-with-python-810fd357d89c/) [Machine Learning](https://towardsdatascience.com/category/artificial-intelligence/machine-learning/) Automate your notification system with Python [Cornellius Wijaya](https://towardsdatascience.com/author/cornelliusyudhawijaya/) June 13, 20204 min read * [![](../images/006.jpg)](https://towardsdatascience.com/i-built-an-ai-data-agent-which-can-query-data-and-answer-business-questions-heres-how/) ## [I Built an AI Data Agent Which Can Query Data and Answer Business Questions. Here’s How.](https://towardsdatascience.com/i-built-an-ai-data-agent-which-can-query-data-and-answer-business-questions-heres-how/) [Agentic AI](https://towardsdatascience.com/category/artificial-intelligence/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](https://towardsdatascience.com/author/jiayanyin.simba/) August 6, 202610 min read * [![](../images/007.jpg)](https://towardsdatascience.com/how-to-automate-workflows-with-ai/) ## [How to Automate Workflows with AI](https://towardsdatascience.com/how-to-automate-workflows-with-ai/) [Agentic AI](https://towardsdatascience.com/category/artificial-intelligence/agentic-ai/) Learn how to take a manual process and optimize it using AI [Eivind Kjosbakken](https://towardsdatascience.com/author/oieivind/) November 15, 20256 min read * [![](../images/008.jpeg)](https://towardsdatascience.com/bi-is-dead-long-live-bi/) ## [BI Is Dead, Long Live BI](https://towardsdatascience.com/bi-is-dead-long-live-bi/) [Agentic AI](https://towardsdatascience.com/category/artificial-intelligence/agentic-ai/) The true bottleneck was never the analysis. [Mahdi Karabiben](https://towardsdatascience.com/author/mahdiqb/) June 11, 20268 min read * [![](../images/009.png)](https://towardsdatascience.com/agentops-is-not-mlops-what-breaks-in-your-monitoring-stack-when-agents-go-to-production/) ## [AgentOps Is Not MLOps: What Breaks in Your Monitoring Stack When Agents Go to Production](https://towardsdatascience.com/agentops-is-not-mlops-what-breaks-in-your-monitoring-stack-when-agents-go-to-production/) [Agentic AI](https://towardsdatascience.com/category/artificial-intelligence/agentic-ai/) The five MLOps monitoring assumptions agents break, and which inherited signals now pass failed runs as healthy. [Mostafa Ibrahim](https://towardsdatascience.com/author/mostafaibrahim18/) August 31, 202610 min read * [![](../images/010.jpg)](https://towardsdatascience.com/deploy-an-openai-agent-builder-chatbot-to-a-website/) ## [Deploy an OpenAI Agent Builder Chatbot to your Website](https://towardsdatascience.com/deploy-an-openai-agent-builder-chatbot-to-a-website/) [Agentic AI](https://towardsdatascience.com/category/artificial-intelligence/agentic-ai/) Using OpenAI’s Agent Builder ChatKit [Thomas Reid](https://towardsdatascience.com/author/thomas_reid/) October 24, 202510 min read * [YouTube](https://www.youtube.com/c/TowardsDataScience) * [X](https://x.com/TDataScience) * [LinkedIn](https://www.linkedin.com/company/towards-data-science/) * [Threads](https://www.threads.net/@towardsdatascience) * [Bluesky](https://bsky.app/profile/towardsdatascience.com) [](https://towardsdatascience.com/) 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 Newsletter[Write For TDS](https://towardsdatascience.com/submissions/)•[About](https://towardsdatascience.com/about-towards-data-science-d691af11cc2f/)•[Advertise](https://contact.towardsdatascience.com/advertise-with-towards-data-science)•[Privacy Policy](https://towardsdatascience.com/privacy-policy/)•[Terms of Use](https://towardsdatascience.com/website-terms-of-use/) © Insight Media Group, LLC 2026•[The New Stack](https://thenewstack.io)•[roadmap.sh](https://roadmap.sh)•[Creator Network](https://insightmediagroup.io/creator-network) #### Recommended Articles Close * [ ![](https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607686/image?etag=1782161464448&width=500&height=500) How Relevance Models Foreshadowed Transformers for NLP ](https://towardsdatascience.com/how-relevance-models-foreshadowed-transformers-for-nlp/ "How Relevance Models Foreshadowed Transformers for NLP") * [ ![](https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607639/image?etag=1781250125848&width=500&height=500) Javascript Fatigue: HTMX Is All You Need to Build ChatGPT — Part 1 ](https://towardsdatascience.com/javascript-fatigue-you-dont-need-js-to-build-chatgpt/ "Javascript Fatigue: HTMX Is All You Need to Build ChatGPT — Part 1") * [ ![](https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/607930/image?etag=1782124566054&width=500&height=500) The Subset Sum Problem Solved in Linear Time for Dense Enough Inputs ](https://towardsdatascience.com/subset-sum-problem-solved-in-linear-time-for-dense-enough-inputs/ "The Subset Sum Problem Solved in Linear Time for Dense Enough Inputs") * [ ![](https://h030.towardsdatascience.com/rest/v2/contentStores/d7d3a4ab-7caf-4383-bbd2-fbf7fb4f1787/items/3660/image?etag=1780176246070&width=500&height=500) Does Your Company Have a Data Strategy? ](https://towardsdatascience.com/does-your-company-have-a-data-strategy-e8944dbec4ae/ "Does Your Company Have a Data Strategy?")