Here's the result before the reasoning: the production swarm I run — a dozen agents working across the studio and the products I ship — has no orchestration framework, no message bus, and no state machine. It runs on a managed routines runtime from the model vendor, a handful of cron schedules, MCP connectors into the systems of record, and failure alerts that land in one Slack channel. That's it. And it's not a toy or a diagram — it's the live architecture behind my own agent swarm and GoBriefed, a thin agent built the same way.
I'm writing this because if you search multi agent orchestration today, you get a wall of vendor glossary pages telling you that you need a platform to do this. You don't. Here's what I actually run, why I chose the smallest possible version of it, and how to tell whether you need more.
IThe payoff up front: no orchestration framework, no message bus, and it still runs a dozen agents
The temptation, when you decide to run several AI agents, is to reach for machinery. A framework to coordinate them. A message bus so they can talk. A state machine to track who's doing what. Every vendor in the category is happy to sell you all three.
I run the smallest, dumbest possible thing instead. Cron fires the workers on a schedule. Each agent reaches its data through MCP connectors that govern exactly what it can read and write. When something breaks, an alert lands in a single Slack channel and I go look. No framework sits in the middle brokering messages between agents, because in my setup the agents don't need to talk to each other — they each do one job against shared systems of record and hand off through data, not chatter. If you want the parts list, the exact stack behind it is public.
That's the whole architecture. The rest of this piece is why that's a feature, not a shortcut.
IIWhat 'multi-agent orchestration' actually means once you strip the vendor language
Strip out the marketing and multi-agent orchestration is simple to define: it's coordinating several specialized agents toward one goal. One layer — the orchestrator — decides which agent runs, when, and with what context. The agents themselves are narrow: a research agent, a summarizing agent, a monitoring agent. Orchestration is just the part that points them at the work in the right order.
That plain definition matters, because the search results for this term don't give it to you. They give you product tours. That's the one real gap in the conversation — a category full of enterprise explainers and almost no honest operator accounts of what a working setup looks like. So here's mine.
IIIWhy we didn't buy a platform: the case against a message bus and a state machine
Every piece of orchestration machinery you add is more surface area that can fail. And the failure rates in this field are not reassuring.
The MAST study — a NeurIPS 2025 spotlight that hand-annotated 1,642 execution traces across seven popular open-source multi-agent frameworks, including MetaGPT, ChatDev, and HyperAgent — found failure rates ranging from 41% to 86.7%, with no consensus across the field on how to build these systems reliably. When the frameworks meant to make multi-agent work robust are failing between four and nearly nine times out of ten in independent traces, "just adopt a platform" stops sounding like the safe choice.
The second problem is churn. The platform you standardize on this year is a moving target. Framework surveys of the current landscape note that Microsoft has shifted AutoGen into maintenance mode in favor of its unified Agent Framework, that CrewAI is the fastest low-code entry point, and that LangGraph is considered the most production-tested option for stateful, observable systems. All true, all this year — and all of it will read differently next year. "Pick a platform" isn't a decision you make once. It's a bet you re-underwrite every few quarters.
My read: the more orchestration machinery you own, the more of your reliability depends on a layer you didn't build and can't fully see. So I keep that layer as thin as it can be.
IVThe owned vs. rented framework: seven pillars, five that don't move
The way I think about any AI system is the owned vs. rented framework we run the whole studio on. There are seven pillars. Five you own. Two you rent.
The five owned layers shouldn't change for years:
- Your repo and tickets — where the work and the decisions live.
- Your hosting — where it all runs.
- Your data and schema — mine sits in Supabase.
- Your secrets and identity — who and what is allowed to do anything.
- Your observability and run-log — the record of what every agent actually did.
The two rented layers are the model and the agent harness. Those you should expect to turn over every twelve to eighteen months — and when they do, you swap them with a config change, not a rewrite. That's the whole point of the split. If replacing your model means re-plumbing your data, your identity, and your logging, you didn't rent the model — you married it. Keep the owned layers stable and boring, and the rented layers stay cheap to replace.
Orchestration lives in that rented harness layer. Which is exactly why I refuse to weld it to everything else.
VInside the actual swarm: a dozen worker roles, cron, MCP, and one Slack channel
The swarm is about a dozen worker roles, each named for what it does: a scout, a curator, an observer, a listener, an engineer, a synthesizer, and a few more. None of them is clever. Each one has a single job.
The mechanics are just as plain. Cron schedules trigger the workers — this one runs every few minutes, that one runs once a week. Each worker reaches the outside world through MCP connectors, and those connectors are where the real governance lives: a custom MCP server, built per fund, decides exactly what the model is allowed to read and write. The model itself is Claude — Sonnet as the default, Haiku when I need low latency at volume — with skills packaged and version-controlled through OpenClaw, and plain SaaS-to-SaaS glue handled by Zapier where nothing smarter is warranted. When a run fails, it says so in one Slack channel. That's the entire control plane. The studio's own swarm is headed for Claude Managed Agents as its home, but the shape doesn't change: schedule, connector, model, alert.
Notice what isn't there. No central brain routing messages. No shared state to corrupt. Each agent is stateless between runs and talks to the world through governed connectors, not to its siblings.
VIWhat it costs to actually run this: June 2026's real bill
The honest way to argue for lean is to show the bill. Here's what the swarm cost me to run in June 2026:
Under $1,500 for a month of a dozen working agents. The shape of that number is the interesting part. The constant, high-frequency jobs run on cheap models — GPT-4o mini, GPT-5.4 mini — and they barely register. Meanwhile the single weekly Claude Opus synthesis run costs more than a full month of the frequent agents combined. One expensive judgment call a week, a swarm of cheap workers the rest of the time. That's the ratio you want. I broke the whole thing down in what the swarm actually cost to run last month.
Two numbers from the wider field explain why staying lean is also staying cheap. Research aggregated across production deployments estimates that re-sent, repeated context accounts for roughly 62% of total agent inference costs industry-wide — meaning most of what people spend is agents re-reading the same material to each other. The same research finds coordination gains plateau beyond about four agents; past that point, coordination overhead grows faster than the value each new agent adds. A framework that makes it trivial to spin up twenty chatty agents isn't saving you money. It's inventing your biggest line item.
VIIA thin agent in production: GoBriefed as the opposite of a platform
If you want the cleanest example of a harness instead of a platform, it's GoBriefed, a thin agent built the same way. It reads your calendar, pulls attendee context from Affinity, runs Perplexity-grade research, and lands a one-page brief in your inbox an hour before each call.
Underneath, it's point tools wired together: Affinity, your Outlook or Google calendar, LinkedIn, Perplexity, Claude, and Postmark for delivery. There's no orchestration engine in there. There's a schedule, a sequence of narrow steps, and a governed reach into each source. That's the pattern for every agent I ship — a thin harness that does one valuable thing end to end, not a general-purpose platform waiting for you to configure it into usefulness.
VIIIThe industry is converging on the same idea, just louder
Here's what makes this timely rather than just my opinion: the builders I follow are landing in the same place from different directions.
LangChain shipped Dynamic Subagents at the end of June 2026. Instead of the main agent invoking subagents one at a time through tool calls, it now writes a short orchestration script that dispatches them programmatically. They built it, in their own words, because normal subagents "work at small scale" but "break down when you need to spawn hundreds of subagents, or when the orchestration logic is conditional or multi-phase." Read that carefully: it's a harness decision, not proof you need a platform. And LangChain frames its own stack as deliberately layered — LangGraph as the graph runtime, Deep Agents as an opinionated harness on top, drop down a level when the shape is wrong. Even the framework makers treat this as choices you compose, not a single locked box.
shadcn made the same move from the coding side. His shadcn/improve skill, shipped in June 2026, splits AI work into an expensive-reasoning planning pass on a frontier model that writes scoped, self-contained specs, and a cheap-model execution pass that implements them. That's the same instinct as my one-Opus-run-a-week ratio: the planning and context is the engineered, owned part; the model doing the grunt work is swappable commodity.
And then there's the warning. Matt Pocock pointed out that simply saying the word "workflow" inside Claude Code — even innocently, like naming a GitHub Actions workflow file — can trip the tool into its workflow mode and spin up dozens of subagents unprompted. That's what ceding orchestration control to a vendor default actually feels like: machinery firing on your behalf because of a keyword you didn't mean. I'd rather own the trigger.
IXThe harness is the product, the model is the dependency
This is the whole thing, and I've said it plainly before:
The model is the part you rent and the part that changes. The harness — the tools your agents can reach, the memory they keep, the connectors that govern them — is the part you own and the part that lasts. Build for that split and a model swap is a config change. Build against it and every new model release is a migration.
XHow to tell if you actually need a platform (and when you don't)
Here's the practical version if you're building your own swarm.
Start with the smallest dumb thing: a schedule, a managed runtime, governed connectors into your systems of record, and one alert channel. Ship that. Run it for a few weeks. In most cases — a solo product, a lean team, a fund's back office — that's the finished architecture, not the prototype.
Only add orchestration machinery when a real coordination need forces it, not when a vendor's pitch does. If your agents genuinely have to negotiate shared state, run conditional multi-phase logic, or fan out to hundreds of subagents, that's a signal to reach for a heavier harness. Wanting to feel more "production-grade" is not. And use the roughly-four-agent plateau as your sizing gut check: if adding the fifth or sixth agent isn't clearly buying more than the coordination it costs, you don't have an orchestration problem — you have too many agents.
The smallest thing that works is almost always the right thing to run. Everything else is surface area waiting to fail.
XIFAQ
Does Black Matter use LangGraph, CrewAI, or AutoGen?
No. The production swarm runs framework-light on purpose — a managed routines runtime, cron, MCP connectors, and one Slack alert channel. Those frameworks are real tools, but every layer of orchestration machinery is more surface area to fail, and I only add it when a genuine coordination need forces it.
What happens when the model I run on changes?
It's a config change, not a rewrite. The model is a rented layer I expect to turn over every twelve to eighteen months. The owned layers — data, identity, logging, the connectors — don't move, so swapping the model doesn't touch them. That separation is the entire design.
Can a lean team run this without hiring engineers?
That's the point of keeping it small. A schedule, a managed runtime, governed connectors, and one alert channel is something a lean team can operate. Building and running that harness for funds and founder-led teams is exactly what my studio does — so if you'd rather have it stood up and maintained for you, that's the work.
— Michael Rouveure
