The simplest possible architecture for a content system is one model. The model reads a brief, drafts a post, decides whether to publish it, and publishes it. We tried this. It is wrong. This is the case for separating the decision into eighteen agents, why each one has a name and a job, and what the audit log looks like when that separation is enforced.
A word before the argument. We are not against large models. Every one of the eighteen agents is a large model doing a small job. The disagreement is not about power. It is about where the seams go. A single seam that runs the whole pipeline is a system with one point of failure and no place to stand while you fix it. Eighteen seams is a system you can hold still and repair.
Why one big model is tempting
It is one component to deploy, one set of weights to update, one prompt to design. The latency is low. The infrastructure is small. The team is small.
It is also opaque. When the model publishes a post that violates a platform’s policy, the team has no name to put on the failure — no agent that can be debugged in isolation, no rule that can be audited and tightened. The blast radius of every decision is the same as the blast radius of the entire system.
We watched this happen for six months. The model was good. The audit story was bad. We rebuilt.
Here is the shape of the bad audit story. A post goes out that should not have. Someone asks why. The honest answer is “the model decided to,” which is not an answer a platform accepts, and not an answer a team can act on. There is nothing to open. There is no threshold to move, no rule to rewrite, no column that names the step that failed. You can retrain the whole thing and hope. Hoping is not a remediation plan. It is the absence of one.
The eighteen agents
Each of the eighteen has one job. We gave each a name so the team and the operator dashboard can refer to them. We constrained each agent’s scope so that a failure in one cannot cascade into a failure in another without a row in the audit log marking the cascade.
The full list is at /product. The shape:
- Listening agents read the social graph: Hypothesis, Strategy, Niche Resonance.
- Decision agents score and stop: Feasibility, Decision, Pattern Abstraction, Legal Compliance.
- Production agents make the artefact: Script Gen, Asset Gen, Video Gen.
- Action agents publish and read back: Publishing, Feedback, Community.
- Operations agents keep the system honest: Channel Setup, Revenue Model, Autonomous Ops.
- Editorial agents maintain the standards: Pillar, Foundation.
Each is a small component. None has the authority to publish without the others. The audit log records which agent made which call, with which inputs.
The naming matters more than it looks. A named agent is a thing a team can talk about at a stand-up. “Feasibility is rejecting too much this week” is a sentence with an owner and a next step. “The model is off” is not. Names turn a diffuse worry into a specific ticket. A specific ticket gets fixed. A diffuse worry gets discussed and survives to the next meeting.
The cost of separation
Every separation has a cost. Eighteen agents talk to each other; the orchestration layer is the codebase’s most carefully-designed surface. The latency is higher than a single-model architecture — but the latency target is “fast enough to publish on a platform schedule,” not “fast enough to feel real-time.”
The operational cost is also higher. Eighteen agents run on language-model inference; the bills are visible in the operator dashboard’s monthly cost line. We have decided this is the right cost to pay.
We watch that cost closely, because a system of many agents can waste money quietly. Every agent call is metered. Every metered call rolls up into a per-stream cost the operator can read. When one agent starts spending more than its work is worth, the line shows it, and we tune that agent alone. In the one-big-model world the bill is a single number with no story. In this world the bill has eighteen line items, and each line item has an owner who can bring it down.
The benefits we have measured
After a year of running both architectures side by side on partial workloads:
-
Failures are localised. When something publishes that should not have, the audit log identifies which agent failed. We tighten that agent. The fix takes hours; in the one-big-model architecture it took weeks of fine-tuning.
-
The team understands the system. A new engineer can read the description of one agent and contribute to it within a day. In the one-big-model architecture, contributing required reading the whole prompt and a six-month context document.
-
The audit log is genuinely informative. A row that says “Decision rejected proposal #87 because the niche threshold was 0.91 and the proposal scored 0.73” is a row a human can act on. A row that says “the model declined” is not.
-
Improvements do not collide. Two engineers can change two agents in the same week without either change stepping on the other. In one prompt shared by everyone, every edit is a merge conflict waiting to happen. Separate agents give separate surfaces to work on, so the team’s throughput scales with its size instead of stalling at one editor deep in a single file.
What we did not separate
A separation that adds no clarity is just overhead. We did not split:
- The brand-voice layer from the editorial layer (Foundation owns both — they are the same standard).
- The script writer from the asset prompter (Script Gen drafts both; Asset Gen renders).
- The operator’s intent from the platform’s policy (operator intent is an input to every agent; platform policy is its own agent because policies change without notice).
The line we drew is: separate when separation buys you a name, an audit-log column, and a debuggable surface. Otherwise, do not.
This restraint is as important as the split itself. A team that loves the pattern will keep splitting until it has a hundred tiny agents and a coordination problem larger than the one it started with. We stopped at the point where each new seam stopped paying for itself. Eighteen is not a magic number. It is the count at which every agent still earns its name. Add a nineteenth only when there is a call the existing eighteen cannot cleanly own.
How the agents disagree
A single model has no way to argue with itself in the open. Our eighteen do it constantly, and the argument is the point. Hypothesis proposes; Feasibility pushes back on cost; Legal Compliance can veto regardless of what the others want. Each of these is a checkpoint with a reason attached. When Legal Compliance blocks a draft, the block is a row, and the row names the missing disclosure. The operator can read exactly why the draft stopped, then supply the disclosure, then watch it pass.
Contrast the single model, which folds all of these judgments into one silent forward pass. The judgments still happen — the model still weighs cost against reach against risk — but they happen inside the weights, unlogged and unarguable. We pulled those judgments out into the light. Each one is now a step you can name, a step you can time, and a step you can override with a reason of your own. That is what “correctible” means in the thesis at the top of this page. A system you cannot argue with is a system you cannot correct.
A failure, traced
Let me trace one real failure end to end, because the tracing is the whole argument. A post shipped that used a claim we could not support. In the single-model world this is a dead end. You know the post was wrong. You do not know why the system chose it. You retrain and hope.
In our world the failure has a path. The log shows the claim entered at Hypothesis, drawn from a source the agent trusted too much. It shows Feasibility passed it, because Feasibility prices cost against reach and does not check claims. It shows Legal Compliance let it through, because the claim was not a regulated disclosure, only an unsupported one. Three rows, three agents, one gap between them: no agent owned “is this claim true.”
That gap is a fix, not a mystery. We gave the ownership to a named check and set its threshold. The next time a similar claim appeared, the check caught it, and the catch is a row you can read. The failure taught us exactly one thing and pointed at exactly one place to put it. A single model would have taught us only that it was, in general, sometimes wrong. You cannot ship a fix against “sometimes wrong.”
Why not just fine-tune the one model
The obvious objection is that a single model can be corrected too. Fine-tune it on the failure and move on. We tried this for six months, so the objection is one we have lived. It does not hold, for two reasons.
The first is blast radius. A fine-tune changes the whole model at once. You fix the claim problem and you cannot be sure you have not moved something else — a tone, a length habit, a judgment on an unrelated niche. Every fix is a full-system change with a full-system risk. You end up testing everything after touching anything, which is slow, or testing nothing, which is worse.
The second is legibility. A fine-tune leaves no readable trace. There is no row that says “this behaviour changed because of that lesson.” The lesson lives in the weights, unsearchable, and six months later nobody can say why the model does what it does. Our separate agents keep the lesson in the open. A changed threshold is a line in a change log with a date and a reason. The system’s history stays readable, which means the system stays correctable by people who were not there when the rule was written.
The orchestration layer
Eighteen agents that do not coordinate are eighteen problems, not one system. So the orchestration layer — the part that routes work from agent to agent — is the surface we designed with the most care. It is deterministic. Given the same inputs, it makes the same routing choices, every time, which is what lets us replay any decision and get the same path.
Determinism is not a detail here. It is what makes the audit log trustworthy. If the same proposal could take two different routes on two different runs, the log would record history without explaining it. Because the routing is fixed and recorded, the log is not just a diary. It is a thing you can re-run. A reviewer who doubts a decision can watch it happen again, identically, from the same inputs. That is a stronger claim than “we wrote down what we did.” It is “we can show you it again.”
Building the layer this way was the hard part of the whole system, and we do not pretend otherwise. Coordination is where a system of many parts tends to fail. An agent waits on another that never answers. A message arrives twice. A stage runs before the stage it depends on. We spent most of the rebuild here, not on the agents themselves, because the agents were the easy part and the wiring between them was the risk. The wiring is where a clean idea becomes a working desk or a tangle. We treated it as the load-bearing surface it is.
The layer also enforces the one rule that keeps the separation honest: no agent publishes alone. Publication is the end of a chain, and the chain is fixed. An agent cannot skip ahead, cannot grant itself authority it was not given, and cannot cascade a failure into the next stage without leaving a row that marks the cascade. The separation would be cosmetic if any agent could quietly overrun it. The orchestration layer is what makes the separation real.
What the operator gains from the split
An operator does not care about architecture for its own sake. They care about control, cost, and trust. The split delivers all three, and it is worth spelling out how, because the benefits are not abstract.
Control comes from the seams. An operator who wants the desk to reject harder can raise one agent’s threshold and watch the effect. An operator who thinks production is too expensive can cap one agent’s budget. Each lever is separate, so pulling one does not disturb the rest. In a single model there are no levers, only a prompt and a hope. The operator’s only move is to ask for a change and wait to see whether the whole system shifted the way they meant. Separate agents turn hope into a set of dials.
Cost comes from the metering. Because every agent bills separately, the operator can see where the money goes and cut the line that is not paying its way. A single opaque bill hides waste; eighteen line items expose it. The operator can run the desk lean without guessing, because the guessing has been replaced by a breakdown.
Trust comes from the log, and trust is the one that closes deals. When a platform, a partner, or a client asks why a thing was published, the operator does not have to defend a black box. They open the row. The row names the agent, the input, the rule, and the score. A question that would sink a single-model shop is, for us, a query with an answer. The operator hands over the answer and moves on. That is worth more than any latency saved by collapsing the desk into one model.
The trade-off, stated honestly
The one-big-model architecture is faster to ship. Ours is faster to fix. We pay the upfront cost to ship the eighteen agents because we expect to spend years fixing failures, and a system that takes weeks to fix is a system that has already lost.
The plain-language version, for an operator deciding whether this matters: the first architecture is cheaper this quarter and more expensive every quarter after. Ours is the reverse. The bet is that the business runs for years, that platforms will keep changing their rules, and that the desk which can adapt in an afternoon beats the desk which needs a retraining run every time a policy moves. We have taken that bet with our own money.
This is the case. The audit log is the proof.
The full agent list is at /product. Comments via [email protected].