title: "Why your AI agent stack breaks at ten agents" slug: "why-your-agent-stack-breaks-at-ten" dek: "Past a handful of agents, the limiting factor isn't model quality — it's not knowing what's running, what's stuck, or what needs a look before it ships." audience: "Solo and small-team founders running multiple AI agents across their company" tags: [multi-agent-systems, ai-agents, git, founder-tools, supervision]

The tenth agent

One agent working your inbox is easy to trust. Two — one on the inbox, one drafting the investor update — is still manageable. By the time you're running five or six across support, content, outreach, and bookkeeping, something shifts. It isn't that any single agent got worse. It's that you no longer know, at any given moment, what all of them are doing.

A founder describing this exact moment on Indie Hackers put it plainly: past a certain scale, "the problem was not intelligence anymore, it was visibility and supervision". The models didn't get dumber. The founder's ability to answer basic questions did — what's running right now, what's stuck, what needs review, what quietly failed overnight. Nobody built for those questions, so nobody can answer them.

A distributed system with none of the tooling

This isn't a new failure mode. It's an old one in a new costume. Several independent processes, each holding its own partial view of the world, acting on stale or missing information — that's a distributed system. Distributed systems fail in well-documented ways: race conditions, stale reads, two writers clobbering the same resource. Multi-agent stacks have all of that and almost none of the tooling built up over decades to catch it.

The research on multi-agent LLM systems backs this up more precisely than most people expect. A failure-mode study spanning seven multi-agent frameworks and 1,600+ execution traces found that inter-agent misalignment — agents simply failing to share critical information with each other — accounts for 36.9% of all observed failures. Not hallucination. Not weak reasoning. Agents that didn't tell each other, or you, what they knew.

That number reframes the problem. You don't fix a 37% communication-failure rate by upgrading to a smarter model. You fix it by giving every agent, and yourself, one place to check what's actually true right now.

What's actually missing

The usual response to agent sprawl is more orchestration: a manager agent, a message bus, another dashboard. That treats the symptom. A dashboard tells you an agent ran. It doesn't tell you whether what it produced is safe to act on, or whether another agent tried something conflicting an hour earlier.

What's missing is a shared, durable record of company state: one every agent reads before it acts and writes to when it's done, and one a human can inspect without tailing logs. Not a new database with a bespoke schema per agent — a substrate that already has a mature toolchain for exactly this problem: propose a change, show the difference, require a human look before it's accepted.

That toolchain is git.

One repo, one queue

Lycato treats a company like a codebase. A local CLI (lycato) and a local web Cockpit both read and write a single git repository that holds the substrate: people and CRM, money — ledger, runway, reconciliation — a decisions log, obligations and compliance deadlines, investor updates, KPI snapshots, the inbox, a content queue, and a basic cap table. All of it is plain markdown, versioned, readable without a special client. Data from Mercury, Stripe, GitHub, and Plain arrives as commits into that same repo, not as separate dashboards to check.

Every agent reads that repo before acting. When one wants to change something, it doesn't just act — it proposes a diff:

--- a/company/decisions.md
+++ b/company/decisions.md
@@ -12,3 +12,8 @@
 ## 2026-06-30 — Switched payroll provider
 Rationale: Gusto pricing changed for our headcount tier.
 Owner: founder
+
+## 2026-07-07 — Pause outbound to unverified leads
+Rationale: bounce rate hit 22% on last campaign; outreach agent was about
+to queue 400 more sends against the same list.
+Owner: proposed by outreach-agent, pending review

You read that the way you'd read a pull request. Approve it and it merges into shared state, where every other agent now sees it. Reject it and nothing happened. Either way, the attempt is in the log, in plain text, permanently.

Visibility stops being a separate problem you have to solve. "What's running, what's stuck, what needs review" is just a query over the repo: open diffs, pending commits, agents that haven't checked in. Lycato's Cockpit puts that query on its own surface — Review — next to Today, Work, and Company, instead of leaving it buried in a log stream only you know to go looking through.

What this doesn't fix

Lycato doesn't make any agent smarter. It doesn't eliminate the failures where an agent is simply wrong — it makes those failures visible and reviewable before they become company state, which is different from preventing them. It doesn't auto-resolve two agents proposing conflicting diffs; you resolve those the same way you'd resolve a merge conflict, by reading both and deciding. And it doesn't remove the human from the loop. That's deliberate — nothing merges without your approval. If what you want is autonomous, unreviewed execution, Lycato is the wrong tool.

It also doesn't hide agent cost behind a subscription. You bring your own Anthropic, OpenAI, or Gemini key and pay raw token cost — no per-seat markup. The repo itself is yours: self-hosted, AGPL-3.0, not rented behind someone else's API.

The takeaway

Somewhere between three agents and ten, the limiting factor stops being how good any one agent is and starts being whether you can see what all of them are doing and stop the bad ones before they ship. That's a supervision problem, and it has a boring, well-understood answer: one shared source of truth, and a queue where every change waits for a human before it counts. Git already does the first half. The second half is just deciding to use it that way.