Multi-agent system failures: three patterns we found on our own board

There's no client in this case. It broke on our side, and the numbers come off our working board.

What's actually running

Grow2.ai runs content production as a multi-agent system on Paperclip: an editor creates tasks, a writer produces the master piece, a distributor adapts it per platform, a publisher posts it, and a separate agent collects metrics. We covered a similar setup in the case about four agents in management — same logic here, applied to our own content. Each stage is a separate agent with its own context, its own run and its own task on the board. The transition between stages is formalized through task status and a blocker dependency: an agent closes its task as done, and that wakes the next one.

The scale as of 13 August 2026: the board runs continuous numbering from AUSA-14 to AUSA-2417, with the first task created on 12 March. The content side holds 165 pieces, 82 of them published. Five months were enough to see what actually breaks.

The main observation: the agents didn't crash

The expectation was that the problems would sit inside the agents. Hallucinations, malformed JSON, an agent misreading the task, an agent looping. Those things happened, and they're cheap and visible: the agent writes a comment, you read it and fix it — and that's exactly what the usual protection layers are built for.

The expensive failures looked different. The agent ran successfully, reported successfully, closed its task successfully — and the work vanished. Not lost as in a deleted file, but invisible to the next stage. The piece is on disk, the task is closed, every metric is green, and nothing is published.

The three patterns below are the most expensive ones we found; the longest-lived held for 24 days. What they have in common isn't the technology, it's that none of them shows up in a check for "is the agent working".

Pattern 1: approved material that never shipped

Approval runs through Telegram: a card with the piece arrives, the user taps "Approve", and a service gateway catches the decision and creates a publishing task.

Then came a bug of assumption. The gateway created the child task "publish", but never moved the approval task itself to done — it simply didn't have rights on someone else's task. And the next stage, which every morning looks for what to publish today, gated publication on exactly that approval status: done or not. The approval stayed in in_review, after seven working days the stale-task policy moved it to backlog, and the piece became invisible for good.

The state when we found this (scan of 9 July 2026, 2,010 tasks on the board):

So 34 pieces had been approved by a live human and were invisible to the system at the same time. The nastiest subgroup is those 18 in backlog: the staleness policy dutifully marked them as "sitting undecided for over a week", when the decision had been made on day one. The system was reporting the opposite of what happened.

The fix: closing the approval became a separate step for the editor in the daily run. Scan every publishing task carrying an approval marker, and if the parent approval isn't closed — close it. The receipt for an approval is the existence of the child publishing task itself.

When the receipt for a decision is written by one component and read by another, what you verify isn't that the component ran — it's that the receipt actually showed up where someone will look for it.

Pattern 2: a silent agent means a broken engine, not missing credentials

The publisher had a real, documented blocker: some social media tokens were dead. The task to restore access had been open since June.

So when publishing tasks stopped moving, the diagnosis seemed obvious. Tasks AUSA-2084 and AUSA-2085, created on 13 July, sitting in todo, nothing published, the publisher has no tokens — cause found, waiting on credentials.

The right answer turned up on 6 August, 24 days later. Those tasks had zero comments.

An agent that runs into missing credentials leaves a comment: it lists the platforms that fell over and stops. An agent that left no comment at all never started. What was broken wasn't access, it was the session engine — the agent died during initialization, before it could see the task. The fix wasn't in tokens but in model configuration; after we moved the agents to a new model, the publisher shipped a piece the same day. That an agent's behavior depends not only on the prompt but on the harness around it is something we covered separately, in why the same AI agent gives different results.

Before you write off a stall as a known blocker, open the task and look for a comment from the agent. No comment — fix the launch, not the integration. On the board, "the agent tried and couldn't" and "the agent never woke up" look identical, and that distinction cost twenty-four days.

One more thing we didn't know: the publisher wakes on task creation , and doesn't re-trigger itself on old tasks sitting in todo . After the engine was fixed, those had to be woken explicitly.

Pattern 3: the filter that screens out its own

The daily "what are we publishing today" check selects material on the condition publication date == today. The strict equality isn't accidental: loosening it to <= today means a piece with a past date and an already-closed publishing task gets a new task every morning, and task creation isn't idempotent. Daily duplicates are worse than a miss.

The consequence that doesn't follow from the rule obviously: a piece with no date field never matches today's date. It's invisible indefinitely — and it can be entirely ready, with platform adaptations filled in and a real approval on it.

On 10 August there were 32 such pieces. Sorting them by approval state showed that "32 lost" is an imprecise phrasing, and different subgroups need different treatment:

As of 13 August, 26 pieces remain without a date: 17 with a link to an approval and 9 without one.

This isn't a bug in the code. The condition is written exactly as intended, and it can't be loosened. The error is in the assumption that a date is always there — the field is optional, and a piece can reach ready without one.

A defect of the same nature lived next door and cost a separate day. The same scans were first written to walk the current month's folder. The folder is the month the piece was created , while the date in the file is the month of publication, and the two diverge regularly. A scan over the August folder honestly reported "nothing to publish" while two finished pieces dated today sat in the July one.

What the three patterns share

• In the first, the gateway did exactly what it had rights to do, and the receipt for the decision never appeared where it was being read.
• In the second, the agent didn't exist as a process, but its status on the board was a valid pre-work state, indistinguishable from "waiting its turn".
• In the third, the filter correctly screened out everything that didn't match the condition, including what should have passed.

The common denominator: an agent reporting success and work reaching the next stage are two different events. Monitoring that checks the first knows nothing about the second.

That formulation isn't our discovery. The paper Why Do Multi-Agent LLM Systems Fail? (Cemri et al., NeurIPS 2025) went through more than 1,600 annotated execution traces from seven popular multi-agent frameworks and built the MAST taxonomy — 14 failure modes in three categories. One of the three categories is inter-agent misalignment: a breakdown in passing critical information between agents rather than inside them. Failure rates in the frameworks studied ran from 41% to 86.7%. Our three patterns land squarely in that category, and the fact that they reproduced on our own stack without any knowledge of the taxonomy reads as confirmation rather than coincidence.

What to monitor at the handoffs

The practical minimum we arrived at. Not a universal framework — just what covers our three patterns.

Check the artifact, not the status. After writing there should be a file; after publishing, a URL or a record ID on the platform. A task in done doesn't prove the work happened: our publisher honestly closes a task as done even when it skips a piece on the date condition.

An agent's silence is its own state. Task assigned, a day gone, zero comments — that isn't "in progress", that's "never started". On the board both look the same, so the distinction has to be made explicitly.

Strict filters have to report what they screen out: not only what passed, but how much didn't and why. A filter of date == today that silently drops 26 finished pieces reports it as "nothing to publish today".

And separately, the part that isn't about code at all. The most expensive of the three mistakes wasn't technical: for twenty-four days we built a plan around a plausible explanation instead of spending one query to test it. A known blocker in the system is a convenient answer that symptoms stick to on their own. That applies to your own conclusions from yesterday too, as we found out: we carried the premise "approvals can't be closed in a batch, it'll create duplicates" around for a week, until a scan showed there wouldn't be a single duplicate.

The honest limits of this piece

There are no client results here and no claim that any of this is universal. It's five months of one system — 18 agents on one orchestration platform, five of them in the content chain. The three patterns are what we found in our own setup, not an exhaustive list of failure modes; MAST counts fourteen.

Grow2.ai builds custom AI agents around a client's process, and publishing a list of our own breakages is a slightly awkward way to talk about that. But the advice "monitor the handoffs, not the agents" would be worth exactly nothing without three specific stories where we didn't.

How we build agents, and where we draw the line between what's worth automating and what isn't — on grow2.ai.