Every operator I talk to has the same setup: a CRM, an ERP, an accounting system, a support tool, a warehouse of some kind, and a layer of spreadsheets stitching the rest together. Every one of them has dashboards. Every one of them can see the problem. Very few of them have a way to do something about it without pulling a human off whatever else they were doing.
This is the gap. Not a visibility gap — an action gap. A dashboard is a mirror; it reflects the past back at you. The orchestration layer is the thing that takes the next step on your behalf — and, done correctly, shows you exactly what that step will be before it happens.
What “orchestration” actually means
The word gets used loosely, so here is the definition we work from. An orchestration layer does four things, every day, without being asked:
- Connect — reach into every system of record you already run (CRM, ERP, accounting, support, email, warehouse) and read from them in a consistent way.
- Watch — run always-on agents that look for the signals that actually drive revenue, cash, and customer risk.
- Decide — when an agent finds something worth acting on, it assembles a specific proposal: what should change, in which system, and why.
- Act — once a human approves the proposal, the change is written back to the source system with a full audit trail.
The fourth step is where most teams get nervous about AI, and they should. The next three sections are about why the middle steps — tools and proposals — are what make the last step safe.
What a “tool” is
When we say an agent has “tools,” we mean something specific. A tool is a declared, narrowly-scoped capability the agent is allowed to use. Something like query_opportunities, draft_followup_email, or propose_credit_memo. Each tool has a name, a description, and a strict schema for its inputs — no free-form calls, no shell access, no “just figure it out.”
The important part: an agent cannot do anything that isn't a tool. If you haven't declared a tool for sending wire transfers, the agent physically cannot send a wire transfer. Tools are the allowlist. They are the safety boundary, and they are also the vocabulary an agent has for thinking about the business.
How tools connect to systems
Tools are typed contracts between the agent and the outside world. Each tool knows three things: which system of record it touches (Salesforce, NetSuite, Zendesk, Gmail, your warehouse), what fields it can read or change, and whether the change is reversible. That metadata travels with every tool call.
Here's the subtle but critical design choice we make: agents do not execute tools directly against your source systems. They plan them. A tool call produces a structured proposal — a record of what the agent intends to do, with enough context for a human to evaluate it. That proposal is what lands in your queue. The source system doesn't see anything until a person approves.
“The model doesn't get the keys to the system. It writes a proposal. The human turns the key.”
The anatomy of a proposed action
Abstractions aside, here's what one of these proposals actually looks like. Imagine an agent is watching for stalled opportunities — open deals with no recent activity — and it finds one worth following up on. It drafts a personalized email using everything in the CRM and the prior email thread. The proposal looks roughly like this:
{
"action": "send_followup_email",
"target_system": "Gmail + Salesforce",
"summary": "Follow up with Harborline on stalled Q2 expansion",
"rationale": [
"Opportunity open 52 days, no activity in 18",
"Last thread: pricing question, unanswered since Mar 14",
"Account expanded seat count 2x in last 12 months — healthy signal"
],
"changes": [
{
"entity": "Email",
"action": "send",
"system": "Gmail",
"to": "[email protected]",
"subject": "Quick follow-up on the Q2 expansion pricing",
"body_preview": "Hi Dana — circling back on the question you raised on Mar 14 about tiered pricing above 250 seats. Here's what we landed on..."
},
{
"entity": "Opportunity",
"action": "update",
"system": "Salesforce",
"fields": { "last_activity_date": "2026-04-19", "stage_notes": "Re-engaged via follow-up email" }
}
],
"risk": "low",
"reversible": true,
"approver": "James Chen",
"audit_id": "act_2026_0419_0812Z"
}Notice what's in there. The email body is written out in full — the approver sees the actual message before it sends, not a summary of it. The rationale explains why the agent thought this was worth doing. The changes array lists every downstream edit, in every system, as a typed record. The approver is named. And every proposal has an audit_id that finance or ops can pull up six months from now when someone asks “why did we do this?”.
Why this is a safe way to automate with AI
The reason this approach works — and the reason we believe it is the right default for any business considering AI-driven automation — is that it inverts the usual worry about agents. The concern with AI acting on your business is that the model might do something unexpected. The answer is not to make the model smarter. The answer is to make sure nothing the model produces touches your systems until a person has seen it and said yes.
- Nothing happens without a named approver. Every proposal routes to a human who owns that kind of decision — the AE for outbound email, the support lead for case replies, the controller for anything touching the ledger.
- Every action is a structured record, not free-form model output. The agent produces JSON with a defined schema. Unstructured text is never sent directly to a system of record.
- Every edit is reversible or logged. The proposal declares whether it can be undone, and the audit trail captures who approved what, when, and on the basis of which data.
- Tools are an allowlist. The model cannot invent new capabilities at runtime. If a tool for a given action doesn't exist, the action cannot happen, full stop.
Three places this already pays off
Orchestration isn't useful in the abstract. It's useful because a lot of work inside a mid-market business is pattern-recognition plus a well-written message — exactly the kind of work an agent can propose and a human can approve in thirty seconds. Three examples where the payoff shows up first:
Opportunity follow-ups
A watcher runs nightly across the CRM looking for open opportunities that have gone quiet. For each one, an agent reads the account record, the past email threads, and recent activity, then drafts a personalized follow-up.
What the operator sees
The AE opens a queue in the morning with a dozen drafted emails, each with the reasoning and the full body visible. Approve, tweak, or skip. What used to be a “I should follow up with those accounts this week” task becomes ten minutes.
Support case resolution
An agent reads each inbound case alongside the customer's history and the internal knowledge base. For cases that match known patterns, it proposes a reply and any record updates (e.g. resetting a flag, adjusting an entitlement).
What the operator sees
The rep sees a drafted response with the reasoning and the referenced KB article. One click sends; one click hands it back. Tier-1 cases resolve in under a minute without sacrificing the human check.
Invoice & billing anomalies
An agent reconciles invoices against the underlying contract terms and received POs. When it spots a mismatch — the wrong rate applied, a missing discount, a duplicate line — it proposes the correction: a credit memo, a re-issue, or an adjustment.
What the operator sees
Finance sees the proposal with the contract clause, the invoice line, and the proposed correction side-by-side. The approver has the full justification before any adjustment touches the ledger.
How we think about building it
This is the approach we take at RevenuePoint. Agents watch. Agents propose. Humans approve. Systems execute. Every step is typed, logged, and reversible where it can be. It isn't the fastest possible way to let AI act on a business — that would be to hand it the keys — but it is the one that an operator, a controller, and an auditor can all live with. If you're thinking about where to start with AI in your own operation, that's the shape we'd recommend, regardless of whose software you use to get there.
