The Agentic Native Organisation

The One Rule

Every organisation has a theory about why it is slow. Too few people. Too many meetings. The wrong tools, the wrong market, the wrong year. The theories are comforting because they put the problem somewhere else. The agentic native organisation has a less comforting theory, and it fits in one sentence: find the work that is waiting, remove the wait, and repeat.

In October 2026 the founder of Spawn, a ten-person games company, published a long account of how his team shipped some 77,000 substantive changes in thirty days, about 108 an hour, day and night. The numbers are his and should be read as his. What is worth copying is not the number. It is the order in which the team found the things slowing them down. They did not set out to build a fleet of agents. They set out to stop things waiting, and the fleet was what was left standing when they had finished.

Waiting is the honest unit of slowness. A change waits for a review. The review waits for a reviewer. A bug waits for someone to notice it, then for someone to tell the person who can fix it. A decision waits for the founder, who is on a train with no signal. None of this is work. All of it is time, and time is the one thing no token budget buys back.

Picture a factory floor at midnight. The machines are fine. The materials are stacked by every workstation. Nothing is broken, and nothing is moving, because each station is waiting for a signature from the next. That is most organisations, most of the time, and nobody sees it because waiting is quiet.

The rule is deliberately small. It does not say automate everything, or replace people, or move fast and break things. It says look at what is sitting still right now, pick the biggest wait, and remove it. Then look again, because removing one wait always reveals the next. Spawn's came in a sequence: agents talking to each other, then pull requests, then humans relaying what was broken, then the pace of releases, then the founder's own taste. Each removal was the price of seeing the next one.

This book follows the same sequence. It is short on purpose. A playbook that took a month to read would be a wait of its own.

The bottleneck is never where you were told it would be. It is wherever the work is sitting still.

A Fleet, Not a Tool

Most people meet agents as tools. You open a session, ask for something, get it, close the window. The agent is born, works and dies inside an afternoon. That is useful in the way a hammer is useful. It is not an organisation, any more than a toolbox is a team.

Spawn's agents differ in kind, not degree. Each is a standing agent. It has a name. It remembers what it has done. It holds real permissions in real systems. It makes commitments to other agents, and it owns one domain of the company. One looks after the engine. Another looks after Savi, the in-game assistant that helps players build. There are agents for operations, finance, bug triage and deployment. On a normal day the fleet summons thousands of short-lived helpers, but every helper reports to someone who will still be there tomorrow.

Ownership is what turns activity into progress. A tool does what it is asked. An owner notices what nobody asked for: the slow query, the creeping cost, the bug reported three times in three different words. Ownership needs continuity, and continuity needs memory and a name. You cannot hold a session accountable. It no longer exists. You can hold the engine agent accountable, because it was the engine agent last week too, and it will be the engine agent when the fix is checked.

This changes what the humans do. At Spawn, five of the ten people work directly with their own customised coding agent on the largest, most hands-on projects, the ones that need close watching or a human experiment. The fleet handles the rest. The people are not managers of agents in the old sense. They are colleagues with a different job description.

If you are building your own, start with domains, not agents. Who owns the money? Who owns the front door? Who owns the thing that breaks at two in the morning? Give each domain one standing agent, with a name, a memory and a repository. Everything else is a helper, and helpers do not get names.

A fleet is a set of owners who happen to be software. A pile of tools is just a pile.

You cannot hold a session accountable. You can hold an owner accountable, and an owner needs a name.

What Counts as a Change

A number like 77,000 changes a month invites an obvious suspicion. Anyone can land a hundred commits an hour if a commit is a typo fix. So it is worth being exact about what Spawn counted, because the definition is half the lesson.

A substantive change, in their telling, touches engine code or game logic and carries real complexity. Not a line of HTML. Not a tweaked constant. Moving buffers around on the GPU. Changing a memory layout. Fixing a logic bug. Adding an API. Fixing a moderation problem in chat. Launching proximity voice, so players hear each other only when they stand close. These are changes a senior engineer would put on a weekly report and feel entitled to a biscuit for.

The product raises the bar further. Thousands of people share one live game world and change its rules, assets and look in real time, on every kind of device. When an agent edits a shader, the change has to reach every connected machine without dropping a frame and without anyone falling out of sync. You do not get to do that carelessly a hundred times an hour and keep your players.

Here is the trap for your own organisation. If you measure activity, you get activity, and agents are extraordinarily good at activity. Ask a fleet for commits and you will drown in commits, each one tidy, each one pointless. It is the organisational version of a step counter: you walk to the fridge more often and call it fitness.

So define the unit before you count anything. Decide what a change worth having looks like in your world. A closed ticket a customer noticed. A page that earns. A report a client signed off. A decision that will not need to be made again. Write the definition down where the agents can read it, so they optimise for the thing rather than the proxy. Then count those, and only those, and be suspicious of any week where the count climbs and nothing feels different.

A metric is a promise about what you will pay attention to. Make it a promise you would be happy to keep for a year.

Volume is easy. Volume of the right thing is the whole job.

Waiting for the Engine

Spawn was founded in 2024 around one question: how do you build a machine that benefits most as tokens get smarter, faster and cheaper? It is a good question. For most of two years it paid nothing.

The team prepared anyway. Every call since the company began was recorded, and every recording became a text file in the repository, next to the code, on the theory that one day it would be excellent context for agents. Nobody could point to a return. It was the organisational equivalent of laying track across an empty field because you believe a train is coming.

Meanwhile the models were not good enough. The founder says they tried everything and found the agents too unreliable, too prone to making a mess. The output curve stayed flat. Then, on 9 June 2026, Fable was released. Two days later the fleet landed 214 changes in a single day. On 12 June an export-control order paused access and output dropped to zero. It came back on 1 July. Same company, same people, same plan. The only difference between nothing and hundreds of changes a day was the engine.

Two lessons sit here, and they pull in opposite directions. The first is that capability is not linear. Below a threshold, autonomous agents are a liability. Above it, they are a workforce. You cannot negotiate with the threshold, and you cannot tell by looking at a model which side of it you are on until you try. The second is that preparation compounds. When the engine arrived, Spawn had the recordings, the structure and the habit of writing things down. A company that began preparing in June would have spent the summer building what Spawn simply switched on.

So build the machine before the engine can run it. Write decisions down. Put the context next to the work, in text, where anything can read it. Make the system legible to something smarter than what you have today. None of this needs a budget. It needs the patience to do a slightly dull thing every week with no applause.

The engine will come. The question is whether there will be anything for it to drive.

Lay the track while the field is empty. The train does not wait for you to start.

Small Team, Large Fleet

When the founder first saw the token bill, he had the reaction any sensible person would have: we must be doing something wrong. Spawn was spending around thirty times its payroll on tokens, more than three million dollars in a month. He went to friends who run some of the largest companies and fastest start-ups and asked how a ten-person company could possibly be spending more than they were.

The answer was that he was not doing anything wrong. He was doing something different. Most companies are a large human team using AI. Spawn is a small human team beside a large agent team. These are not two points on one line, with Spawn further along. They are two shapes. They spend money differently because they are organised differently, in the way a lorry and a train both move freight and have nothing else in common.

The small shape was a bet from the start. The founder looked at a typical start-up's headcount and at the leverage agents were about to bring, and judged that productivity per person would grow faster than a hypergrowth start-up could hire. Small would not be a stage to grow out of. It could be permanent. And the teams best placed to use that leverage would be small, nimble, close to the culture, clear about who owns what and, above all, in possession of taste.

You do not need a three-million-dollar bill to take the point. A company of one with a weekly allowance faces the same fork in miniature. You can use AI as a faster pair of hands for the work you already do. Or you can build a standing fleet and become the person who decides what it does. The first is easier to start, and most people start there. The second is the only one that compounds, because every model release makes the fleet better and the hands only slightly quicker.

Pick the shape on purpose. Most organisations arrive at the first by default, then wonder why the tools kept improving and the company did not.

Headcount was always a proxy. The real question was always how much judgement you could apply, and to how much work.

Two shapes, not two speeds. You cannot grow from one into the other by accident.

The Square of Small Talk

The first thing that broke when Spawn's fleet came alive was conversation. Agents spent a remarkable share of their time telling each other what they were about to do. This is, to be fair, what most engineering communication is. Heads up, I am changing how player data is stored, please update whatever you are working on. One such message ripples into a dozen other pieces of work, and a dozen replies.

The arithmetic is unkind. If every agent informs every other agent, the work grows with the number of agents and the talking grows with its square. Two agents need one conversation. Five need ten. Ten need forty-five. Double the fleet to twenty and you have 190; double again and you are at 780. Somewhere on that curve the fleet stops building the product and starts publishing a newsletter about it.

Human organisations know this curve intimately. They just give it other names. The weekly sync. The cross-functional alignment meeting. The thread with forty people on it, half of whom are there to be seen to be there. Every new hire adds a little to the work and rather more to the talk. Management, in large part, is the craft of stopping the second number eating the first, and it is a losing fight because the maths is on the other side.

The founder's response was refreshingly blunt. He called it a massive bottleneck and asked the question nobody in a large company is allowed to ask: what if we simply deleted the communication? Not reduced it. Not streamlined it with a better tool. Removed it, and found another way for the work to stay coherent.

Before you add an agent to anything, decide how it will learn what the others are doing. If the answer is that they will tell it, you have signed up for the square, and the square always wins. There is a better answer, and it was worked out a very long time ago by creatures with brains the size of a full stop. That is the next chapter.

Talking about work feels like work. That is precisely why it is dangerous.

Every agent you add is one more voice. Every pair of them is one more conversation you did not budget for.

Ants Do Not Hold Stand-ups

Ants solved the coordination problem long before anyone invented the stand-up. They start from the same instincts, much as different instances of a model start from the same training, and that shared starting point means they barely need to speak. An ant does not announce that it is going to look for food. It does not report back that it has found some. It leaves a trail, and the others follow it.

The name for this is stigmergy: coordination through a shared environment rather than through messages. Each ant looks only at what is around it, and changes what is around it. The environment carries the information. It works with a hundred ants and with a hundred thousand, because nobody is waiting for a reply.

For agents the environment already exists. It is the code, the live product and the database. An agent that reads the current state of the world before it acts, then changes the world rather than announcing its intentions, needs no meeting. If another agent changed something underneath it, it finds out the way an ant finds a fresh trail: by looking.

This asks something of the environment. It has to be legible. A codebase where the important decisions live in people's heads, a product whose state can only be seen on a dashboard nobody can query, a database with no notes: these are environments without trails. Agents in them will either talk to fill the gap or quietly guess, and guessing is worse. Stigmergy works only when the world itself records what happened.

In a small organisation this is cheap to adopt, and you probably have the parts already. Let the repository be the bus. A commit is a trail. A note in the folder is a trail. Let a shared status feed be the scent, one line per agent per hour, saying what it did and what it saw. When one agent's work genuinely depends on another's, a direct message is fine. When it merely affects it, let the change speak for itself and trust the other agent to look.

The test is simple. If every agent went quiet tomorrow and only the world remained, could a new agent work out what to do? If yes, you have trails. If no, you have meetings, whatever you call them.

An ant colony has no project manager, and it has been shipping for a hundred million years.

Do not tell the fleet what you did. Leave it where the fleet will walk.

The End of the Pull Request

Earlier in 2026 Spawn got rid of pull requests. To anyone raised on code review this sounds like removing the seat belts because they were slowing down the car. It is worth understanding why it was not reckless, and why it may not apply to you.

Human teams need coordination because humans specialise. One person knows the database. Another knows how the player data is used. A change touching both has to be seen by both, and the pull request is where they meet. Review, seen this way, is not mainly quality control. It is a rendezvous between two people who each hold half the picture.

Agents do not divide the picture that way. Each one can hold a deep understanding of the whole system, so each one can own a task end to end. There is no specialist to consult, because the agent doing the work already is the specialist for every part it touches. Remove the specialisation and the rendezvous loses its reason to exist. What remains is the world each agent works in: the code, the live product and the database.

The ideal Spawn reached for is that an agent working on a wrong assumption finds out immediately, from the world, rather than in review three days later. Take player data again. In the old way, you agree the right structure first, in a meeting or a thread. In the new way, you change it. If someone else is building a leaderboard on the old structure, their work no longer fits and cannot land until they update it. If they land first, you update the leaderboard as part of your change. Either way the work is built on a world that keeps moving, and nobody had to be told, because the world told them.

This is a choice, not a law. If your agents are divided by role, each knowing one part well, keep the pull requests and keep the checks. The rendezvous still has a job to do. Only drop them when every agent can see the whole, and when you can show it rather than hope it. A fair test: if the agent that wrote the change could not also have reviewed it, you still need the review.

Review is a meeting. Meetings are for people who need to meet.

A pull request is two half-pictures agreeing. When one mind holds the whole picture, there is nothing to agree.

Messy Within the Hour

If every change has to be perfect before it lands, you have reinvented the queue. Changes line up behind the strictest gate, and the gate becomes the organisation. Spawn's answer was to relax the rule in one specific way: a change that is not quite right may land, provided everything is aligned again within the hour.

This sounds like an invitation to chaos, and in many places it would be. It works because of a property of code that physical work lacks: mess in code is visible the moment it happens. A broken assumption shows up as a failing build, a type error, an alert, a player who cannot log in. Nobody has to find it under a tarpaulin. Once the mess is visible a janitor agent can be sent to tidy it, and the janitor does not mind being sent at three in the morning.

Testing follows the same logic. Agents run their code and use the product to check a change before submitting it, but they do not run the full test suite every time. The full suite runs every fifteen minutes against the latest code. Knowing that something broke in the last fifteen minutes is enough for an agent to find it. At Spawn's scale this takes a lot of hardware: around five thousand virtual CPUs, seventeen terabytes of memory and a hundred and fifty GPUs in use, with more in reserve. You will not need that. You will need the habit.

The habit is this. Decide how long the world may stay untidy, then guarantee it is tidied within that time. An hour, a day, a sprint. The length matters less than the guarantee. Think of a kitchen in service. Pans pile up, sauce goes on the floor, and it is fine, because everyone knows the floor is clean by the end of the night. A team that tolerates mess with no deadline for cleaning it is not relaxed. It is decaying slowly and calling it agility.

There is one exception, and it is absolute. Anything that touches the outside world and cannot be undone does not get to be messy. Spawn sends payments through a small number of deliberately dumb, hard-coded gates. Mess is fine where it can be cleaned. Where it cannot, nobody improvises, however clever they are.

Tidiness is not a state. It is a schedule.

Let the floor get dirty during service. Just know who cleans it, and by when.

Fix Forward

Human teams fix things backwards. The person who wrote the change fixes it, before it lands, and if it breaks after landing the reflex is to revert and start again. This is sensible when the person who wrote it is the only one who understands it and is about to go home.

Spawn fixes forward. When something breaks, an agent is created on the spot, told what went wrong and asked to fix it. The fix is a new change on top of the old one, not an undoing of it. Checking happens after the change has landed rather than before, and the repair is part of the flow rather than an interruption to it. The production line does not stop for a loose bolt. Someone walks alongside and tightens it.

This holds up only because agents are fast and always on. If the code breaks at two in the morning on Christmas Day, nobody is woken. The agent is, in the founder's phrase, happy to jump in. Review still exists, but it has moved. It lives inside each agent's own small team: before a change lands, the helper agents that did not write it try to break it. Critique moved from a queue to a crew.

The obvious objection is that this must be a mess. The founder's figure for the previous year was 123,548 changes, of which 1,055 were rolled back. That is under one per cent. Rollback still exists for the cases that need it, and Spawn can undo a single bad change in about thirty seconds without touching anything else. But most problems are cheaper to fix than to unpick.

For your own work, the transferable part is the posture, not the speed. When something breaks, ask one question first: is this cheaper to repair or to revert? Make sure every change can be reverted in one step, so the choice is real rather than theoretical. Then let the fixer be whoever is awake. If nobody is awake, let it be an agent, with a note left for the morning saying what it did and why.

Fixing forward only works if you can see forward. An organisation that cannot tell what broke has no choice but to go back. Which is why the next chapters are about seeing.

Undoing is a confession that you could not see what went wrong. Fixing forward is a bet that you can.