Field Manual · 14 min read

The Revenue Orchestration Field Manual

Every platform sells orchestration as a workflow builder. The actual job is deciding, task by task, what an agent can do alone, what needs a named human, and what the system of record must be able to prove afterwards.

What does orchestration actually mean in a revenue engine?

Orchestration is the phase where a scored signal gets an owner: a rule deciding whether an agent acts, drafts, or waits for a named human, before any workflow tool gets involved.

In the five phase model we use on every revenue automation engagement (see the five phase build), Orchestration sits between Signal and Scale. Foundation gets the data clean. Signal decides which accounts and moments matter. Orchestration decides who, or what, acts once that signal fires. Scale is what happens once the answer holds under volume, which is a separate problem we have written up on its own.

Most platforms sell Orchestration as a workflow builder: if this field changes, do that action. That is useful plumbing, and it is not the hard part. The hard part is deciding, for every action an agent could take, whether it is allowed to take it alone, draft it for a person to send, or stop and wait for a named approver. That decision is a governance question, not an engineering one, and it does not get easier by adding more connectors to the workflow builder.

We have written about pieces of this already: which tasks to keep out of an agent's hands entirely, in the rule for what not to automate; what changes once an agent is writing to the system of record; and why one trusted control room beats another dashboard nobody checks. This guide is where those three pieces become one framework, with the decision rights spelled out in one place instead of three.

What actually decides whether an agent acts alone or waits for a human?

Two variables: how reversible the action is, and how wide its blast radius is if it is wrong. Capability is not on that list, and treating it as if it is explains most stalled pilots.

We set out the test itself in the rule for what not to hand an agent: judge every candidate task on reversibility (can a mistake be undone before it compounds) and blast radius (how many records, people or relationships a mistake touches). A capable agent given an irreversible, wide blast radius task is not a readiness problem. It is a design mistake, made before the agent ever ran.

Gartner reached a close version of the same conclusion from the governance side. Its research, published 26 May 2026, found that applying one governance standard to every agent regardless of its autonomy produces two failure modes at once: over restricting simple, low risk agents slows delivery and pushes teams into unsanctioned workarounds, while under restricting agents that can act with real consequence raises operational, security and compliance risk. In Gartner's own words, Shiva Varma, the firm's senior director analyst, put it plainly: "Enterprises are treating AI agent governance as binary, either locked down or fully trusted." Gartner predicts that by 2027, 40 percent of enterprises will have to demote or decommission autonomous agents because the governance gap was found only after a production incident.

Translated into revenue terms: an agent drafting a renewal risk note is not the same shape of risk as an agent applying a discount exception. Governing them identically guarantees one of them is wrong, and it is usually the one with the wider blast radius that gets found out first.

What are the four levels of agent autonomy, and how do you assign a revenue task to one?

Observe, advise, act with approval, and fully autonomous, each a different trust boundary assigned by the reversibility and blast radius test, never by what the agent happens to be capable of.

Gartner's same research names four levels of agent autonomy, each a different trust boundary with its own governance requirement. Observe agents get read only access and surface findings to the person who asked. Advise agents draft a recommendation or a message and a human reviews and sends it. Act with approval agents can write, send or reconfigure, but only after a named person approves that specific action. Autonomous agents act inside a defined, bounded scope without a per action approval.

Most of what we run for clients sits at Observe or Advise, by design, which is also where our own delivery work runs. The portal behind our own client delivery exposes 25 agent tools through a permissioned MCP server, and every AI generated draft is reviewed by a named person before a client ever sees it. The morning sweep that reads client feedback drafts replies and books one bounded diary slot a day. It never sends. That is an Advise agent by design, not a cautious half measure.

Vendors are now shipping the lanes rather than leaving teams to improvise them. Gong's Revenue Harness, announced 24 June 2026 as part of its Mission Big Dipper release, lets a RevOps leader build agents in natural language that run with scoped data access, a full audit trail and configurable human oversight, without needing engineering support. That is a genuine advance, and credit where it is due: a RevOps leader who could not previously ship a governed agent without a backlog slot can now do it themselves. What the Revenue Harness does not do is tell a team which of its own tasks belongs in which lane. That policy is still the operator's job, and it is what the rest of this guide sets out.

What does a clean handoff from an agent to a human actually look like?

Four parts: the context that moved with it, a named receiver, a time bound to act, and a recorded reason it escalated. Missing any one, it is an output in a queue, not a handoff.

A handoff is not the moment an agent stops. It is a transfer with four parts: the context that moves with it, not just a notification that something needs attention; a named person who now owns it; a time bound inside which they are expected to act; and a recorded reason for why the task escalated rather than running to completion.

Our own drafting bench model is built around that shape deliberately. The morning routine behind our delivery portal drafts replies to client feedback and books one diary slot sized to the volume, between 20 and 45 minutes depending on how much came in overnight. It never sends. Approval chains and sign off stay with named people on both sides of the relationship. The one thing that actually broke in production was not the drafting, it was notification: client comments were not alerting anyone on our side until we checked, and fixing that mattered more than any feature we had planned. A handoff protocol is only as good as the path that tells a human it happened at all.

The direction of travel elsewhere in the market backs the same shape. Salesforce's Agentforce Operations, launched 29 April 2026, logs every action an agent takes against the process it followed, specifically so a team can review what happened in real time rather than reconstruct it afterwards. That is a vendor building the audit half of a handoff protocol as a standard product feature, which is a reasonable sign that the market has stopped treating "the agent handled it" as a sufficient answer on its own.

What does the system of record need to prove about every agent write?

Three things: which identity made the change, under what approval, and whether it can be reversed without manual archaeology. A shared service account cannot answer any of them.

We set this out in full in our piece on agents writing to the system of record: the old audit trail assumed one human made one change, so logging the account that made it was enough. That assumption breaks the moment several agents and several humans write through the same service account. The system of record needs to answer three questions about any agent written field: which identity actually made the change, under what approval it was made, and how it gets reversed if it was wrong.

This is a reversibility problem before it is a logging problem. A field you can audit but cannot cleanly revert is still a liability, just a well documented one. It is also why Level 3 and Level 4 agents, the ones that write or act without a per action approval, are exactly where this matters most: Observe and Advise agents never touch the field in the first place, so the identity question does not arise.

Build this into the system of record itself, not into a dashboard that sits beside it. A log that lives outside the record it describes gets out of date the first time someone edits the record directly, which in our experience across several of these rollouts is usually within the first month.

Where does all of this actually get operated day to day?

In one control room with a named owner, not scattered across a workflow tool, a CRM view and a chat channel. The decision rights above are rules the control room enforces, not just displays.

We have argued elsewhere that most of what gets called a command centre is a dashboard nobody fully trusts, built in the order of excitement rather than the order that actually works: connect everything first, then figure out governance. That order produces exactly the ungoverned agent sprawl Gartner is now measuring.

The build order that holds is the reverse. Name who owns the control room before connecting a second system to it. Decide the decision rights above before any agent gets write access. Only then wire the agents in, at the level their task earns, with the control room as the one place approvals, audit trail and escalations are visible together. A control room that only shows what happened is a dashboard. One that enforces what is allowed to happen next is orchestration.

This is also where the Salesforce and Gong platform features above actually belong. An audit trail or a scoped agent builder is a component. The control room is where a named human can see every component at once and tell, in one screen, whether the decision rights are being followed or quietly drifting.

What is the build order for a revenue orchestration framework?

Name an owner, write the reversibility test into the system, map every live agent task to a level, define the handoff contract, wire the audit requirement in, then review monthly.

In our own engagements this runs in six steps, in this order, because doing it out of order is the most common way a team ends up governing agents after an incident rather than before one.

1. Name one decision rights owner. Not a committee, and not whoever configured the tool. One named person approves which tasks move up a level, the same way a schema owner approves a field change.
2. Write the reversibility and blast radius test into the system, not the prompt. A rule a prompt can talk its way around is not a control. It needs to sit in the permission layer the agent actually runs through.
3. Map every live or proposed agent task onto one of the four levels. Do this task by task, not agent by agent. The same agent can sit at different levels for different tasks.
4. Define the handoff contract for everything above Observe. Context, named receiver, time bound, recorded reason. Write it down before the first live handoff, not after the first missed one.
5. Wire the identity and audit requirement into the system of record before scaling volume. Retrofitting this after an agent has made thousands of writes is materially harder than building it first.
6. Review the mapping monthly, not quarterly. Agent capability moves faster than most governance cycles, which is the same gap Gartner's research is measuring at the enterprise level.

Frequently asked questions

What is revenue orchestration?

Revenue orchestration is the phase of a revenue engine that decides who or what acts once a signal fires: whether an agent handles a task alone, drafts it for a person, or waits for approval, and what the system of record needs to prove about the result.

Who should own agent decision rights in a revenue team?

One named person, not a committee and not whoever configured the tool. The role mirrors a schema owner: they approve which tasks move up an autonomy level, and every exception goes through them, not around them.

What is the difference between automation and orchestration?

Automation moves work along a predefined path. Orchestration decides, task by task, whether an agent is allowed to take that path alone, needs a human to approve it first, or should not be automated at all.

How do you decide when a task is ready to move up an autonomy level?

Check reversibility and blast radius, not how well the agent has performed so far. A task only moves up a level once a mistake at that level is cheap to undo and narrow in who it affects, regardless of how confident the agent's output looks.

Does trusting an agent at one autonomy level mean trusting it everywhere?

No. Autonomy is assigned per task, not per agent. The same agent can run fully autonomously on a reversible, narrow task and require approval on an irreversible one inside the same workflow.