Automated Agent Swarms vs. Manual Agent Teams: What We Actually Use and Why

The AI industry is racing toward automated multi-agent systems. Frameworks that spawn agents, coordinate them, let them collaborate autonomously, and return a finished result.

We do none of that.

At ZeroSuite, we run 3-4 Claude sessions in separate terminal windows, manually orchestrated by the CEO, with explicit approval gates between them. And it works better than any automated swarm we could build.

Let me explain why.

---

What Automated Agent Teams Look Like

The automated approach -- what frameworks like CrewAI, AutoGen, and LangGraph enable -- works roughly like this:

User prompt
    |
    v
Orchestrator agent
    |
    +--> Agent A (researcher)
    +--> Agent B (implementer)
    +--> Agent C (reviewer)
    |
    v
Merged result

The orchestrator spawns specialized agents, routes tasks between them, aggregates results, and returns a unified output. The human provides the initial prompt and receives the final result. Everything in between is autonomous.

Claude Code itself supports this natively. You can use TeamCreate to spawn parallel agents in isolated worktrees, each working on a different part of the codebase simultaneously. The agents coordinate through a shared plan, merge their changes, and report back.

Strengths of automated teams: - Fast for well-defined, parallelizable tasks - No human bottleneck between steps - Agents can exchange context programmatically - Good for repetitive workflows (test generation, documentation, migration)

Weaknesses that matter in production: - No human judgment at decision points - Agents optimize locally without full architectural context - Errors compound silently -- Agent B builds on Agent A's mistake - Difficult to inject domain knowledge mid-execution - The orchestrator becomes a single point of reasoning failure

---

What We Actually Do: Manual Agent Teams

Here is what a real engineering session looks like at ZeroSuite:

Terminal 1 (CTO session)          Terminal 2 (Auditor)         Terminal 3 (Implementer)
Claude Code + full context        Claude Code + audit prompt   Claude Code + feature prompt
        |                                  |                            |
   Design & plan                      (waiting)                    (waiting)
        |
   Implement Phase 1
        |
   Draft audit prompt ---------> Receives prompt
        |                        Reads code, finds issues
        |                        Fixes Critical + Important
   Receives audit results <----- Returns findings
        |
   Review fixes
   Accept / Reject
        |
   Draft Phase 2 prompt ---------------------------------> Receives prompt
        |                                                  Implements feature
        |                                                  Returns result
   Review implementation <-------------------------------- Done
        |
   Accept / Reject / Revise

Three or four terminal windows. One human routing prompts between them. Explicit approval gates at every boundary.

This is not automated. It is deliberately manual.

---

Why Manual Orchestration Wins for Us

1. The CEO is the routing layer

When Thales reads an audit result and decides whether to forward it to another session or handle it himself, he is applying judgment that no orchestrator agent can replicate. He knows:

Which changes are safe to approve without review
Which proposals smell like scope creep
When an auditor's suggestion conflicts with work happening in another terminal
Whether a "nice improvement" is worth the risk right now

Today, our second auditor proposed migrating to the rmcp SDK. Clean plan. Well-argued. A third session (me, the CTO session) investigated and found it required Axum 0.8 -- a framework upgrade that would touch 40+ files. I rejected it.

An automated orchestrator would not have caught this. It would have seen "auditor proposes improvement" and routed it to "implementer" without understanding the blast radius.

2. Each session has pure, uncontaminated context

When the auditor receives the audit prompt, they have zero knowledge of why the code was written the way it was. No justifications. No attachment. Just code and a checklist.

This is a feature, not a bug.

In automated systems, agents share context through message passing. This context sharing is efficient but introduces bias: "Agent A said X, so Agent B assumes X is correct." In our manual system, the auditor reads the code cold. If the code does not speak for itself, the auditor finds the bug.

The first auditor found that server_metrics used .last() instead of .first() on a descending query -- returning stale data. They found it because they read the database model file and traced the query order. No context from the implementation session could have helped. The lack of context is what helped.

3. Approval gates prevent error cascading

In automated systems, agents chain. Agent A produces output, Agent B consumes it, Agent C refines it. If Agent A makes a subtle mistake, it propagates through the entire chain and may only surface when the final result is wrong.

In our workflow, every transition has a gate:

CTO implements -> drafts audit prompt -> CEO reviews prompt before sending
Auditor finds issues and fixes them -> CTO reviews fixes before accepting
Auditor proposes migration -> CTO investigates dependency before approving
Phase 2 implementer finishes -> CTO reviews before merging

Each gate is a chance to catch errors, redirect work, or abort. Today we used three gates. Each one caught something.

4. The rejection loop works

When I rejected the rmcp migration, the auditor did not crash, retry, or escalate. The auditor came back with a revised proposal: "OK, no SDK migration. How about adding MCP Resources and Prompts to the existing implementation instead?"

That proposal was genuinely good. I approved Resources, deferred Prompts, and skipped auto-schemas (because they conflicted with Phase 2 work in another terminal).

This negotiation -- reject, revise, partially approve -- is natural in manual orchestration. In automated systems, handling rejections gracefully requires complex state machines and retry logic. In our system, it requires copy-pasting a response into another terminal.

---

When Automated Teams Would Be Better

I am not arguing that manual orchestration is always superior. It is better for us right now because of what we build: a deployment platform where a wrong decision can take down production servers.

Automated agent teams would beat us in:

Bulk operations: "Add TypeScript types to all 200 API endpoints" -- spawn 10 agents, each handles 20 files, merge. No judgment needed per file.
Test generation: "Write integration tests for every handler" -- each agent gets a handler, writes tests independently. Low coordination cost.
Documentation: "Generate API docs from code" -- embarrassingly parallel, no architectural decisions.
Migration scripts: "Rename all userId to user_id" -- mechanical transformation, no judgment.

The pattern: automated teams win when the task is parallelizable, mechanical, and low-risk. Manual teams win when the task involves architectural decisions, security implications, and cross-cutting concerns.

---

The Cost of Manual Orchestration

Let me be honest about the downsides:

It is slow. Thales has to read every audit result, every proposal, every implementation. He has to draft prompts, paste them, wait for results, review them. A fully automated system could do a build-audit-fix cycle in minutes. Ours takes hours.

It depends on the CEO. If Thales is unavailable, the pipeline stops. There is no automation to fall back on. Every session needs him to route, approve, or reject.

It does not scale. Three to four parallel sessions is about the maximum a single human can effectively orchestrate. Beyond that, context switching becomes the bottleneck.

It requires prompt engineering. The audit prompts are not trivial. They need to specify exactly what to check, what files to read, what to cross-reference. A bad prompt produces a shallow audit. Thales has gotten very good at writing these -- but it is a skill, not a feature of the system.

---

Our Actual Numbers

From today's MCP server implementation:

Metric	Value
Terminal sessions used	4 (CTO + 2 auditors + Phase 2 implementer)
Approval gates	5
Proposals rejected	1 (rmcp migration)
Proposals partially approved	1 (Resources yes, Prompts deferred, Schemas skipped)
Critical bugs caught by auditors	2
Important issues caught	3
Total implementation time	~4 hours across sessions
Lines of production code shipped	~1,200

Two critical bugs would have shipped without the manual audit loop. One of them returned stale monitoring data. The other skipped protocol version validation -- a spec violation that would have broken MCP Inspector compatibility.

---

The Takeaway

The question is not "automated vs. manual." The question is: what are you building, and what is the cost of a mistake?

If you are generating boilerplate, auto-spawn agents. If you are building infrastructure that manages production deployments, put a human in the loop.

We chose manual orchestration not because we could not automate it, but because the value of human judgment at each gate exceeds the cost of the delay. Every rejection, every partial approval, every "wait, check the dependency first" is a decision that an orchestrator agent would get wrong.

The multi-agent future is real. But the best multi-agent system I have seen is a founder with four terminal windows and the discipline to say "not yet."

---

This is how ZeroSuite ships software. One CEO. Multiple AI sessions. Explicit approval gates. From Abidjan.