The Agentic Native Organisation

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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 .

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.

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.

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.

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.

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.

With the talking removed, the next wait Spawn found was people. The agents were waiting for humans to tell them what was broken in production.

The founder's view is that this loop is both messy and slow, so he did the opposite. Spawn's agents edit the live code directly and ship to production every hour, so every error, every bug report and every metric is something they read for themselves. Roughly sixty per cent of the fleet's work begins from one of four places: a production error, a bug report filed by Savi, an anomaly in the logs, or a feature request. None of them needs a human to carry it across the room.

You may not want your agents anywhere near production. For client work you almost certainly should not, and the later chapters say so. But you can still close the gap between a change and its consequence. Give agents read access to the logs, the costs, the usage and the issue tracker, even where their write access stops at a draft. Half the value of a closed loop is the agent seeing that its last idea did nothing.

An agent that cannot see the world is not autonomous. It is just unsupervised.

Savi, the assistant inside Spawn that helps people make games, files bugs herself. When a user runs into a problem, or when Savi hits one while working in the product, a report is written. Nobody has to notice, take a screenshot, find the right channel and explain it twice to someone who was not there.

The same path carries everything: engine bugs, trouble talking to Savi, problems on a user's own computer, a confusing screen. So the capacity to fix things grows with the number of users rather than with the number of support staff. More people find more problems. More problems get fixed. No ticket queue swells in between, quietly ageing.

If you build only one loop, build this one. Let reports come in through the product itself, not through a form on another page. Let a triage agent sort them into fix, leave and ask, and make it write down which bucket and why. Then measure one number: the time from report to reply. Not to fix, to reply, because a reply within the hour that says we see it and here is what we are doing is most of what a customer wanted. That number is the customer's whole experience of your organisation, and most companies never look at it.

For the rest of the loop, Spawn uses a phrase the founder calls hyper observability. Everything they build must be traceable step by step, in text, by an agent, and replayable afterwards. The product is built to be run and watched by agents, not merely used by people.

The principle underneath is simple to state and annoying to implement: anything an agent cannot read is a wait . If the only way to know whether something worked is to look at a dashboard, take a screenshot and squint, you have built a system that needs a human to relay its state. If the state is written down, in text, in order, an agent can follow the thread from symptom to cause on its own, at three in the morning, without asking.

This changes how you build. Every job can be replayed. Every decision an agent makes is recorded with its reason. It is extra work at first, in the way that writing things down is extra work at first, and it pays back the same way: the next reader does not need to ask you.

If you have to tell the machine what happened, the machine was not watching.

Spawn's agents watch more than the product. They watch every input to the company, including what it spends with Anthropic, with AWS and everywhere else. This sounds like accounting. It turned out to be security.

Every transaction notifies an agent and is reviewed as it happens. The books are reconciled hourly or daily. When someone mentions the company on social media, they know within five seconds. None of this is glamorous. All of it is the error loop again, applied to money and reputation: if something matters, give an agent a sensor on it.

For a smaller organisation this may be the easiest loop to close and the most valuable. Costs already arrive as data. A ledger of what each service costs, a budget for each, and an agent that compares the two every morning will catch the forgotten instance, the runaway job and the leaked key long before an invoice does. It will also tell you, quite unsentimentally, which projects cost more than they earn, which is a conversation most founders put off until the accountant forces it.

What you do not measure, you discover on a statement.

A loop this tight only works if it keeps turning, so Spawn treats an hour without a release as a SEV-0 , its most serious class of incident. Not a broken feature. An hour of silence. Unshipped changes pile up. Problems already in production last longer. Feedback slows. And there is a quieter reason: an agent can hold only a few hours of work in mind at once, so shipping more often than that helps it stay coherent.

Recovery is built in. A bad change can be rolled back in about thirty seconds, and only that change. An alert from a monitor or a log wakes the agent that owns the incident. The team breaks things on purpose to check the recovery paths still work.

Your rule need not be hourly. For a one-person operation, a weekday on which nothing lands might be the right alarm. For client delivery it might be a Friday status note that never slips. The cadence is yours to pick. The discipline is not optional: pick it, call missing it an incident, and mean it, including when you are the reason it was missed.

By October the only thing still waiting at Spawn was taste, and most of it was the founder's. Should we build this feature? Add this setting? Introduce a new API? Delete a thing or make a new one? Close a door or open one? One morning he woke to seven hundred such questions waiting for him. The agents were finding questions faster than he could answer them.

The uncomfortable discovery was that most of the seven hundred were not new. He had answered them already, in one form or another. Too complex. That trade-off is fine. It still does not feel right. He was saying the same things over and over to an audience that did not remember, like a lighthouse keeper explaining the rocks to every ship individually.

The first step is to notice. For one week, count the questions that reach you and mark each one as new or repeat . Be honest about repeats: a question you answered for a different person on a different project still counts. If more than half are repeats, you are not making decisions. You are reciting them, slowly, to one listener at a time, and your organisation is paying for the performance.

The founder's job is to decide things once. Deciding them weekly is a hobby.

Every conversation Spawn had held for two years was sitting in the repository as text. The habit that had looked slightly eccentric in 2024 now paid out. The team distilled two years of decisions into per-person taste principles and built AI judges to apply them.

The first rulings came out on 6 October. In the following eight days the judges returned more than eleven thousand rulings; the founder answered twenty-seven himself. The queue no longer stops anything. When a judge gets something wrong, someone says so, and the judge reads the correction next time. The week before the judges launched, the fleet landed about a thousand changes a day. On 10 October it landed 7,250.

You can start this on Monday with one text file. One line per rule, each with a link to where you decided it, in the plainest words you can manage. When a question arrives, check the file before you answer. If you answer something new, add a line. Within a month you have a rulebook. Within a quarter, an agent can read it for you, and you can go back to answering only the questions that have never been asked before.

So what do the humans do? At Spawn the work has changed completely. A year ago each engineer owned a system and knew it deeply. Now they are closer to paratroopers: they drop in wherever they are needed, get up to speed fast and find a way to unblock the agents. Wherever they land, there are two new jobs. The first is taste .

Taste also means saying no to Claude when the thing works. The founder shared some recent instructions. Never use CPU rasterisation; if that code path exists, delete it. No stand-ins for distant players: if you can render them, render them, and if you cannot, do not. This broke chat, please roll it back. I know you can do better; do you think this will make people happy? And one default, which made Savi think longer before every reply, went live at 10.22 one evening and was rolled back at 10.40 because it was too slow and had no jazz. A release that lived eighteen minutes, killed by the word jazz. Nothing in a test suite checks for jazz. Only a person does.

For your own organisation, make taste a scheduled activity rather than an accident. Use your own product every day as a customer would. Write every no down in a sentence, with the reason. Every no is a rule waiting to be recorded, and once recorded, the judge can say it for you next time, in your voice.

The second human job the founder calls entropy : asking the model for things it would not think of on its own. Ambition is one kind of entropy. Creative randomness is another.

Models will not ask for a hundred times by themselves, so people do. Some of Spawn's prompts read like provocations. Imagine if the world could truly be infinite. How do we make a world a thousand times the size of a famous open-world game load on a phone in under a second? The second one led to Spawn 6, the version that went viral.

The two per cent trap is comfortable because every step is defensible. The hundred times ask is uncomfortable because it might fail loudly. That discomfort is what the humans are now for.

Increments are what happens when nobody asks for more.

Every generation of models arrives with a gift and a bill. The gift is obvious: things that did not work now work. The bill is quieter: everything you built to help the previous model cope is now in the way.

Spawn's founder treats deletion as a first-class part of taste. The engine's server-side simulation, roughly seventy per cent of it, went because nobody could name a real reason to keep it. When Fable 5.1 replaced Fable, most of the problems the team had fought through the middle of the year simply vanished, and so did the need for the workarounds. He expects models to start doing this pruning themselves soon. For now it is a human job, and an unpopular one, because it means throwing away work that cost real effort and still works.

Keep a record of why each piece of scaffolding existed, so the question has an answer to check against. A one-line note at the top of the file is enough. When the reason stops being true, the file can go.

The hardest code to delete is the code that still works. Delete it anyway.

Everything so far has been someone else's company. This part is about yours, and it starts with an audit that takes an afternoon and no software.

Then rank. Age matters, because old waits rot: the person who asked has moved on, the context has gone cold, the fix will cost more. Blast radius matters, because some waits hold up ten other things. Multiply the two, roughly, and the top of the list is the wait to remove this week. Only that one. Removing a wait almost always reveals the next, and if you try to remove five at once you will remove none of them properly.

Rerun the audit every week, on the same day, and keep the old ones in a folder. Over a quarter they become a record of how your organisation changed shape, which is far more honest than a strategy document, because a strategy says what you meant to do and the audits say what actually sat still.

Spawn's risk appetite is not yours, and should not be. It makes a game. A broken shader for four minutes is an annoyance. Most organisations run things where four minutes of broken is a contract dispute, a refund or a regulator. The lesson to copy is not the appetite. It is the way they sort work by whether it can be undone.

Think of the doors in a hospital. Most open to anyone. Some need a badge. One or two need two people and a key, and nobody finds that insulting, because everyone knows what is behind them.

The Gate tier deserves its dumbness. It should not be a judge or a clever policy. It should be a hard stop that a tired human cannot talk themselves past and a confident agent cannot reason its way around. Spawn routes payments through gates like this, and it is the most agent-forward company its founder knows of. If they still have dumb gates on money, so do you.

Trust is not a feeling. It is a list of what you are allowed to do without asking.

The method works anywhere. The autonomy does not. The distinction matters most when the work belongs to someone else.

On a client engagement the playbook becomes a delivery method rather than an operating model. The waits audit is still the best status report you will ever write: what is waiting on whom, and since when, is exactly what a client sponsor wants to know on a Friday, and almost never gets. Reading the client's own trackers and repositories directly, rather than waiting to be told, is still a closed loop. But anything inside the client's systems sits in the Gate tier. Their data stays in their tenant. Their rules live in their project, not mixed into yours. Nothing reaches them without your say-so. You are a guest in someone else's house, and guests do not rearrange the furniture at night, however sure they are it would look better.

Be honest about the source whenever you use it. A story is persuasive. A story presented as a benchmark is a liability, and a client who later learns the figures were one founder's own account will not thank you for the enthusiasm.

The moment the fleet idea lands, everyone wants a new agent. A sales agent, a content agent, an agent for that thing we discussed on Tuesday. Most of these should not exist, and the fit test is how you tell.

When something passes, spawn it properly. One name and one domain. A private repository with a short set of house rules, a backlog with one halo project, and a decision log stating its tier of trust. A project with a goal written as a sentence with dates in it, and instructions that say what it must never do. A master skill that routes to the skills you already have rather than copying them. And a line in every register you keep: the roster, the status feed, the cost ledger. If it is not in the registers, it does not exist, however busy it looks.

The cost of a new agent is not its tokens. It is the attention it will claim from you, every day, for as long as it exists. A fleet of thirty agents you cannot name is not a fleet. It is a crowd, and you are back to the square.

The founder of Spawn thinks large companies will find all this hard to adopt, and his reason is not technical. None of it works unless the loop is closed, and closing the loop takes an appetite for risk: you have to be willing to let agents break production. His argument is that humans break production all the time, that change is the leading cause of failure and that people make the changes. In his experience agents break things less often, and when they do they usually notice and fix it quickly, provided the loop is closed.

Then there is compounding. Every new model makes a well-structured organisation faster and more coherent. The problems of the middle of the year mostly disappeared with the next release. If the structure is right, each model makes the whole company noticeably stronger, and that lead is very hard to catch.

None of this is a technology decision. A fleet is a way of organising, and organising is a choice you can make on a Monday with a text file. Run the audit. Remove one wait. Come back next week.