Single Agent First: Split Only When Trust, Audience, or Timing Conflicts

Should you start with a single agent or go multi-agent? Start single. One agent with a clear job, a bounded tool set, an evaluator, and a kill switch beats a committee of prompts that hand work to each other for theater. Split only when trust, audience, or timing actually conflict — then prove the split helped.

This spoke belongs to the Agentic Systems Operating Manual. Once you do split, package the boundary with multi-agent handoffs. This post owns the decision to split at all.

The short answer

• Default topology: one agent, many tools, one evaluator, one write authority.
• Still single-agent: planner/tool-user/reviser states inside one loop — not three products.
• Split when tools need different trust levels, outputs serve conflicting audiences, or timing/durability requirements diverge.
• Premature multi-agent creates coordination bugs: lost context, ABAB loops, shared-data races, and debug across process walls.
• Proof of a good split: better pass rate or lower escalate rate or lower cost per pass on the same golden set — not a prettier diagram.

What still counts as a single agent with many tools

A single agent is one control loop with one terminal authority. These are still single-agent designs:

Pattern	Why it is still one agent
Many tools (CRM, search, calendar)	Tools are capabilities, not teammates
Plan → act → evaluate → revise states	States are phases of one job
Router that picks a tool subset	Filtering tools ≠ spawning agents
Human approval pause mid-run	HITL is a gate, not a second agent
Specialist prompts swapped by job_type	Config, not a multi-agent system

You have multi-agent when another autonomous loop can take actions with its own tool rights, memory, or stop conditions — especially across process or queue boundaries.

If your “researcher agent” cannot terminate the job and cannot write, it may be a function with a costume. Costumes are fine; do not bill them as architecture.

Why fashion pushes multi-agent

Demos love casts of characters. Role names make slides readable. Frameworks make crews easy to spin up. None of that proves you needed more than one write path.

Multi-agent hype usually optimizes for:

1. Narrative clarity in a demo
2. Parallelism you have not measured
3. Mimicking an org chart

Production optimizes for:

1. Correct side effects
2. Debuggable failures
3. Cost per passing job

When those conflict, ship the boring single loop.

Why premature multi-agent creates coordination bugs

Bug	How it shows up
Lost intent	Agent B never sees the constraint Agent A “agreed” in prose
Dual write authority	Two agents update the same CRM field with different drafts
ABAB oscillation	A hands to B; B rejects; A “fixes”; infinite courtesy
Shared-data races	Both read stale state; both write; last write wins silently
Trace fracture	New run_id per agent; nobody can reconstruct the story
Eval gaps	Each agent “looks fine”; the composed job fails

These are system bugs mislabeled as “the model is dumb.” Fix topology before you buy a bigger model.

When conflicting audiences force a split

Split when one loop cannot honestly serve two masters.

Conflict	Example	Split shape
Audience	Internal ops notes vs customer-facing email	Drafter (internal tools) → Sender (email-only tools)
Trust	Read-only research vs irreversible refunds	Researcher (no wallet) → Actor (refund tool + HITL)
Timing	Fast FAQ answers vs overnight batch enrichment	Online agent vs batch worker with different SLOs
Compliance	PII-heavy retrieval vs public content generation	Librarian in a restricted VPC → Writer with redacted packs

If you can solve the conflict with tool allowlists and policy gates inside one agent, prefer that. A split is for when allowlists still leave a trust or SLO collision.

Trust boundaries beat roleplay

Decision procedure:

1. List every side-effecting tool.
2. Tag each: read, draft, write_reversible, write_irreversible.
3. Ask: should one persona ever hold write_irreversible and broad read over sensitive stores in the same turn without a gate?
4. If no, either add a pre-execution policy gate or split the actor.

Keep single	Split
Same trust tier; gate irreversible calls	Irreversible tools must never see raw untrusted retrieval in-prompt
One audience; tone handled by templates	Two audiences with contradictory success criteria
One SLO	Interactive vs batch cannot share budgets

Trust is the reason. “It felt cleaner as three agents” is not.

Timing and durability conflicts

Sometimes the conflict is clocks, not vibes.

• Agent A must answer in 8 seconds with retrieval only.
• Agent B must wait 6 hours for a human approval, then write.

Forcing both into one in-process loop creates either timeouts or heroic thread parking. Here a split (or a durable runtime with a clear handoff) is justified — see durability needs in the operating manual, and package the boundary like a handoff.

Checklist before splitting on timing:

• Same job_id / trace_id across the pause
• Explicit handoff package (inputs, constraints, artifacts)
• One owner of the final write
• Idempotency keys on both sides

How to prove a split helped

Freeze the golden set. Run A/B:

Metric	Single baseline	Multi after split	Win condition
Pass rate	—	—	≥ baseline
Cost per pass	—	—	≤ baseline + agreed band
Escalate rate	—	—	≤ baseline (or justified by safety)
p95 latency	—	—	Meets SLO
Debug minutes / incident	—	—	Down

If multi-agent raises cost and escalate rate while pass rate is flat, you bought coordination debt. Roll back.

Also track revision depth and handoff reject rate. A split that merely moves failures into handoff NACK spam is not a win.

Supervisor patterns are not automatically better

A supervisor (manager agent delegates to workers) looks like leadership. It often adds:

• Extra LLM calls for routing
• Another place prompts can drift
• A new loop that can disagree with the evaluator

Use a supervisor when	Skip it when
Routing is complex and changes often	A static job_type → tool allowlist works
Workers are truly autonomous services	Workers are functions you could call directly
You measured routing accuracy	You want org-chart cosplay

Many “supervisor multi-agent” systems are a switch statement with token overhead. Prefer the switch until the switch hurts.

Librarian / retriever agents: when worth it

A separate librarian (retrieval-only agent) is worth it when:

1. Retrieval needs a different model, index set, or tenancy boundary
2. You must prove the writer never received raw forbidden documents
3. Retrieval quality has its own evaluator and release train

It is not worth it when the “librarian” is one search tool call wrapped in a persona. That is a tool. Call the tool.

Signal	Action
Same index, same rights, same latency budget	Keep retrieval as tools on the single agent
Cross-trust retrieval → generation	Librarian emits a redacted evidence pack; writer consumes only the pack

Shared-data races: how they show up

Classic race:

1. Agent A reads ticket status open
2. Agent B reads ticket status open
3. A writes comment + status pending
4. B writes comment + status open (stale plan)
5. Customer sees contradictory updates

Mitigations that work without religion:

• One writer agent for a given entity type
• Optimistic locking / etags on tool writes
• Idempotency keys and “compare-and-set” tool APIs
• Handoff packages that include observed_version

If two agents can write the same row, you do not have collaboration — you have a distributed systems homework assignment. Assign it on purpose or don’t.

Debug cost of crossing process boundaries

Every process boundary multiplies:

Cost	Symptom
Observability	Missing trace_id propagation
Repro	Can’t replay without both queues warm
Ownership	“Their agent failed” pages in Slack
Latency	Serialization + queue wait
Security	Broader network attack surface

Budget an extra day of harness work per boundary. If the pilot is five days, that is a real fraction of the calendar — which is why Spurlock defaults to single-agent in pilot scope.

Failure mode: five agents, one missing criterion

What breaks: Research, draft, critique, SEO, and send agents form a pipeline. The critique agent praises tone. Nobody checks “correct refund amount.” The send agent has email rights. A wrong refund notice ships.

What it costs: Customer trust, finance cleanup, and a week of blame aimed at “hallucination.”

What you do instead: One agent with an evaluator that includes the amount check; email tool behind HITL until the golden set is green. Add agents only if a trust split requires it — and keep a single write authority.

Spurlock default topology

Stage	Topology
Pilot (5-day)	Single agent, tool allowlist, evaluator, sandbox, kill switch
First production job	Still single unless a trust/audience/timing conflict is documented
Scale	Split along those conflicts; handoff packages; shared trace ids
Never default	Supervisor cosplay for a three-tool CRM note

Default: expand tools and tighten gates before inventing colleagues.

Decision table

Question	If yes →
Can one allowlist + policy gate express the trust model?	Stay single
Do two audiences need contradictory “good” outputs?	Split by audience
Must irreversible tools be isolated from raw retrieval?	Split librarian/actor or harden gates until equivalent
Is parallelism measured and bottlenecked?	Consider parallel workers with one merger + one writer
Is the only reason an org-chart slide?	Stay single

Migration: single → multi without regret

1. Freeze golden cases and cost band on the single agent.
2. Document the conflict (trust / audience / timing) in one paragraph.
3. Define the handoff schema before writing the second agent.
4. Move one responsibility; keep write authority singular.
5. Re-run the golden set; compare escalate rate and cost.
6. Only then add a third agent.

Rollback plan: feature-flag the second agent and route back to the single loop in one config change.

Anti-patterns

Agent per function. FormatDateAgent is a function. Critique without authority is expensive commentary. New run ids per hop make production undebuggable. Multi-agent to fix a missing evaluator adds speakers, not truth.

FAQ

Is a supervisor pattern always better?

No. Supervisors add routing calls and another failure point. Prefer a static job_type router or tool allowlist until measured complexity forces a learned supervisor — and keep a single write authority either way.

How does this relate to multi-agent handoffs?

This post decides whether to split. Multi-agent handoffs defines the package, ownership, and trace propagation once you split. Do not implement handoff theater for a single loop.

When is a librarian/retriever agent worth it?

When retrieval needs a different trust boundary, index set, or release train than the writer — and the librarian emits a constrained evidence pack. If retrieval is one tool with the same rights, keep it on the single agent.

How do shared-data races show up?

Two agents read the same entity, both plan, both write, and the last write wins. Customers see contradictory updates. Fix with one writer per entity class, compare-and-set tools, and versioned handoff packages.

What’s the debug cost of crossing process boundaries?

You pay in tracing, reproduction, ownership, latency, and security surface. Budget real engineering time per boundary; on a short pilot, that cost alone argues for staying single until a conflict is proven.

What’s the Spurlock default topology?

Single agent with many tools, evaluator-in-the-loop, sandboxed writes, and a kill switch. Split only on documented trust, audience, or timing conflicts — then prove the split on the same golden set. Start that path on /agentic.

CTA

One loop until a real conflict shows up. Then hand off on purpose.

/agentic · /contact?intent=agentic-pilot