Build Your Company as a Federation of Amoebas
A department is a context-bounded token partition, a company is a federation of amoebas, and every rule is inherited from software engineering.
The AI-Native Organization, Part 2: Organizations and scale.

Build Your Company as a Federation of Amoebas
In the last article, I laid down two axioms: AI is stateless, and its context window is finite. It is like a genius with amnesia—every fact, rule, and piece of tacit understanding must be written down and fed to it, and fed again every single time.
From these two axioms, a chain of consequences unfolds. The classic "communication funnel" loses its safety net in human-AI collaboration. Everyone's job shifts from executor to communicator. The smallest atomic unit of an organization becomes "one person plus their agents," which means the diseases of large corporations break out in five-person teams. The cure, also given in Part 1: trace disagreements back up to mission, vision, and values, write a constitution, ground it in a single source of truth (SSOT), and let an agent-to-agent (a2a) infrastructure make alignment happen automatically every day.
This article pulls the camera further back: when the scale grows from a small team to departments, companies, hundreds or thousands of people, what does this same logic rewrite the organization itself into?
The physics of scale: entropy, waterlines, and review bandwidth
In any organization that keeps iterating, the amount of information only ever increases: more people, longer history, faster iteration means more documents, decisions, emails, and chat records. This ever-growing pile of disordered information is what software engineering, borrowing from thermodynamics, calls entropy.
In The Manifesto, Chapter 12 "Token as a Quantitative Measure of Project Scale", I wrote that a project's complexity can be measured by the total number of tokens it contains. Applied to an organization, that measure becomes a hard constraint—because an AI's context window is finite, while the information a mid-sized business accumulates over the years easily runs into millions or tens of millions of tokens. No single AI can hold an entire company.
This yields a very physical waterline. When a project's total token count stays under 1 million, one person with their team of AIs can still hold the complete picture in their head and context window. As a reference, 1 million tokens is roughly what a tiny AI-native team produces in 15 to 30 days. At 10 million tokens, a project reaches a tipping point where chaos and misalignment begin to escape control. Above 10 million, it must be split into multiple sub-projects of 1–10 million tokens each.
This directly determines where organizational form is heading: units must divide, departments must shrink, organizations must flatten. In the past, departments were divided by function (marketing, sales, engineering) or by business line (games division one, e-commerce division two). The boundary was a line on an org chart, an expression of power, resources, and reporting relationships. In an AI-native world, only one logic remains for drawing departments: partitioning context. Since no single AI can ingest a whole company's context, you have no choice but to slice it so that each slice fits into a finite context window and each department owns a relatively complete information world.
A department is, in essence, a "context-bounded token partition."
You call it the "marketing department" only because that partition holds the context about markets, users, and channels. The meaning of the boundary shifts from "managing people" to "managing information"—making sure information can be fed in and processed effectively.
How small should a unit be? Around 5 people. This is not a magic number from management theory but the equilibrium between communication and output: beyond it, the time spent on internal alignment starts to exceed the time spent on actual work.
When should a team add people? Not when a hiring quota arrives, and not when someone reports being overloaded.
The tipping point at which a team must expand is when its "review bandwidth" saturates. AI can massively increase execution bandwidth; it cannot increase review bandwidth.
Review bandwidth is the amount of material a person can carefully read, review, and give effective judgment on in a single day—a proposal, a contract, a design revision. That limit is set by their ability, their experience, and how solid the team's alignment infrastructure is. AI multiplies execution output by ten, but all of it still has to pass through this human gate. Only when everyone's review bandwidth is saturated and work keeps spilling over has the organization's throughput truly hit its bottleneck. That is when to add people—by splitting one large token partition into two smaller ones.
The counterargument: why I'm skeptical of agent group chats
A natural question arises here: if agents could communicate, collaborate, and resolve conflicts among themselves, couldn't we skip the laborious work of partitioning the organization? Plenty of products already market themselves as "agent swarms" or "multi-agent collaboration," expecting a group of agents to complete all the work autonomously in a chat room.
I am skeptical of this path, at least for the foreseeable future. Four reasons.
One, inconsistent context management. Each agent carries its own context, its own reading of the same words, its own update frequency. In a group chat, this inconsistency is rapidly amplified into misunderstanding.
Two, the complexity exceeds what most people can manage. Never mind 10 agents—most people struggle to manage two or three well. Each agent has its own inputs and its own drift direction; coordinating them into a working unit demands a great deal from the human in charge.
Three, the alignment cost is high. The communication funnel from Part 1 becomes a web here: you align with A, A aligns with B, B aligns with C, and every leg loses fidelity while draining you daily.
Four, once divergence sets in, convergence is extremely hard. Each agent digs deeper in its own small direction. At delivery time you receive a large batch of output that looks complete but carries small defects in 10 different directions, none of them obvious. To pull it back, you must correct 10 different errors in 10 directions at once—harder than starting over.
Fundamentally, every agent draws on your "Dunbar budget." The anthropologist Robin Dunbar found that a person can maintain about 150 stable relationships (Dunbar's number). Leading agents draws on this budget even more heavily than leading people: not because they lack intelligence, but because your own context width is finite. The number of agents a person can effectively lead is a function of the context window, not a figure that can be stacked without limit.
The shape of a large organization: a federation of amoebas
A single super-brain cannot hold all the context, and the independent units that can are only about 5 people each. So when an organization grows large enough, its only path is to become a federation of "context-bounded units." The readiest name for such a unit is the amoeba: each amoeba owns one domain, leads its own squads of agents, and delivers independently within its bounded context.
This is not an invention of the AI era; it is the same physical law projected once more onto organizational form. And we need not work it out from scratch—the companies that pioneered flat, autonomous small units decades ago have already handed in their answers. Kazuo Inamori's Kyocera used "added value per hour," a business metric everyone reads the same way, plus a shared "Kyocera Philosophy," to keep thousands of amoebas profitable in the same direction without deep hierarchy. Haier's Rendanheyi used internal markets and a shared platform to turn every micro-enterprise into a startup unit facing the user directly. Morning Star, the tomato processor, uses point-to-point written commitments between colleagues (CLOU) to sustain a boss-less network with clear accountability. Add W. L. Gore's lattice structure (capped near Dunbar's 150) and the Netherlands' Buurtzorg (small teams plus a shared IT platform).
Abstract these practices and they solve the same problem—"without thick hierarchy, how does information flow up, down, and sideways"—with the same three-part kit.
A shared information base everyone can read; a shared mission and set of values everyone believes in; and clear market-style or written contracts between units.
The AI-native organization merely swaps a new engine into each of the three. The shared base becomes a machine-readable a2a context pool. The shared philosophy becomes the constitution that agents also read and act on. The written contracts become the a2a protocols agents use to call one another. Even the size of the unit is no longer set by the psychology of Dunbar's number, but by the physics of tokens, entropy, and the context window.
One warning from Conway's Law must be added here. This software engineering law states that the systems you build will inevitably mirror your organization's communication structure. AI is an amplifier that magnifies the structure you already have; it creates nothing new on its own. Most companies will take the seemingly easiest passive path: treat AI as an efficiency tool and plug it into existing functional silos—marketing's AI does marketing, sales' AI does sales. The result is not fewer walls but more walls, built faster and stronger, as each AI, loaded with its department's context, goals, and biases, produces ever more locally-optimal "improvements" at superhuman speed. You cannot buy an AI that climbs over walls. If you want AI to break down barriers, people must tear down the walls first: change the human structure, rebuild the function-based silos into cross-functional, goal-oriented amoebas, and only then put AI into their hands.
These laws are not new — software already paid the tuition for you
The names below may be ones you have never heard, but the phenomena they describe are ones you have almost certainly seen inside your own company. Software was simply the first industry forced to write them down as iron rules, because it was the first industry that had to manage a "worker" at scale — one that happens to be stateless, literal-minded, context-limited, and infinitely fast.
Software engineering was the first industry forced to manage, at scale, a worker that is stateless, literal-minded, context-limited, yet infinitely fast at execution. That worker was called a "program." Today every industry has been handed the same kind of worker. Its name is agent. So every industry now inherits the same hard laws.
The behavior of AI is the behavior of a program. The inherited laws number at least nine:
- A project is already late, and adding people makes it later — newcomers need training from veterans, and the lines of communication grow with the square of headcount. Software wrote this into The Mythical Man-Month and calls it Brooks's Law.
- If you want any position to be swappable at any time, everything about that job cannot live only in one person's head — it must be written down in a shared place anyone can pull from. Software calls this stateless services.
- When the same number disagrees across three reports, it is almost always because it has three sources. For facts to stop fighting, every important fact must have exactly one authoritative source, and everything else must reference it. Software calls this the single source of truth (SSOT).
- The only workable way to manage a complex business is to cut it into units that are meaningful and can run on their own — tightly connected inside, with only the simplest, most stable interfaces outside. Software calls this high cohesion, low coupling.
- Collaboration between units runs on written agreements set down in advance, not on meetings, friendships, or tacit understanding — exactly what Morning Star does with its colleague-to-colleague CLOU letters. Software calls this interfaces and contracts.
- Before the day ends, automatically pull everyone's work together and reconcile it, so every brewing conflict surfaces the day it appears instead of hiding until late in the project. Software calls this continuous integration (CI).
- A decision-maker can seriously review only so much material in a day, and that ceiling sets the whole company's bottleneck. AI can multiply output ten or a hundred times, but a human still has to sign off, and human judgment bandwidth is finite. Software's counterpart is code review.
- The vague decisions and unwritten verbal agreements made to save time today all come due later, with interest — paid in misunderstanding, rework, and endless disputes. Software gave this a name: technical debt. Inside an organization, it is alignment debt.
- Deliberately stopping at intervals to redraw reporting lines, re-partition departments, and archive or delete stale material is the maintenance that pushes chaos back under control. Software calls this refactoring.
Conway's Law is the tenth; the previous section already used it.
The decision-maker's new job, and the training of you
When your team is no longer composed of individual "people" but of "human + AI" amoebas, your job as the decision-maker changes completely. You no longer drive the organization by chasing progress and managing personnel. The new job has exactly three parts. Maintain the constitution: guard the top-level mission, vision, and values so they remain the final, sole arbiter in every corner of the organization. Design the partitions: your most important decision becomes where to cut—slicing a complex business into cleanly bounded, contextually self-contained token partitions, each handed to an amoeba to cultivate. Guard the alignment: watch the most macro level, so that the combined force of all amoebas still points where the constitution says.
The growth lever changes too. Growth used to come from hiring; now unrestrained hiring only brings entropy and soaring communication costs, quickly bursting the organization's review bandwidth and context windows.
The AI-native organization's growth lever shifts from "hiring people" to "adding clarity": write the constitution more clearly, design the partitions more sensibly, then replicate the amoebas that share the same constitution and already run smoothly.
We are in an awkward transition. When model context windows grow from today's million-token level to five or ten million—my estimate is another 1 to 3 years—the number of agents each person can effectively lead, and the business complexity each amoeba can carry, will rise a level together. Until then, this era of one-person teams and organization-wide friction will persist for a while.
But the foundation is already clear. AI has only two properties, statelessness and finite context, and like a mirror it forces you to think your organization through, write it down, and align it. The one being trained was never the AI. It's you. Since you haven't hired anyone and are already running a company, build it seriously as one—starting from a constitution that machines can also read.