A minimal Zen-style illustration of one operator coordinating thirteen parallel flowing streams, one broken, converging into a single check.

Running Thirteen AI Agents in Parallel

An Operations Post-Mortem

One coordinating session drove thirteen parallel agent work units through analysis, implementation, measurement and benchmarking. Here is everything that broke, and the operating rules that came out of it.



TL;DR

  • I ran 13 parallel AI agent work units over 48 hours; the program shipped, the operations broke in systematic ways
  • Background notifications silently fail: never make wake-up mechanisms a dependency
  • Context exhaustion looks like laziness from the outside; it is a terminal symptom
  • Pattern-based kills murder sibling processes: destructive operations must address identity, never description
  • Agent status reports lag, or lie: verify claims against external evidence
  • The worst failure was a “false green”: a validation that passed against code that never ran
  • Every failure mode is an operations problem, not an intelligence problem

The setup

Over roughly 48 hours I ran a personal research program as one coordinating session driving thirteen parallel work units, each executed by AI agents (Claude Code sessions with their own worktrees, ports and build dirs).

The program shipped: a search engine went from 6/14 on its smoke suite to 19/19, gained a 250-record scaled suite, two domain-shift datasets, a public benchmark run, and a test cycle that dropped from 40 minutes to 24 seconds.

This essay is not about that. It is about everything that broke while operating the fleet, because the failure modes turned out to be systematic, and the fixes turned into operating rules I now treat as non-negotiable.

If you are orchestrating more than two agents at once, I suspect you will meet every one of these.

Failure 1: background monitoring does not wake up

The single most expensive failure: background-and-notify patterns (monitor-and-sleep loops, wake-on-completion) stalled or failed to re-wake agents at least seven times across five work units.

One of those cost a full overnight: the work was done, the notification never fired, and the fleet idled for hours.

Operating rule: long validations run as blocking foreground steps with visible output. Wake-up mechanisms are a convenience, never a dependency. A manual ping recovers cleanly from the transcript; a silent stall does not.

Failure 2: context exhaustion looks like laziness

An agent approaching context exhaustion (around 560k tokens in my case) does not crash. It degrades into what I started calling degenerate rest cycles: one small tool call per turn, no progress, no error.

From the outside it looks like the agent got lazy. It is actually dying.

The fix that worked twice: spawn a fresh closer agent and have the dying one produce a text-only knowledge dump: a tree map of the work, known scores, the causal chain of what regressed, a commit plan. The handoff document is what makes the succession cheap.

Operating rule: treat degenerate one-call cycles as a terminal symptom. Institutionalize the handoff dump for long rounds; do not wait for the death rattle.

Failure 3: pattern-based kills murder siblings

A cleanup script used pkill with a process-name pattern. It killed another agent’s benchmark server on a different port, mid-run.

The “fix” moved the pattern, which just moved the victim. Two separate incidents before the real fix.

Operating rule: pidfile-only lifecycle. Every script kills only PIDs it wrote. Pattern kills are banned fleet-wide. The general form: any destructive operation must address identity, never description.

Failure 4: agents’ status reports lag, or lie

Three incidents, one root cause:

  • A flow that reported “running for 53 minutes” was hung.
  • A learn job that reported progress had silently judged another dataset’s values (two collections shared a name).
  • A monitor watching a record-count endpoint declared a healthy ingest “stalled at 0” because the counter only updated on flush.

Operating rule: verify agents’ claims against external evidence: git log, ps, server logs, file mtimes. The agent’s self-report is a hypothesis, not a measurement.

This sounds paranoid until you count how many of your own incidents began with believing a status message.

Failure 5: the false green

The worst one, because it produced a pushed commit with an unverified claim.

A validation “passed” against the OLD binary: the pidfile held a stale PID, so the kill missed the old server; the new server died silently on the old one’s WAL lock; the health check answered from the survivor. Green across the board, and the code under test had never executed.

Operating rule: after every restart, verify that the pidfile PID equals the PID actually listening on the port. A health check proves something is alive. It does not prove the thing you built is what answered.

What made the parallelism work anyway

The rules that held, for balance:

  1. Full isolation per fork: own git worktree, own port, own build target dir, own data dir. Cross-contamination dropped to zero after this became mechanical.
  2. Single owner for contested code. Two agents editing one file is a merge conflict you scheduled on purpose.
  3. Measurement forks are frozen: dataset and expectations committed before the first run, no tuning allowed inside a measurement unit. Diagnose, do not fix. This kept the numbers honest across thirteen units.
  4. Sharing uncommitted work between forks via explicit patch commits marked DROP ON REBASE, never via a shared dirty tree.
  5. A refutation ledger. Every idea that failed is recorded with the evidence and its location (“tried and refuted, do not retry without new evidence”). Fleet memory is what stops agent N+1 from re-proposing what agent 3 disproved.

The meta-lesson

None of these failures is about model intelligence. Every one is an operations problem: process lifecycle, state verification, memory across workers, isolation.

Which is good news, because operations is an engineering discipline we already know how to do. The agents are new; the discipline is not.

Multi-agent orchestration in 2026 feels a lot like distributed systems in 2010: the primitives work, the failure modes are systematic rather than random, and the teams that write down their operating rules compound while everyone else re-discovers them per incident.

Write yours down. Mine are above; steal them.

The discipline these rules point to eventually grew into its own series of essays, starting with Intent Engineering.

Key Takeaways

  • Wake-up mechanisms are a convenience, never a dependency
  • Degenerate one-call cycles mean context death: hand off, do not wait
  • Destructive operations address identity (PIDs), never description (patterns)
  • An agent’s self-report is a hypothesis; verify against external evidence
  • A health check proves something is alive, not that your code is what answered
  • Agent fleets fail like distributed systems, not like chatbots

Authored by Davi Guides
Visit daviguides.github.io for more insights