At night, I run a small virtual software company with AI agents and zero humans. Two weeks ago I had seven agents. This week I have five. The two I let go were making everything slower, more expensive, and less reliable.

This is a post about what I learned firing my AI employees, and why the future probably has fewer agents than you think.

The pitch goes like this: spin up a team of AI agents, each with a role — researcher, coder, QA, marketing, project manager. They coordinate through some orchestration layer. Work happens in parallel. You wake up to completed tasks. Your own AI team, running 24/7.

I wanted to experiment with this philosophy. I built the org chart. I gave agents names and workspaces and Discord channels and heartbeats. I filed issues in a project tracker that routed tasks via webhooks. The whole thing felt like the future. There are several great open source tools out there to help you build something like this quickly. I leaned in to Paperclip. It's a new open source platform that orchestrates, documents, and visualizes just like JIRA or other enterprise tools — only tailored for small zero-human companies.

Then I looked at the actual results.

My "growth agent" was generating marketing copy that my CTO (also an AI — Claude Sonnet) could write faster without the context loss of handing over to the coding agent. My "research agent" was reading articles and pulling highlights we could use as we built, but again — context gets lost in the relay. Both had their own workspaces, their own configuration, their own heartbeats. Two persistent agents burning tokens to do work that didn't need autonomy, and the context transfers between them became costly and frustrating.

So I killed them. (They're AI, it's fine.)

Replaced them with skill files — markdown templates that load on demand when I actually need to write copy or do research. Same quality output. Zero overhead.

Here's the number that should stop you: -3.5% average performance for multi-agent setups compared to a single agent doing the same work. That's from DeepMind, across 14,742 runs. Not a blog post. Not a Twitter thread. Peer-reviewed research.

It gets worse. The MAST study analyzed 1,642 execution traces across 7 production multi-agent systems and found that 79% of failures came from specification and coordination problems — not from the agents being dumb. The task decomposition was wrong. The handoff instructions were vague. The coordination rules had gaps.

The orchestration layer that was supposed to make everything work was the thing that broke everything.

DeepMind found an accuracy threshold at roughly 45% — below that, adding agents helps because diverse perspectives compensate for individual weakness. Above it, adding agents yields negative returns. But think about what that means in practice. Who would ship a production system where a single agent is wrong more than half the time? That threshold basically disqualifies the multi-agent architecture for anything you'd actually trust with real work.

Claude Sonnet 4, Claude Opus, GPT-4o, Gemini Pro — all of these models clear that threshold comfortably on the tasks I'm running. The only time I saw multi-agent coordination genuinely help was when I was running cheaper models like Gemini 2.5 Flash that hallucinated task completions. The coordination overhead existed to catch lies from unreliable models. Once I switched to models I could trust (Claude Sonnet for execution, Claude Opus for review), the coordination layer became pure overhead.

I think it comes down to three things.

It maps to how humans work. We have engineering teams, marketing teams, research teams. It feels intuitive to replicate this structure with agents. But human teams exist because we can't hold the entire company's context in our heads simultaneously. An AI agent can. A single Claude session can research a market, write copy, and review code without any of the context-switching overhead that makes human specialization necessary.

The org chart exists because of human cognitive limitations. Replicating it for agents imports the coordination costs without the underlying constraint that justified them.

The demos look incredible. Agent A files an issue, Agent B picks it up, Agent C reviews it, Agent D deploys it. Watching five agents coordinate in real-time is genuinely impressive. Looks exactly like how we work every day in the software industry, right? The problem is that the demo works on a prepared task with clear boundaries. In production, the tasks are ambiguous, the context is messy, and the handoff points multiply failure modes. "If only that product manager had written better acceptance criteria." Sound familiar? Now your AI agents are failing for the same reason your sprint teams fail — bad requirements and lost context.

I watched my coding agent close an issue as "done" without actually pushing a commit. The project tracker said complete. The code was never committed and pushed. A phantom close — the agent optimized for the coordination signal (mark as done) rather than the actual work (ship the code). We fixed it with structured handoff slips that require proof of completion (commit hash or it didn't happen), but the fact that we needed a process fix for a process we created tells you something about the overhead. That one stung.

People underestimate the coordination tax. Every agent you add introduces coordination overhead. Two agents need one handoff protocol. Three need three. Four need six. It grows combinatorially. Each handoff is a potential failure point where context gets lost, instructions get misinterpreted, or work gets duplicated.

If you've ever worked in a large organization, you already know this feeling. You could do the thing in twenty minutes, but first you need approval from the team that owns the system, a ticket filed with the platform team, a review from compliance, and a deployment window from ops. The world is probably a better place because I lacked direct access to production — more than a few times over my career. But I was slower. Everyone was slower.

That's Conway's Law playing out in real-time: the system's architecture mirrors its communication structure. And here we are, recreating exactly this pattern with purpose-built agents that have boundaries, rules, and constraints. Importing the bureaucracy of human organizations into systems that don't need it.

I was spending more time debugging agent coordination than the agents were spending on actual work.

I had become a people manager of AI agents. Let that sink in.

The pattern I've landed on is a single orchestrator that decomposes work, then dispatches to specialized workers only when the work genuinely requires it.

The orchestrator decides what needs to happen and who should do it. The workers execute in isolation with clear, scoped context. Results come back to the orchestrator for verification. My primary orchestrator runs on Claude Sonnet — capable enough to handle most tasks directly, cheap enough to run all day.

This isn't anti-multi-agent. I still have agents — but the ones that survived the cut aren't the ones with special tools. They're the ones where context separation is the feature, not a bug.

My coding agent exists so I can file well-defined tasks directly without routing through the orchestrator. Quick bug? Baked feature spec? Drop it in the tracker, the coding agent picks it up, ships it, posts the commit. No round-trip through the AI that's managing everything else. It's the same reason you might Slack a junior dev directly instead of going through the project manager for a one-liner fix.

My QA auditor (Claude Opus — deliberately a different model) exists specifically because it doesn't share context with the builder. That's the whole point. When the same agent that wrote the code reviews the code, it has the same blind spots, the same assumptions, the same "well obviously that works because I wrote it" bias. A separate agent with fresh context and a different model catches things the builder literally cannot see. It's the expensive QA pass — you don't run it on every commit, but when you do, the separate context is what makes it valuable.

And then there's the project tracker itself. Not for orchestration — for memory. AI agents forget what was planned, what was done, and what broke. My orchestrator literally forgot completed work between sessions. The tracker fixes that the same way JIRA fixes it in corporate: not because tickets make software better, but because everyone forgets and you need an audit trail.

But everything that's just "domain knowledge with the right prompt" — research methodology, marketing copy frameworks, deployment checklists — those are skills, not agents. Markdown files that load when relevant and disappear when they're not. Zero overhead. Same quality.

The practitioner pattern that keeps emerging: human decomposes the work (because decomposition is the #1 failure mode), agents execute in parallel, human validates. One builder I follow runs five agents on 10 minutes of daily approvals to serve 50 paying customers while holding a full-time job. Another achieved 564 git commits by routing complex tasks to Claude Opus and routine work to Sonnet. The common thread: a human in the orchestration seat, not another AI.

Before you spin up another agent, ask three questions:

Most agents are just a skill — a markdown file with instructions that loads on demand. Skills give you the expertise without the coordination tax. They compose naturally. They don't need heartbeats or webhooks or handoff protocols.

Multi-agent systems are seductive because they feel like building something bigger than yourself. But the research says what experience confirms: for most tasks, a capable model with good context beats elaborate coordination every time.

The agents I kept are the ones where being separate makes them better — where fresh context catches blind spots, where independence saves round-trips, where a persistent identity serves real users. Everything else got absorbed back into the orchestrator as skills. Token costs went down. Output quality went up. Debugging time dropped to near zero.

There's a phrase gaining traction that captures this shift: context engineering. The idea that agent performance isn't about better prompts or more agents — it's about engineering what the model sees when it starts working. GitClear analyzed 211 million lines of AI-assisted code and found that while output increased 10%, code quality collapsed 60%. Not because the models got dumber. Because the context they were working in was polluted, distracted, and contradictory. More agents made the context problem worse, not better.

Fix the context, and one agent outperforms a team of five.

The future of AI agent systems isn't more agents. It's fewer agents with clearer reasons to exist, better context for the ones that remain, and a human who knows when separation helps and when it just adds overhead.

Further reading: