An AI System Grows Upward, Not Sideways

More agents, more workflows, more automation. For a while that holds. Then comes the point where more of everything stops making anything better.

Our next jump didn't come from more. It came from a layer above.

Sideways Was Already Done#

The fleet had been running long before this rebuild. Orchestrators drove it: jobs on a schedule, pipelines in TypeScript, small models doing triage, sorting mail, bundling reports. One generation had a conductor, querying a handful of specialists, each wired to exactly one tool and nothing else. None of that was a stopgap. It ran cheap, reliable and unglamorous, every night, and most of it still runs today.

That build had a deliberate limit. The workers took in text and handed back text, which is exactly right for sorting, bundling and reporting. Real interventions, changing code, measuring something, checking a claim, needed a sequence that anticipated every step. We built that too. A system in that shape just doesn't grow further, it only gets fuller. Every new capability is another workflow, and every workflow is another place someone has to update when something changes.

Then the Tooling Made a Jump#

The agents reporting to a project can now act on their own: open a file and change it, drive a browser, run a test and read what it prints. They connect to services and data sources through MCP, an open standard that lets a program plug into outside tools, and they start each task already holding a relevant slice of what the system remembers. All of that runs inside Claude Code.

A small setup absorbs a jump like that by swapping a few scripts. A system with a running fleet uses it differently: it grows upward.

Managing Became Assigning#

Once the workers could act on their own, planning every move for them was wasting capability. Dictate the path and you get exactly the path you thought up in advance, never the better one the agent would have found on site. What an orchestrator did was plan a sequence; what a supervisor does is hand out an assignment. Not the same job.

Set side by side, the shift is easy to see:

The price is care at a new point in the process. A badly written assignment is worse than a badly planned sequence, because nobody stands in between anymore to fill the gap in passing.

What Goes Into an Assignment#

An assignment is not a sentence. It's a package, and anything meant to be binding for the execution has to be written into it.

It states the goal and, just as explicitly, the non-goals. Scope is what's written down, not what would be complete. It states the decisions already settled, so the agent neither relitigates them nor invents replacements. It states which files belong to it, and in parallel work no two agents ever own the same ones, each in its own working copy where that risk is real. It states the tools it may use, because anything not explicitly allowed counts as not allowed, which matters most for anything that costs money or reaches the outside world.

Then comes the part that decides, later, whether the assignment was any good. Acceptance criteria are written so they can be recalculated: this is done when this command shows this result, not when it looks about right. The required checks are named, along with the duty to quote their output in the report. The stop conditions say when the agent halts and asks instead of guessing, on missing data, on a conflict with the scope, on a rule standing in the way. And at the end sit the hard limits, the things that never happen under any circumstances, however sensible they look to the agent in the moment.

Whatever the client hasn't decided gets settled before the assignment goes out. Not guessed at halfway through, and not passed down the chain as "abort if you find reasons against it". That rule came out of practice, not out of a manual. It's the most uncomfortable one, because it forces the supervisor to finish thinking before delegating.

Everything That Applies Has to Travel With the Assignment#

A subordinate agent doesn't start with the project's knowledge in its head. It doesn't know the house rules that the main session takes for granted. Miss that, and you're delegating to someone who knows none of the standing conventions, then wondering about the result.

So we separate two things: context may come from the system's memory, knowledge, prior work, connections. Whatever is meant to be binding is written in the assignment, or it doesn't apply. It's tedious and it feels like bureaucracy the first time. It's also the difference between a team you lead and a series of coincidences.

Checked Against Evidence, Not Self-Report#

Whether something is actually done gets checked against evidence: the real diff, tests that were run, screenshots that were looked at. Not a summary from the agent that built it. A report saying everything is green is a claim about a check, not the check.

So whoever reviews gets the assignment and the result, nothing else. No self-assessment from the builder, no "I deliberately chose this here". Praise in the preamble creates exactly the expectation a reviewer shouldn't have, and then they see what they expect. Internally, that's a blind review.

What comes out of that separation is unspectacular and valuable for exactly that reason: a report gets read, the claimed changes get looked at, the checks get run again independently. Only then does the result get passed on.

When One Project Wakes Another#

The real leverage sits one level up. A supervisor can do more than assign work inside its own session: it can start a full session in another project, one that finds everything belonging to that project already in place, its rules, its safeguards, its tools, its memory.

That changes the division of labour. The supervisor no longer needs to know the other project in detail. It writes down what has to happen and what applies, wakes the session that lives there, and checks what comes back. Domain knowledge stays where it belongs, and so does oversight.

An assignment like that always carries the same limits: the smallest possible change, publish nothing, ship nothing, checks as proof, one clean summary of the change, a report as a file rather than a verbal all-clear. What ships is decided by a person, every time.

Every Project Runs Its Own Team#

Building, checking, writing, researching, keeping things locked down: these are roles, not job titles tied to one person or one model, and every project draws whatever it actually needs from that set. The payoff shows up when something changes. A role gets sharpened in one place and improves everywhere, instead of being reinvented per project.

Above that we built one more layer, one that doesn't build anything itself but watches the system and measures it: what's growing, what's drifting apart, where a rule claims something that stopped being true. It had to earn that position. For now it only observes and reports; more automation comes step by step. That, too, is growth upward rather than sideways.

No Conductor Over the Conductors#

What we deliberately didn't build is a central router that takes every assignment across every project and decides who does it. That would have been the obvious crowning piece, and the point where the whole thing tips over.

Each project keeps authority over its own work. The layer above watches; it doesn't dispatch. A project that no longer decides what happens to its own assignments has stopped being the one in charge of them. And responsibility nobody can point at has never been progress, only one more layer.