After building more than 20 agents across Python, TypeScript, Go, and custom frameworks, I no longer begin a multiagent system by drawing an organizational chart.

The manager, researcher, writer, reviewer, and planner metaphor is easy to understand. It is also one of the fastest ways to hide vague responsibilities behind convincing names. The agents chat, the demo looks alive, and the production system becomes expensive to inspect.

I prefer a factory: queues, workcells, explicit contracts, artifact handoffs, quality gates, rework lanes, and clear human exception paths.

This is not a claim that every agent workflow needs industrial architecture. It is a lesson about repeated work. Once an agent system must produce reliable output for a business, I care less about whether it feels like a team and more about whether its work is measurable, reviewable, and difficult to fake.

The production system that made this concrete

The clearest example was an agent native SEO department I built inside a GTM operating system. It had a manager agent and three specialist agents, but those roles were not what made the system work.

Airtable held the production queue. Approved briefs entered a defined process. Research, writing, infographic generation, CMS staging, and verification produced durable artifacts. Humans retained the final publication decision. Weak output returned to a visible rework state instead of disappearing into another round of agent conversation.

The system produced more than 40 articles, with 7 to 8 entering the first public rollout. A typical article took about 90 minutes to produce. Those numbers mattered, but the architecture mattered more: every completed unit of work had a state, an artifact trail, and a human owner at the consequential boundary.

That experience changed how I evaluate agent architecture.

What agent architecture should optimize for

Architecture discussions often begin with three questions:

  • How do I make multiple agents collaborate?
  • How do I assign realistic roles?
  • How do I make the system feel autonomous?

Those are demo questions. Production asks different ones:

  • How does work enter the system?
  • What exact artifact must each worker produce?
  • Where does review happen?
  • What is retried, and what is escalated?
  • Can an operator see what changed and why?
  • What is the cost per completed unit of useful work?

A serious system optimizes for throughput, bounded autonomy, clear handoffs, quality control, observability, auditability, and cost discipline.

The architecture is not good because it feels intelligent. It is good because these surfaces remain legible.

Why fake teams break

The team metaphor is seductive because everyone understands an organizational chart. It is easy to draw and easy to pitch.

It also creates predictable failure modes.

Role names hide vague contracts

“Researcher” and “reviewer” sound clear until you ask what exact output each role owns.

If the worker contract is vague, downstream failures become difficult to diagnose. Did the planner underspecify the task? Did the writer misunderstand it? Did the reviewer overstep? Or did every worker do part of every other worker’s job?

A role name is not an interface.

Conversation replaces system design

Many orchestration systems are agents talking to each other because nobody built a real handoff model.

That produces repeated reading, context loss, unstable output shapes, higher latency, higher cost, and weaker accountability. If information can be encoded once in a schema, checklist, or queue record, paying for repeated conversation is a design failure.

Nothing durable exists between steps

If the handoff is only another message in a chat, the system has no strong spine. The work is difficult to diff, replay, audit, or review.

Autonomy feels attractive until someone needs to trust the result.

Humans quietly repair the system

Many fake teams work because a person handles the difficult parts in the background: repairing briefs, resolving contradictions, rewriting prompts, judging output quality, and carrying business context the architecture failed to encode.

The system is not autonomous. It is leaking work.

Working beside employees made those leaks visible. People were resolving ambiguity, carrying context between tools, and correcting outputs in ways the architecture did not record. Those conversations were not resistance to automation. They were requirements discovery. Every recurring repair pointed to a missing contract, state, artifact, or escalation path.

Token use is mistaken for collaboration

More dialogue can support better reasoning, but it can also be a coordination tax. If workers exchange information that should have been part of a contract or artifact, more tokens do not make the system more sophisticated.

Under real load, the same symptoms appear: the queue looks busy but nothing lands, review is inconsistent, workers drift, costs rise, and people begin bypassing the system.

The factory model

Factory architecture treats agent work as an explicit production flow:

  1. intake;
  2. routing;
  3. bounded execution;
  4. artifact creation;
  5. quality review;
  6. rework or application;
  7. archive, metrics, and audit.

It sounds less romantic than collaboration between artificial employees. I have found it far more useful.

Queue

The queue makes work visible. It states what is waiting, active, blocked, under review, or complete.

Without a queue, systems confuse conversation state with operating state.

Workcell

A workcell is a bounded worker or worker lane with one clear responsibility.

Examples include drafting an article from an approved brief, collecting a specific evidence set, proposing conservative repository maintenance, or reconciling a ledger against live state.

Contract

The contract defines what a worker receives and what it must produce. Good contracts specify allowed inputs, required outputs, evidence expectations, safety limits, and the correct response to uncertainty.

Artifact handoff

Every meaningful step leaves behind something inspectable: a draft, report, patch, decision object, review note, or state transition.

Artifacts make review, replay, and recovery possible. They also prevent a downstream agent from relying on a compressed summary when the full work exists.

Review and rework

Every serious system needs an explicit answer to who checks what before mutation, publication, or closure.

Weak output should enter a rework lane instead of triggering more unstructured conversation. The system must distinguish incomplete work, contract violations, retryable failures, and situations that require a person.

Proposal and mutation

Whenever trust matters, separate the worker that proposes a change from the step that mutates live state.

The system that concludes “this seems correct” does not automatically need permission to publish content, merge code, close an issue, or update a customer record.

This one separation improves a surprising number of agent systems.

Generalists and specialists

Not every worker should be specialized, and not every worker should remain general.

A generalist is useful when the task family is broad, the workflow is still changing, and the queue requires flexible interpretation. Generalists work well as routers, first pass operators, and drafters.

A specialist is useful when the same task repeats, trust boundaries matter, failure cost is high, or a typed decision contract removes ambiguity. Specialists work well for controlled audits, governed classification, verification, and narrow mutation.

Healthy architecture often starts broad and specializes where repeated failures prove the need.

Seven rules I use

1. Make queue state the source of truth

Do not infer operating state from chat logs. The queue records it explicitly.

2. Give every worker one obvious contract

Each worker knows what it receives, what it emits, and when it must refuse or escalate.

3. Emit artifacts, not only conversation

If a step matters, it leaves behind something inspectable.

4. Separate proposal from mutation

This is especially important for code, publishing, account changes, and other consequential actions.

5. Make review and rework visible

Do not hide quality control inside another vague reviewer role. Give it state, criteria, and an owner.

6. Specialize only when evidence supports it

Do not prebuild an artificial org chart. Let throughput problems and recurring failure modes reveal where harder boundaries pay off.

7. Treat observability as architecture

A system that cannot explain its state is not mature, regardless of how polished the demo looks.

The agent native SEO department documents this shape in production, including the working queue, agent responsibilities, artifacts, and approval boundary.

When not to build a factory

The factory model is for repeated, governed work. It is unnecessary when one tool call solves the task, the queue is tiny, output is too ambiguous for a stable contract, failure cost is low, or a normal script is cleaner.

Architecture earns its complexity through repeated work. It should never exist only to make a system look more autonomous.

The decision I now make

Fake teams optimize for narrative. Factories optimize for operations.

If the system must survive real use, I think less about role play and more about queues, workcells, contracts, artifacts, review, and rework. If a simple agent or script can do the work, I keep it simple. If repeated work needs throughput, governance, and quality control, I build the production line deliberately.

The enterprise GTM operating system is the larger implementation of this idea: an internal agent factory surrounded by context, traces, skills, approvals, and integrations.