Count the agents that can write, not the ones that exist

Databricks documents four agent system design patterns as a continuum: a standalone model and prompt, a deterministic chain with hard-coded steps, a single-agent system that decides its own tool calls, and a multi-agent system with a supervisor routing between specialists.

It is a good page, and it does not do the thing I expected. It does not sell the far end. It says:

When building any AI-powered application, start simple. Introduce more complex agentic behaviors when you truly need them.

It also names the costs plainly: routing strategy, logging and tracing overhead across multiple endpoints, and agents that "can bounce tasks indefinitely among themselves without resolution if not carefully constrained".

My build does not sit anywhere on that line, and working out why took me longer than it should have.

Fifteen investigated, one wrote

Building the price index, agents were used heavily and in two completely different modes.

Investigation was delegated wide. Fifteen written reports across thirteen domains: a framework review against its own best practices, a performance report, an animation pass, an end-to-end audit, a design-engineering audit, a search and answer-engine review, a deploy report, a prerendering finding, three separate reports on crawler data quality, and two production-readiness audits.

Implementation was single-threaded. One agent, one working tree, one commit at a time.

Count the agents and this is a multi-agent system. Watch which of them could modify a file and it is a single-agent system. Databricks' continuum has one slot for it and the slot is wrong either way.

The axis that actually matters

The continuum orders systems by how much decision-making the runtime delegates. For a system whose output is an answer, that is the right axis: a supervisor routing a question to a specialist is the whole architecture.

For a system whose output is a repository, it is not. The question that predicts pain is narrower:

How many agents can write to the same place at the same time?

Reads parallelise for free. Fifteen agents can read the same codebase simultaneously and the only cost is tokens. Nothing they do can conflict, because reading does not produce a state that another reader has to reconcile.

Writes do not parallelise at all, and the cost is not a merge conflict. Git will resolve most of those. The cost is a diff nobody can review, because no single person or agent holds the reason each hunk is there. A reviewable change is one where a reader can reconstruct the intent, and intent survives exactly one author.

What that buys, in the same terms Databricks uses

Their listed cost of multi-agent is the overhead of logging, tracing and debugging across endpoints. Splitting on the write boundary pays that differently.

• The trace is a file, not a span. Fifteen investigations produced fifteen documents. They are greppable a month later, they carry a verdict per rule, and reading one does not require a tracing backend to still be running.
• The bouncing problem disappears. Agents cannot pass a task back and forth indefinitely if only one of them can act on the result. The others produce findings, and a finding that nobody acts on is a document, not a loop.
• Routing is not a strategy, it is a list. Thirteen domains, each investigated once, each report read before implementation. There is no supervisor because there is nothing to arbitrate.

And the honest cost, which is real: it is slower. Fifteen investigations feeding one writer is a queue with a single server, and the writer is the bottleneck by construction. I would make the same trade again, but I would not pretend the trade is free.

Where the continuum is right and I am not

Two limits on all of this.

The write boundary is the right axis for producing artefacts. It is not the right axis for serving requests. If the output is an answer to a user rather than a commit, Databricks' ordering describes the real design space and mine describes nothing.

And "start simple" is the strongest sentence on their page. It is also the one every catalogue of patterns is read against, since a reader who has just learned four patterns is not usually looking for permission to use the first one. Their placing it at the top is the part I would copy.

Next

This is the last of the five sources in this series. The pattern across all of them is the same: each is careful, each is defensible, and each is written from the layer where the author works. PostHog writes from the product surface, Datadog from the platform, the manifesto from the process, Databricks from the runtime. None of them is wrong within its layer, and none of them can see the failure that lives in another one.

The one I would defend hardest is the split between reading and writing, because it is the only claim here that a build survives or does not. The post arguing against the manifesto's first value and the one about evidence that lies both come out of the same three days, and both would have been different if more than one agent had held the pen.

If you take a rule from this: count the agents that can write, not the agents that exist. If that number is above one, work out who reconstructs intent when the diff is wrong, and whether that person is you at two in the morning.