Mixture of Actors — peerd

// all posts<br>rss →

The monolith

Strip the UI off any agent product shipping today and the coding agents, the browser agents, and the everything-assistants are the same shape underneath: one loop, one context window, everything in it. Every tool the agent might ever need described up front and every byte every tool has ever returned, constantly accumulating. And all the authority the user granted, held in the same place as all of that. Subagents help by splitting work across loops, but each loop is typically a general-purpose copy of the parent, carrying the same tools and the same broad prompt, so it reproduces the dense structure instead of escaping it.

This model has three problems. Outside the frontier data center models it degrades fast. Keeping dozens of tools and a couple hundred thousand tokens of mixed history straight is exactly what smaller models are bad at. It is also expensive, because every decision pays for the whole context. The third problem is a lack of structural isolation: if an agent fetches a page it lands in the same context that holds your credentials and your capabilities, and the only thing between a hostile instruction on that page and your authority is a line of defensive prompt text.

The lesson from inside the model

Model architecture already went through a similar evolution. Mixture-of-experts models stopped activating every weight for every token: a router sends each token to a few dynamically routed "experts" and everything else stays idle. Activating a small specialized slice beats activating everything, per unit of compute, and it has become a dominant way to scale capacity: most large open models are built this way now, and in all likelihood all of the frontier closed ones too.

peerd's bet is that the same economics hold one layer up, at the agent orchestration layer. Instead of one loop holding everything, an orchestrator routes each task to a small actor that holds only the context and tools for its function. The browsing actor knows how to drive a page and only how to drive a page. It has the DOM interaction tools and nothing else. The VM actor knows its Linux machine instance inside and out. The notebook actor knows its files, and what utilities are available to it. Each one starts lean and reports back in a sentence or two. The raw page text or terminal output it worked through never lands in the orchestrator's context. Leaner context per decision, and specialization according to the environment and task, is the harness-layer analog of sparse activation. It is also why the architecture has the potential to work really well with smaller locally hosted models: no single model call has to keep dozens of tools straight, each one just has to do one job with a handful.

Despite the confusing and imo misleading "mixture of agents" term, I found the best description for this architecture is a mixture of actors . In a mixture of experts the routing is learned and per-token. At the harness layer the router is itself a model: the orchestrator delegates each task in plain language, or writes a script when a chain of actors needs coordinating. The analogy is looser than the name implies but still useful. MoE experts are weight partitions a learned router happens to lean on, not the clean hand-built specialists the naming suggests. But the main theme holds: routing and dividing to narrower units beats monolithic bloat.

That bet stopped being just peerd's a day after I first wrote this. Anthropic is now recommending a similar move for their own models: run a cheap model as the executor and call a stronger one only as an on-demand advisor, or flip it and run the strong model as an orchestrator that plans and fans work out to a pool of cheap workers, with most of the tokens billed at the cheaper rate either way. The vocabulary mostly overlaps: orchestrator is a term we already use, just for a role that in this system is itself an actor, and advisor and executor are the two genuinely new ones. The wager underneath resembles the one MoE made inside the model: route the expensive reasoning to where the task actually needs it and let something cheaper handle the rest. When the lab that trains the models converges on a similar layer-up argument, that's a good sign the economics are real.

Actors need walls

Isolation between experts is engineered into a mixture-of-experts model: separate weights, a router between them, no way for an expert to reach into its neighbor. At the harness layer that isolation has to be engineered too, and that is most of the work. A monolithic agent loop has none of it: every tool result, every fetched page, every model-written script shares one context with all the authority. Prompt text is not a boundary.

Subagents give you delegation and a separate context window, which is what the advisor and orchestrator patterns above are built on, and that's real and useful. Context and heap are different things though: nothing about...