Platform
Govern AI-driven workflows
A workflow that involves AI still reaches production systems at the end of it. Governance applies at every step rather than once when the work begins.
Governed per step
Steps in the run
8
That reach out
2
Only the steps that touch a system of record are governed. The reasoning steps are not, because reasoning changes nothing.
The governance question
Not whether the workflow was approved. Which step was.
Almost every workflow tool checks once, at the trigger, when a person started the work. Then it runs eight steps, and the last one writes to a ledger. The authorization has been stretched over a sequence it never described.
This is the same claim execution control makes about a single call, at a different scale. There the failure is an action widening between the check and the send. Here it is a step appearing between the approval and the write — and the second is harder to see, because every individual step looks reasonable.
So governance attaches to the steps that reach out, not to the trigger. A reasoning step is not governed, because reasoning changes nothing. A step that posts a journal entry is governed at that step, against that entry.
Three ways a start-of-workflow check stops being true.
None of these need anything adversarial. They are what happens to sequences that retry, look things up, and get extended by a different team six months later.
- The approval was for step one
- A person authorised beginning the work. Eight steps later something writes to a ledger, and nobody asked about that specifically — the authorization has been stretched over a sequence it never described.
- The data changed underneath
- A lookup between the check and the write returns something different from what was checked. The amount that was approved and the amount that executes are the same variable and not the same number.
- A step was added later
- Workflows accrete. The one governed six months ago has two more calls in it now, and the governance was attached to the trigger rather than to the steps.
One run, end to end
An invoice arrives, and eight steps later money is scheduled to move.
The reference workflow from the sample estate. Two of these steps reach a system of record and are governed individually; the rest are the workflow doing its job, which OpsAI has no view on.
Accounts payable, one run
8 steps · 2 governedInvoice arrives
A supplier invoice lands. Nothing has run and nothing has been decided.
AI analysisap-invoice-agent
An agent reads the invoice, extracts the amount and matches it to a purchase order.
Data lookup
The vendor record is fetched — itself an authorized data request, not a free read.
Policyevaluated as code
payout.dual_control applies. It is evaluated here, at the action, rather than once when the workflow began.
Risk
The amount is above the dual-control ceiling and the payee is newly created, so this scores high.
Approvalheld
Held for a named co-signer in Finance. Thirty minutes, after which it expires rather than proceeding.
Enterprise actionRazorpayX
Only now does money move, and the policy travels with the call so it cannot widen in flight.
Audit
Every step above is in the record, including the thirty minutes it waited and who signed.
Who is running this.
- The orchestrator
- ap-invoice-agent, built with CrewAI, answering to Rahul Menon in Finance.
- The delegated step
- The payout is handed to payout-runner, which holds a subset of its parent's authority and runs at level 4 — unattended, watched, breaker armed.
- What it may attempt
- post.journal_entryinitiate.payout
- Not an orchestrator
- Temporal, n8n, Airflow, CrewAI and hand-written schedulers keep running the sequence. OpsAI is not in the control flow and has no opinion about retries, fan-out or state machines.
- Governed at the steps that reach out
- A step that thinks is not governed. A step that writes to a system of record is, and it is governed at that step rather than at the trigger.
- One record per step, one thread per run
- Each governed step seals its own evidence, and the records chain into a single readable trail for the whole run. A workflow is auditable as a unit without losing the resolution of individual decisions.
Workflows in the estate
Every orchestrator is a sequence somebody has to be able to read.
An orchestrator is the shape that most often hides a governance gap, because the interesting step is rarely the one that was reviewed. These are the ones in the sample estate.
- refund-resolverLangGraph
- issue.refund
- close.ticket
Priya Nair · L3
- ap-invoice-agentCrewAI
- post.journal_entry
- initiate.payout
Rahul Menon · L2
- payout-runnerHand-written (Python)
- initiate.payout
Rahul Menon · L4
- vendor-onboardTemporal workflow
- create.vendor
Anita Rao · L3
Orchestrators
4
running sequences
Delegating
2
a step handed to a child
Policies applied
8
at the steps, not the trigger
Decisions
240
sample estate, 24 hours
IllustrativeThe OpsAI sample estate. Every agent and what it was built with.
One step, in detail
Execution
What happens at the boundary of a single call, and why the bound travels with it.
One run, recorded
Traces
Each governed step seals its own record, and the records chain into a readable trail for the whole run.
When a run goes wrong
Incidents
A pattern of refusals mid-sequence stops the agent rather than continuing to refuse it one step at a time.
Where to start
Find the last step in your longest workflow.
Whatever writes at the end of it is the step that matters, and it is almost never the step that was reviewed. Governing that one first gives you more than governing the trigger ever will.