The lonely-agent problem
Most AI agents today are stuck in a particular kind of solitary confinement. They're good at one job — answering tickets, drafting emails, screening resumes — and they're completely blind to everything happening in the next room. A sales agent closes a deal and the moment of celebration is also the moment of dropped context: finance gets a Slack ping, success gets a forwarded email, onboarding finds out next week.
That gap between agents is where most of the real work used to live. The handoff meeting. The "looping you in" thread. The Notion doc that summarized the deal for the CS team. The reason your ops org exists at all is because no single tool knew the whole story, and someone had to be the connective tissue.
We've been quietly building the alternative for the last six months, and today it's generally available. We call it multi-agent orchestration, and it lets Aria, Atlas, Sage, and Theo work as a team — handing off context, scoping permissions, and chaining workflows the way a real ops team would.
How handoffs work: shared context, scoped permissions
The hard part of building this wasn't the orchestration layer. It was the trust model. If Aria has read access to your CRM and Theo has write access to your HRIS, what does it mean when Aria asks Theo to do something? The naïve answer is "it inherits Aria's permissions plus Theo's." The right answer is significantly more careful.
Every handoff in our system carries three things: a shared context object (the relevant deal, ticket, candidate, or invoice), a scoped intent (what the receiving agent is being asked to do), and a permission envelope (the union of what the requesting agent is allowed to read and what the receiving agent is allowed to do, with explicit caps the customer sets).
The receiving agent can ask follow-up questions but can't reach back into the requesting agent's tools. Every step is logged with full lineage in the audit trail you already get. If your security team wants to know exactly which agent did what, when, and on whose authority, that's a one-click view.
The Aria → Atlas → Sage → Theo path on a closed-won deal
Let's walk through what actually happens. Imagine your AE just got a signed MSA back from a mid-market prospect. Aria detects the signature on the document, confirms the deal moved to closed-won in your CRM, and triggers a handoff workflow.
Step 1 — Aria to Atlas. Aria packages the contract terms (start date, price, billing frequency, payment terms, entity, tax info) and hands them to Atlas with intent "provision billing." Atlas creates the customer in your billing system, generates the first invoice on the right cadence, and sets up the payment method capture link. It also checks for any non-standard terms — custom net-X, prorated start dates, multi-entity splits — and flags them for human review before posting.
Step 2 — Atlas to Sage. Atlas confirms billing is set up and hands context to Sage with intent "run kickoff." Sage drafts a welcome email referencing the actual product the customer bought, schedules the kickoff using the customer's calendar preferences (already in the deal record), and pre-populates the kickoff doc with the use cases the AE captured during discovery.
Step 3 — Sage to Theo. The kickoff identifies the buyer-side admin and a small group of seat-holders. Sage hands that list to Theo with intent "provision access." Theo invites the users with the right role mappings, sends them a personalized welcome message, and schedules an onboarding office hour. The entire chain — from signature to ready-to-use workspace — runs in about 11 minutes of agent time. The humans involved each look at one decision point, not eight.
Failure modes we ruled out — and how
Multi-agent systems fail in specific, predictable ways. We spent most of our build time on the failure modes, not the happy path.
- Permission creep. An agent receiving a handoff can never use the requesting agent's credentials. Every handoff downgrades, never upgrades. If you didn't grant Theo HRIS-write access, no chain of handoffs gives it to Theo.
- Loops and runaway chains. Every workflow has a max-depth and a max-step budget set by the customer. Chains that exceed it pause and escalate to a human, rather than retrying forever.
- Ambiguous intent. Receiving agents must confirm the intent before acting. If Sage receives a handoff with an intent it can't map cleanly to one of its workflows, it asks — either the requesting agent or a human, depending on configuration.
- Silent failures. Every handoff is observable in real time. If a step fails, the chain pauses and notifies the workflow owner. Nothing keeps going "as if" it succeeded.
None of this is glamorous. All of it is what we'd want if we were running ops at your company and trusting four agents to chain on top of each other.
What you can build with it today
Multi-agent orchestration ships on the Team and Enterprise plans starting today. You don't need to do anything to enable it; the moment you have two or more agents active, the orchestration layer is available.
The pre-built workflows we're launching with cover the most common chains we saw in beta: closed-won → billing → kickoff → onboarding, support escalation → expansion opportunity → AE handoff, candidate offer accepted → equipment provisioning → calendar setup, and a few more. You can also build your own with a visual workflow editor, or call our orchestration API directly if you want chains that span your own tools alongside our agents.
This is the version of multi-agent we wanted to ship the day we launched, and we're glad it's finally out the door. As always, the interesting part isn't the demo. It's what your team stops doing in week three.