The temptation is understandable: give one AI agent access to sales, finance, delivery, customer success and the ERP, then ask it to “run the business.”
That is not orchestration. It is an unclear job description attached to an oversized permission set.
A better pattern is emerging. Certinia recently announced 14 purpose-built agents and an expanded library of 135 “Veda Intelligent Actions” across professional services, customer success and finance. The company says these actions can be called inside Certinia, Salesforce Agentforce, Claude, Microsoft Copilot and other tools through a headless architecture and MCP.[1]
The release is a useful signal, not a template every company should copy. The important shift is from one general assistant toward a library of narrow business capabilities.
For SME operators, that is the more practical way to move AI from chat to execution.
The omniscient-agent trap
A department-wide agent usually begins with a broad objective: improve operations, manage customers or help finance.
The problem appears when that objective reaches real systems.
Can the agent edit a customer record? Change a delivery date? Allocate stock? Post a journal? Cancel a transaction? Send a message to a customer? Approve a discount?
If the answer is “it depends,” then the agent does not have one job. It has dozens of jobs with different risks, data needs and approval rules.
That creates three operating failures.
First, permissions become difficult to reason about. An agent that needs read access for analysis may quietly receive write access because another part of its job requires action.
Second, acceptance criteria become vague. It is easy to say an agent should “manage the account.” It is much harder to prove whether it updated the correct fields, used current information, followed commercial policy and escalated the exception.
Third, recovery becomes messy. When one agent can touch several systems, operators must reconstruct which tool calls changed which records before they can reverse the right actions without damaging unrelated work.
A capable model does not solve these problems. Better reasoning can improve decisions, but it does not define authority.
Define the governed business action
A governed business action is one narrow capability with an explicit operating contract.
That contract should contain seven parts:
- Trigger: What event starts the action?
- Required context: Which records, definitions and evidence must be available?
- Permitted tools: Which systems can the action read or change?
- Decision boundary: What may the agent decide, and what requires a person?
- Deterministic checks: Which rules must pass regardless of the model’s reasoning?
- Evidence trail: What inputs, decisions, tool calls and outcomes must be recorded?
- Escalation owner: Who receives the case when the action cannot safely finish?
This is closer to a well-designed API operation than an open-ended chatbot prompt.
The model can still interpret unstructured information, compare options and propose the next step. But the surrounding action contract determines whether that proposal may become a business event.
Separate reasoning from transaction control
This distinction matters most when an agent approaches consequential systems.
Certinia’s announcement includes intelligent actions for posting, cancelling and reversing general-ledger transactions, allocating inventory, and generating or recognising revenue schedules.[1] Those examples show why “human in the loop” is not specific enough.
The agent may use probabilistic reasoning to classify a request, match supporting documents or explain an anomaly. The final transaction should still pass deterministic controls.
For a ledger posting, those controls might include a valid accounting period, balanced entries, permitted account combinations, mandatory attachments and approval above a value threshold.
For inventory allocation, they might include available-to-promise rules, customer priority, location constraints and a block on negative stock.
For revenue recognition, they might include contract status, delivery evidence, period rules and a named finance approver for exceptions.
Reasoning can recommend. Rules constrain. A person approves where judgment, policy or material risk demands it.
These are not competing approaches. They are different layers of the same operating system.
A practical SME example: closed-won to sales order
Consider a recurring handoff from CRM to ERP.
A salesperson marks an opportunity as closed-won. Today, an operations employee checks the customer, validates the quotation, confirms commercial terms, creates the sales order and asks finance to resolve any mismatch.
Do not replace that process with an agent that has broad access to “manage sales operations.”
Create one governed action: prepare sales order from approved opportunity.
Its trigger is a closed-won opportunity with an approved quotation.
Its trusted context package contains the customer identifier, quotation version, product lines, agreed prices, tax treatment, payment terms, delivery address and approval history.
Its permissions allow the agent to read the required CRM and ERP records and create a draft sales order. It cannot release the order, change the customer’s credit limit or override a price exception.
Its deterministic checks confirm that the customer exists in both systems, line totals match the approved quotation, required fields are present and no duplicate order already references the opportunity.
Its evidence trail records the source records, validation results, proposed ERP document number and any differences found.
Its definition of done is measurable: one non-duplicate draft order created with matching customer, items, quantities, prices and terms, plus a complete validation receipt.
If the data does not match, the action stops and routes the case to the operations owner. It does not “use its best judgment” to repair commercial terms.
That is a digital coworker with boundaries—not an unsupervised system administrator.
Compose actions without expanding every permission
Once one action is reliable, it can become part of a larger workflow.
The sales-order action can hand off to a credit-check action. A successful credit check can trigger an allocation action. Allocation can prepare a fulfilment request. Delivery evidence can later feed an invoice-preparation action.
Each action receives only the context and authority it needs. The workflow coordinates them; no individual agent needs unrestricted access across the full chain.
This is what “orchestrate, don’t operate” looks like in practice. The operator designs the jobs, boundaries, handoffs and proof. Digital coworkers execute within those constraints.
The architecture also makes improvement safer. A team can test a revised allocation action without changing the contract for ledger posting. It can replace a model without redefining who may approve a credit exception. It can pause one risky capability without shutting down every AI-assisted process.
Start with one handoff
The implementation sequence is simple, but not casual:
- Identify one recurring handoff with clear volume, friction and ownership.
- Write the action contract before choosing the model.
- Restrict permissions to the minimum reads and writes required.
- Test against real normal cases, edge cases and policy exceptions.
- Require a machine-readable evidence receipt for every run.
- Measure reliability, exception rate, cycle time and correction effort.
- Expand only after the action performs reliably inside its boundary.
Not every workflow should become agentic. Stable, deterministic processes may remain conventional automation. Low-volume, high-judgment decisions may remain human-led. The right target is work where AI reasoning adds value and the action boundary can still be governed.
The durable asset is not the number of agents on an org chart.
It is the library of governed business actions: reusable capabilities grounded in your data, shaped by your operating judgment, constrained by your policies and improved through evidence.
Build that library one action at a time.
Sources
[1] https://www.certinia.com/blog/certinia-unveils-system-of-action-for-services-and-largest-expansion-of-veda-ai-to-date — Certinia Unveils the System of Action for Services, and the Largest Expansion of Veda AI to Date