We are unusually transparent about what the engine does. We publish [weekly diffs](/blog/14-changes-shipped-this-week) of every change, we name what the [critic rejected](/blog/the-critic-gate-matters-most), and we tell clients exactly why each edit shipped. And we are deliberately, unapologetically opaque about one thing: the orchestration graph — the specific wiring of how the 160+ agents coordinate, hand off, and check each other.
People notice the asymmetry and ask about it, fairly. So here is the honest answer — both the commercial reason and the strategic one — and why we think opacity about the mechanism is fully compatible with transparency about outcomes.
What is the orchestration graph?
The orchestration graph is the architecture that turns 160+ narrow agents into one coherent operator: which agent runs when, what each one is allowed to touch, how work hands off between them, where the critic gates sit, and how conflicts get resolved. It is the difference between a pile of capable agents and a system that behaves like a tireless, coordinated team.
The individual agents are not the secret — most are narrow and, frankly, [boring by design](/blog/the-case-for-boring-agents). The base models underneath are available to anyone. The value is in the wiring: the accumulated decisions about how the pieces connect, where to put guardrails, and what to do when two agents disagree. That graph is the product.
The agents are commodities. The base models are commodities. The graph that makes them behave like one operator is not.
What is the honest commercial reason?
The honest commercial reason is simple: the graph is the moat, and almost nothing else is. Anyone can rent the same models and prompt them to write copy. What they cannot trivially copy is years of accumulated decisions about orchestration — the failure modes we have already hit and routed around, the guardrails earned through mistakes, the specific topology that makes the system reliable instead of impressive.
Publishing that graph would be handing competitors the one asset that is expensive to reproduce. We do not think clients actually want us to do that, any more than they want their accountant to publish the firm's internal methods. They want the results, the accountability, and the ability to leave — all of which we provide without exposing the wiring.
What is the honest strategic reason?
The strategic reason is subtler: the graph changes constantly, so any public documentation of it would be misleading the day after we published it. The engine's whole premise is that it improves itself — including how the agents are orchestrated. A schematic of today's graph describes a system that will not exist next month.
A frozen diagram of a moving system lies
If we published an architecture diagram, we would be making an implicit promise that the diagram is true. It would not stay true. We would either have to freeze the system to match the documentation — which defeats the point — or knowingly publish something stale. Neither is honest, so we publish neither.
How can opacity be compatible with transparency?
Because transparency about outcomes and opacity about mechanism operate on different layers, and clients only need the first to hold us accountable. You do not need to see the graph to verify that the engine is doing its job — you need to see every change it made, why, the measured effect, and a one-step path to undo it. We provide all of that.
- Every change is logged, dated, and attributable — you can audit the full history.
- Every change is reversible in one step — accountability does not require a schematic, it requires an undo button.
- Results are measured on a traffic slice before rollout — you see the evidence, not just the claim.
- You can leave at any time and keep every change already shipped — no lock-in to the black box.
That is the deal: maximum transparency about what happens to your site, and a closed box around the mechanism that makes it happen. We think that is the right trade — and the same trade you make with every expert you hire. If you want to see the outcomes side of it in action, [book a discovery](/contact.html) and we will run the engine on your site, logs and all.