When the Model Becomes an Org

A note on where this comes from: I design agentic systems for a living, and I read management theory because I kept drawing the same boundary (where does “the model” end and “my system” begin) and getting it wrong. The claims about how OpenAI’s swarm behaves are from Noam Brown describing it on a podcast, not independently confirmed. Everything else is cited at the bottom.

The word “model” moved while we were looking at benchmarks

For most of the last decade a “model” was a single thing that took a prompt and produced an output. You reasoned about it as one predictor with a context window. That mental model is now wrong at the frontier, and the shift matters more than any single benchmark number.

I came at this same word once before, arguing that what we ship as a “model” had already quietly become a compound system, several models plus orchestration and tools, and I asked readers for a better name for it [6]. No name stuck, and the thing did not wait. It has moved again, and this time not toward a bigger pipeline but toward something that behaves like an organization.

When Noam Brown, the OpenAI researcher behind the reasoning models and now its multi-agent work, describes how the Navier-Stokes system was built, he is careful to deflate the hype: “I wouldn’t even attribute 10% of the credit to multi-agent. The reality is that OpenAI has trained a very powerful model.” [1] Keep that deflation in mind for the whole post. The swarm is not magic. It is a way to spend test-time compute in parallel once you have a strong enough general model. The magic, such as it is, lives in the model. And to be clear about the run itself: no solution to Navier-Stokes, and no verified partial result, is claimed here. What makes it worth writing about is the structure the collective grew, not any mathematical output.

But something did change, and it is structural. The unit you deploy is starting to behave like an organization. Once you see that, a set of laws we already know about organizations, laws that predate transformers by decades, start applying inside the thing you used to treat as a single function call.

Two directions for one word

Here is the confusing part. “Multi-agent” is being built in two opposite directions at once, and both call the result a model.

The labs are pushing it down, into the model. Brown describes OpenAI’s GPT-5.6 as having a multi-agent capability he calls Ultra Mode, defaulting to four agents and scaling up from there [1]. From the outside it is one product. You send a request, a collective of agents forms inside, coordinates, and returns an answer. The multi-agent structure is a hidden implementation detail of “the model.”

Applied-AI builders are doing the reverse, building it up, on frameworks. You take single-purpose agents and wire them together yourself with an orchestration library. The multi-agent structure is the thing you designed and can see.

Same word, two directions. And the boundary between “the model” and “the system I built on top of the model” is exactly where those two directions meet. It used to be a clean line. It is now a design decision.

One added primitive, and an org grows around it

The design that makes this uncanny is how little structure the labs bake in. Most multi-agent systems people build use a scaffold: a coordinator agent hands tasks to child agents, collects their answers, and synthesizes. Sensible, and it works, but Brown lists its limits. Siblings usually cannot talk to each other. A child that hits a clarifying question has to choose between blocking to ask and guessing what the parent wanted [1].

OpenAI went the other way. The primitive Brown highlights is letting an agent message another agent directly (the message lands in the recipient’s context); with that added to the setup, the collective works out coordination itself. What emerges, Brown says, looks like people on Slack: one agent proposes an answer, another disagrees, they interrogate each other’s reasoning, converge, then broadcast the change to the rest [1]. In Brown’s account, once peer messaging is added to the surrounding setup, the collective reinvents the patterns humans use to coordinate, including a spontaneous hierarchy, a middle-management layer nobody designed. The podcast does not isolate messaging as the sole cause; the model, prompts, objectives, and compute budget are all in play.

Why would that happen? Brown gives one reason directly and the rest is reasonable inference:

• The models are trained on an enormous amount of human text, so they carry a prior on how humans organize and communicate. The coordination is not invented from nothing; it is recalled and polished [1].
• One possibility (my read, not Brown’s claim): optimizing for collective task performance favors the familiar coordination patterns already represented in the model’s training data.
• Getting there is not automatic. Brown notes the agents tend to collapse into a local minimum where “we’re all just going to solve the problem independently,” and only more general models climb out of it into real coordination [1].

That human prior is worth pausing on, because it cuts both ways. The collective coordinates like people because it was trained on people. So what happens if you withhold that prior, or train against it, and let a collective work out coordination from the task alone? Maybe it rediscovers our playbook, hierarchy, handoffs, status updates, because those patterns are genuinely efficient. Maybe it finds a structure with no human analogue that is simply better for this kind of work. And if it did, the question that interests me most is whether it would transfer back: whether a machine collective could hand us a better way to organize ourselves. I do not know. But it turns “the model reinvented Slack” from a cute result into a real question about whether human org design is optimal or just familiar.

So the interesting object is no longer a predictor. It is a small, fast, self-organizing firm that happens to fit inside one API call. And firms have laws.

Law one: most “teams” are groups, and this collective is team-like

In 1993, Jon Katzenbach and Douglas Smith drew a distinction in the Harvard Business Review that most managers still get wrong. A group is a set of people with individual accountability who share information and make decisions to help each other perform in their own areas. A team is smaller, has complementary skills, a common purpose, and, the load-bearing part, mutual accountability. The team owns a collective work product that no single member could produce alone. [2]

Their uncomfortable claim was that most working units in a company are groups wearing the word “team.” Real mutual accountability is rare and hard, because you cannot compel it. It shows up when a small number of people commit to something together and hold each other to it.

Watch what the emergent agent-collective does against that definition. It has a common purpose (solve the problem). Its agents divide the work, though that is division of labor, not proven complementary skills. And it does something that looks like the rare part: it cross-checks and corrects toward a shared answer, interrogating each other until it converges, then owning the result collectively. Be careful with the mapping, though. Peer correction is not the same as mutual accountability, because model instances do not hold each other to commitments with consequences, and interdependent output is not proof of complementary skills. What I am claiming is a behavioral resemblance on three axes, common purpose, interdependent output, and peer correction. Complementary skills and mutual accountability remain unestablished. On those three axes, it reads less like a group and more like a team.

The freshest consequence: the team-size ceiling may not bind

Here is the part I find most interesting, and it is a consequence, not a citation.

Mutual accountability is why teams are small. You can hold a shared commitment with a handful of people. You cannot hold it with ten thousand, which is why large organizations decay into groups, politics, and fiefdoms. Brown puts the human version plainly: a five-person startup where everyone owns 20% is highly aligned, and a 10,000-person company is full of people building fiefdoms and gaming headcount. That misalignment, he argues, is a big part of why startups disrupt incumbents [1].

The team-versus-org trade-off has always been forced. You get team-grade alignment or you get organizational scale, not both.

An agent-collective might not face that forcing. If alignment between the agents holds, and Brown says training them to be cooperative makes them behave, roughly, like a room full of 20% co-founders [1], then you might keep team-grade alignment while adding agents. And unlike people, you can clone the aligned ones and spin them down when you are done. So “team” and “organization” stop being opposite ends of a trade-off. You could, in principle, have a ten-thousand-strong unit that still behaves like a five-person founding team.

Brown is careful, and so am I: nobody has measured that 10,000 agents coordinate better than 1,000. He says outright it is entirely possible 10,000 humans still coordinate better than 10,000 agents today [1]. This is a structural possibility, not a benchmark. But it is the possibility that makes the org lens worth taking seriously, because if it holds, a century of organizational scaling limits might not be a law of nature for collectives like this. The measurements that would settle it, task quality versus agent count, communication overhead, correlated-error rate, are not ones Brown reports for this system.

Law two: Conway’s law, and the lever you might lose

The second law is the one architects feel in their bones. Melvin Conway in 1968: “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” [3] Martin Fowler’s gloss [9] draws on Conway’s own example: assign four groups to build a compiler and you get a four-pass compiler, one pass per group. Software coupling follows human communication.

The modern move is to run the law backwards. The inverse Conway maneuver: deliberately shape your team and communication structure so the architecture you want falls out of it [9]. It is why we form small, long-lived, capability-aligned teams to get small, independently deployable services. We steer the design by drawing the org chart.

Now put an emergent agent-collective in the designer’s seat. If a Conway-like effect holds here, the systems the collective designs would mirror the collective’s communication structure. But that structure is the emergent one, the middle management the swarm grew on its own, not one you drew. And here is the lever you may lose: the inverse Conway maneuver assumes you can change the design by changing the org chart. If the org self-organizes from a messaging primitive and a learned prior, there is no chart to redraw. You do not get to reassign the agents into the shape you want the architecture to take.

What replaces the lever is not nothing. You still shape the collective through its incentives, its prompts, its reward signals, and the tools you expose. But that is a softer, more indirect kind of steering than moving boxes on an org chart, and it is worth knowing you have traded one for the other.

So where do you draw the boundary?

This is the actual takeaway, and it is a decision, not a prediction. If the model is becoming an organization, then designing an agentic system is deciding which organizational properties you refuse to leave inside the model, and provide yourself instead. Four are worth keeping outside on purpose.

Identity. Who is each agent, and on whose behalf is it acting? An emergent collective does not hand you per-agent identity for free.

Observability. Can you see what the collective did and why? Emergent coordination is legible to the agents, not necessarily to you.

Accountability. When something goes wrong, can you trace the decision to a bounded actor? Mutual accountability among agents is not the same as accountability to you.

Steerability. When you cannot redraw the org chart, what levers do you actually hold?

The good news for builders is that this is a well-trodden layer, and on AWS it is concrete rather than aspirational.

If you want the coordination to be explicit and inspectable, you scaffold it rather than hope it emerges. The Strands Agents SDK [8] gives you explicit, inspectable multi-agent patterns: agents-as-tools (a hub-and-spoke where one manager calls specialists), graph workflows (a structured graph with an execution order you define), and swarms (a decentralized network where agents hand off to each other, but with hard safety controls: caps on total handoffs and iterations, an execution timeout, and automatic termination when the same agents keep passing work back and forth) [4]. That is the opposite of the lab’s minimal-primitive design. The routing is something you specify and can read, which is exactly what you want when the alternative is an org you cannot see.

And underneath, you keep the org properties in the runtime. Amazon Bedrock AgentCore Runtime gives each session its own isolated microVM, with separate compute, memory, and filesystem, terminated and sanitized when the session ends, so per-session compute, memory, and filesystem state cannot bleed across [5]. External stores, tools, or credentials that sessions share are still the application’s job to isolate. You map users or agents to sessions to get that runtime-local boundary. AgentCore pairs that isolation with managed identity [10] and built-in observability [11] for the agents you run. Together they let you correlate authenticated actors, sessions, tool calls, and traces, which is what makes an action attributable to a bounded actor. That is not the same as explaining every model decision. These are primitives, not outcomes: the attribution only holds if you propagate identity, map sessions, and instrument on purpose. None of this is a cage around a dangerous thing. It is the legibility and accountability substrate that the emergent in-model org, by its nature, will not give you. The cloud layer is what lets you use emergent multi-agent power and still answer the four questions above.

If you are scaling a single-agent harness into a multi-agent system, that boundary turns into a short, concrete checklist:

• Make the coordination explicit, not emergent. Pick an orchestration topology you can read, agents-as-tools, a graph with a defined execution order, or a swarm with peer-to-peer edges, instead of hoping structure appears. Strands ships all three as first-class patterns [4].
• Put hard controls on any decentralized handoff. Caps on total handoffs and iterations, an execution timeout, and automatic termination when agents keep passing work back and forth. A swarm without brakes is an outage waiting to happen [4].
• Keep identity and isolation in the runtime. One session, one isolated microVM; map each user or agent to a session so work cannot bleed across [5].
• Instrument for accountability before you scale, not after. Managed identity and observability let you correlate authenticated actors, sessions, tool calls, and traces [10][11], so an action is attributable to a bounded actor. That is not the same as explaining every model decision, but it is the accountable-actor boundary you want.
• Treat multi-agent collaboration as a managed capability, not glue code you own forever. Amazon Bedrock offers supervisor-and-specialist collaboration as a built-in feature rather than something you hand-roll and maintain [7].

But the labs did the opposite

Fair objection: OpenAI got its result by giving the agents almost no structure, one primitive, and I just told you to impose structure. Both hold, once you separate the research frontier from what you should ship this quarter.

Letting coordination self-organize from a bare primitive is a research bet. It needs a model strong enough to climb out of the “everyone works alone” local minimum, and a tolerance for structure you cannot see or steer. For most production systems today, I would not count on that model headroom or that risk budget, so my default is to provide the structure. And we are not short of good ones: a century of organizational experience, Conway and Katzenbach included, already tells us which coordination patterns work. Architect with that now, explicitly, and leave self-exploring structure as the research track it currently is.

But borrow the one thing the minimal design got right: let agents talk to their peers, not only up and down a coordinator chain. A strict hub-and-spoke, where a manager fans work to children who never compare notes, is exactly the bottleneck Brown says throttles the scaffolded approach: siblings cannot talk, and a blocked child has to guess or wait [1]. In Brown’s account, peer-to-peer messaging is what removes that bottleneck: siblings can compare notes directly instead of blocking or guessing. So design lateral channels in on purpose: a graph or swarm with peer edges, bounded by the handoff and iteration caps above. Explicit structure with peer channels is the synthesis. A pure coordinator tree just re-imposes the limit the labs removed.

To make that tradeoff tangible, here is a toy model you can poke at. Switch the topology, add concurrent pairs, and watch two numbers: the messages sent and the time to converge. Under the model’s assumptions, the coordinator can become a bottleneck as parallel work piles onto it.

It is not a simulation of any real system, and it assumes a serially-serviced coordinator with finite throughput and two-hop peer messaging. Under those assumptions it shows one thing: routing every message through a single coordinator costs more messages and serializes work that peers could have done at the same time. A coordinator with enough parallel throughput would not bottleneck the same way.

The boundary, then, is not “model versus not-model.” It is “which properties of an organization am I willing to let emerge inside the model, and which do I insist on owning in the system around it?” Draw that line deliberately. The model will happily draw it for you if you do not, and it will draw it in a place you cannot see.

The question I am sitting with

We spent years learning that your org chart becomes your architecture, and that most teams are really just groups. Both of those were laws about people. They may be quietly becoming laws about models. So the question I would put to anyone building agentic systems: of identity, observability, accountability, and steerability, which are you keeping outside the model on purpose, and which have you left inside it by accident?

Sources

• [1] Noam Brown on the Dwarkesh Podcast: Agent swarms, alignment, and recursive self-improvement (2026-09-17) · the send-a-message primitive, emergent coordination and hierarchy, the “20% co-founder” argument, and the “not 10% of the credit” deflation. Claims about OpenAI’s system are Brown’s account, not independently confirmed.

• [2] Jon Katzenbach and Douglas Smith, “The Discipline of Teams,” Harvard Business Review (1993) · the group-versus-team distinction, mutual accountability, and the collective work product.

• [3] Melvin Conway, “How Do Committees Invent?” (Datamation, 1968) · the original statement of the law and the four-group, four-pass compiler example.

• [4] Strands Agents: Multi-Agent Patterns (Agent Swarms) · scaffolded swarm, graph, and agents-as-tools patterns with handoff and iteration safety controls.

• [5] Amazon Bedrock AgentCore: Use isolated sessions for agents · per-session microVM isolation, memory sanitization, and managed session lifecycle.

• [6] When a ‘Model’ Isn’t Just a Model: Redefining AI Systems for the Builder’s Era · my earlier take on the same word, when a shipped “model” had already become a compound system and I was still hunting for a name for it.

• [7] Use multi-agent collaboration with Amazon Bedrock Agents (Amazon Bedrock User Guide) · the supervisor-and-collaborator multi-agent capability as documented, including its behavior and setup.

• [8] Introducing Strands Agents, an Open Source AI Agents SDK (AWS Open Source Blog) · the model-driven agent SDK behind the multi-agent patterns above.

• [9] Martin Fowler, “Conway’s Law” · the inverse-Conway maneuver and modern commentary on the law.

• [10] Provide identity and credential management for agents (Amazon Bedrock AgentCore Identity) · managed identity for agent applications.

• [11] Observe your agent applications (Amazon Bedrock AgentCore Observability) · tracing and telemetry for the agents you run.

About the Author

Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.

This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.

Learn more →

• AgenticAI
• MultiAgent
• AIAgents
• SoftwareArchitecture
• AmazonBedrock