Salesforce made multi-agent orchestration generally available today. Before you decide you already have a council, read what it actually does.
An orchestrator agent reads the incoming task, checks which specialist agents are registered, and routes the work to whichever one is best-fit — or splits the task and hands each piece to the specialist suited to it — then returns one coherent answer. Three agents in the system, or a dozen. Not once do two of them look at the same question.
That distinction sounds like a quibble. It is the whole ballgame.
What shipped today
Salesforce Summer '26 went GA this morning — Multi-Agent Orchestration, Atlas Reasoning Engine 3.0, agent-to-agent messaging, and MCP, with Google's Gemini 3.5 Flash wired natively into Agentforce. The biggest CRM in the field just made "multi-agent" a default setting for production orgs.
It is good engineering. Routing a task to the model best suited to it is exactly right for most enterprise work. The problem isn't the feature. The problem is the word. "Multi-agent" is now doing two completely different jobs in one phrase, and the gap between them is precisely where the expensive mistakes live.
Three things people call "multi-agent"
There are three distinct architectures hiding under that label, and they answer three different questions.
Routing asks: which model should handle this? One query comes in, a classifier picks the single best model, that model answers. Apple's new Siri does this — it grades each request by difficulty and sends it up a three-tier ladder. One question, one model, one answer.
Orchestration asks: who does which part? A task comes in, gets decomposed into sub-tasks, each sub-task goes to the specialist best suited to it, and the pieces get recombined. This is what Salesforce shipped today. A research agent, a drafting agent, a compliance agent — each owns a slice. It is division of labor.
Deliberation asks: what happens when two capable models look at the same question and disagree? The same question goes to multiple models. They answer independently. Then something reads the spread between their answers. This is a council.
Here is the line that matters. Orchestration divides the work. Deliberation doubles it. Only the one that doubles it can catch a model that is confidently wrong.
Why orchestration can't catch the mistake
A compliance specialist that flags a contract clause is not checking the research specialist's market analysis. It never saw it. Each agent owns a different slice of the task, so no two agents ever evaluate the same claim. That is the point of division of labor — and it is also why it produces zero disagreement signal. There is nothing to disagree about when every agent is working on a different thing.
Think about how high-stakes human systems actually buy safety. A surgical team doesn't get safer by having the anesthesiologist and the surgeon do separate jobs well — that's just competence. It gets safer when a second surgeon looks at the same scan and says "I'd cut somewhere else." Aviation doesn't trust one pilot's altimeter reading; it cross-checks two. The safety comes from redundancy on the same question, not specialization across different ones.
Orchestration gives you a well-run team where everyone does their own job. Deliberation gives you the second surgeon. A confident wrong answer sails straight through the first and gets caught by the second — because catching it requires someone else to have looked at the identical thing and landed somewhere else.
A concrete split
Ask a hard question — "should we price this contract at a discount to win the logo, or hold margin?" — and watch what each architecture does.
Orchestration decomposes it: a finance agent models the margin, a sales agent models the win probability, a synthesizer stitches them into a recommendation. Clean. Fast. One answer. And if the finance agent's discount-rate assumption is quietly wrong, nothing in the system is positioned to notice, because nothing else modeled the margin.
A council asks all of it of several models at once. Claude says hold margin and explains why. GPT-5 says discount and explains why. The gap between those two answers — the assumptions they don't share — is the analysis you actually needed. The single coherent answer orchestration hands you is the one thing a hard decision can't use: a number with the disagreement already deleted.
The substrate makes it worse
Here's the part that should make you uneasy. Salesforce wired Gemini into Agentforce today. One week ago, Apple rebuilt Siri on a custom Gemini model. Karpathy's open-source llm-council already runs Gemini as its chairman. The substrate under the biggest consumer surface and the biggest enterprise surface is converging on the same vendor.
Diversification only works when failures are uncorrelated. A monoculture means everyone inherits the same blind spot at the same moment — and a "multi-agent" system built entirely on one model's family is a monoculture wearing a crowd costume. You can't get model diversity from the platform anymore; it's being standardized away beneath you. The only place left to introduce a genuinely different opinion is the strategy layer above the platform, where you convene models from different vendors yourself.
A paper out this month — Consensus is Strategically Insufficient — makes the academic version of the point: for hard questions, collapsing disagreement throws away the signal you most needed to keep. Today's GA is what collapsing it looks like in production.
Where this lands
None of this is an argument against orchestration. Route the task to the best specialist when there is a best specialist. Most work has one. But the decisions you lose sleep over don't have a best model — they have two strong ones that disagree, and the disagreement is the information. An architecture that never puts two models on the same question cannot, by construction, hand it to you.
That is the line a council sits on. Red Team vs. Blue Team forces two models to argue the same question into the open. Chairperson Synthesis reads the disagreement and decides what to do with it instead of averaging it away. Quick Take is there for when one model genuinely is enough — most of the time. The strategy is choosing which question you're actually asking.
"Multi-agent" went mainstream today. Just check whether yours has ever put two models on the same question. If it hasn't, you don't have a second opinion. You have a faster way to ship the first one.
Try it free — no signup. shingik.ai