Multi-agent orchestration explained: how Fulcrum Sessions splits the work

An orchestrator is the part of an AI system that decides who does what. You send one request — “get the Harbour St proposal out by Friday” — and it works out the steps, which steps a specialist agent can do, which need a person, what order they must happen in and which can run at the same time. Then it tracks them and reports back in the thread where you asked.

You don’t need orchestration for single tasks. You need it when requests are really projects: several pieces of work, different skills, some dependencies and at least one human decision. This article explains how that works using Fulcrum Sessions as the example. If you are new to delegating, start with how to delegate work to AI agents.

What an orchestrator actually does

Strip away the jargon and an orchestrator has five jobs:

1. Plan. Turn the request into a list of steps with a definition of done for each.
2. Split and assign. Give each step one owner: a specialist agent (research, operations, software) or a named person.
3. Sequence. Work out which steps depend on others and which can run in parallel.
4. Hand off. Pass context between owners so nobody starts from scratch, and stop at approval points.
5. Report. Keep one running record in the original thread: what’s done, what’s waiting, on whom.

The single most important word there is “owner”. A task with two owners has none. Every step in a well-run plan names exactly one agent or one person who is accountable for it.

Multi-agent orchestration for small business: a worked example

Here is an illustrative request from a small commercial cleaning company: “We’ve been invited to quote for the Harbour St office tower. Proposal due Friday. Can you pull it together?”

Notice the shape. The research and data-gathering steps fan out in parallel because none depends on another. Then everything funnels into one human decision — the price — because that is judgement, not admin. After the decision, drafting fans out again, and it all funnels back to one approval before anything leaves the business.

This mirrors what customers describe. Mark Halstead of Nitrobots.ai said that on 27 October a client proposal page and public ROI calculator went from request to live in one day, and that he approves what goes to prospects and what goes live. Individual results vary.

Parallel agents, serial humans

Agents can work side by side at no extra cost to your attention. People can’t. So a good plan maximises parallel agent work and minimises the number of times it needs a human, then batches those human moments together.

• Parallelise: research, data gathering, drafting independent sections, building separate artefacts.
• Serialise: anything that depends on a decision, anything that changes the same record, anything that goes out to a customer.
• Batch human moments: one pricing decision and one final approval beat six small check-ins spread over two days.

There are limits. Parallel work that writes to the same thing — two agents editing one document, or updating the same CRM contact — creates conflicts. The orchestrator should sequence those, even if it is slower. And parallel work only helps if the request is genuinely separable; a single nuanced letter is faster written once than assembled from parts.

Hand-offs without losing context

Most errors in multi-step work happen at hand-offs: the person who picks up the task doesn’t know what the last person knew. An orchestrator should hand over three things every time:

• What was done, with links to the outputs.
• What was decided, and by whom (“price approved at A$18,400 per month by Dana”).
• What is still open, including assumptions the next owner must check.

The same applies when work passes from an agent to a person. A hand-off to you should look like a good approval request: self-contained, with evidence, answerable from your phone. We cover that format in approval gates for AI agents.

The recap thread as the single record

Sessions reports back in the same conversation where you made the request. That sounds like a small design choice; it is a big one. The thread becomes the place where the request, the plan, every hand-off, every approval and the outcome live together, in order. When a colleague asks “where are we with Harbour St?”, the answer is a link, not a meeting.

For records that outlive the project — contacts, deals, next actions — the agents also write to the CRM, so the thread is the story and the CRM is the system of record. And across many requests, the daily summary pulls open items from every thread into one place; see the daily exception report.

Planning versus execution

A useful habit: for any big request, ask to see the plan before execution starts. It takes a minute to read a list of steps and owners, and it is the cheapest point to catch a misunderstanding (“no, we’re not doing the web page for this one”). For routine requests you have run before, skip it and let the plan run.

Plans should also be allowed to change. If the research agent finds that the tender requires a security clearance you don’t have, the right move is to stop and tell you, not to continue drafting. That is a stop condition at project level, and it is why a definition of done for each step matters — see how to write instructions for AI agents.

Coordinating across time zones and schedules

Orchestration also helps when the people involved aren’t online at the same time — a bookkeeper in Perth, an owner in Sydney, a supplier overseas. Agents keep working while people sleep, and the plan holds the human steps until the right person is available, then nudges them at a sensible local hour rather than at 3am. A simple rule is worth writing down: no approval requests to a person outside their working hours unless the item is marked urgent.

When you don’t need an orchestrator

Be honest about scale. If most of your requests are single tasks — draft this reply, file these invoices — a single capable agent and good briefs are enough, and an orchestration layer adds little you will notice. It earns its place when requests regularly involve research plus drafting plus a decision plus something going out, and when more than one person is involved.

Orchestration is one layer of what we call an AI execution layer; the bigger picture is in what is an AI execution layer. To see how Sessions plans, splits and reports a request in the chat thread, visit the Sessions page.