An AI agent can look excellent in a demonstration.
It reads an email, checks a spreadsheet, updates a CRM record and drafts a reply. The room nods. The workflow appears ready.
Then production starts.
The customer record is duplicated. The inventory figure is stale. A discount falls outside policy. Nobody knows whether sales, operations or finance owns the exception. The agent did not create those problems. It exposed a workflow that was never ready to carry delegated action.
That is the gap operators need to close.
The milestone is not a working agent. The milestone is a workflow that remains dependable when the agent encounters incomplete data, conflicting instructions, unusual cases and actions that need to be reversed.
The scaling numbers point to an operating problem
An Infosys–HFS report based on more than 500 Global 2000 enterprises found that 14% had reached the scaling stage for agentic AI, while 16% reported enterprise-wide deployment. The two measures describe different aspects of adoption, so they should not be collapsed into one statistic.[1]
The same report found that 60% of respondents said their most advanced agents still performed rules-based tasks rather than autonomous decision-making. It also reported that 44% cited data and infrastructure gaps, only 16% had real-time data availability, and 12% were comfortable granting agents broad access to sensitive enterprise data.[1]
Those findings do not describe every company, and they should not be treated as an SME benchmark. They do reveal a useful pattern: building the agent is only one part of the work.
Smaller organisations feel this quickly. One person may own customer service, approve discounts and fix the CRM. Data definitions often live in people's heads. Exceptions move through WhatsApp or email. A broad permission granted for convenience can affect several systems at once.
The answer is not to wait for a perfect organisation. It is to put a readiness gate in front of autonomy.
The seven-part SME readiness gate
Before an agent can change a record, send a message, approve a transaction or trigger another system, check seven things.
1. Name the outcome owner
Every agent-enabled workflow needs one human owner for the business outcome.
Not the model owner. Not the software vendor. The person accountable for what the workflow produces.
For a sales-quotation agent, that might be the sales operations lead. For invoice matching, it might be the finance manager. The owner defines acceptable outcomes, resolves policy conflicts and decides when the workflow needs to stop.
If several departments can veto the result but nobody owns it, the agent will make the confusion move faster.
2. Identify trusted data
List the records the agent may use and identify the source of truth for each important field.
Which system owns the customer address? Which inventory figure is current? Where does the approved price list live? How fresh must the information be before the agent can act?
Do not ask the agent to reconcile organisational disagreement silently. When two systems conflict, route the case to an exception queue.
3. Bound the permissions
Useful agents do not need broad access by default.
Separate read, recommend and write permissions. Limit the systems, fields, transaction values and time windows the agent can touch. Give it the minimum authority required for the current stage.
A customer-service agent may read order status and draft a response without changing a refund. A procurement agent may prepare a purchase-order recommendation without submitting it. Narrow authority is an operating design choice, not a lack of ambition.
4. Build the exception queue
Normal cases make demos look good. Exceptions determine whether the workflow survives.
Define what sends work to a human: missing data, policy conflict, low confidence, unusual value, duplicate record, unavailable system or customer complaint. Each exception needs an owner, a response target and enough context for a person to decide without reconstructing the whole case.
The queue is also where the organisation learns. Repeated exceptions show which policy, data field or workflow step needs repair.
5. Set approval thresholds
Human-in-the-loop control should not mean a person approves every click forever.
Place approval at the points where mistakes become expensive, difficult to reverse or visible to customers. A draft internal note may need no approval. A discount above a set percentage, a supplier change or a customer-facing refund may require one.
Write the thresholds down. Otherwise “human oversight” becomes an informal promise that disappears under pressure.
6. Define the rollback path
Before the agent writes, decide how the action will be reversed.
Can a CRM field return to its previous value? Can a purchase order be cancelled before transmission? Is the original record preserved? Who can trigger rollback, and how quickly?
An audit log explains what happened. A rollback path gives the operator something to do about it. Production readiness needs both.
7. Measure the business outcome
Do not measure success by the number of agent actions.
Track the result the workflow exists to improve: quotation cycle time, first-response time, invoice exceptions, order accuracy, stockout frequency or cases resolved without rework.
Also track correction cost. If the agent completes more tasks but creates a larger review burden, it has moved work rather than removed it.
Move from observation to bounded execution
Consider an SME that receives supplier invoices by email and matches them against purchase orders in its ERP.
In the observe stage, the agent reads invoices, finds the likely purchase order and logs what it would do. It changes nothing. The finance team compares its proposed matches with real decisions.
In the recommend stage, the agent prepares the match and explains discrepancies. A finance operator approves or corrects it. Those corrections expose missing rules and weak data.
In bounded execution, the agent posts only exact matches below a defined value, from approved suppliers, with complete records. Price differences, duplicate invoice numbers, missing receipts and high-value items enter the exception queue. Every write is logged and reversible.
That progression is slower than granting full access on day one. It is much faster than recovering from an agent that confidently acted inside an undefined process.
Readiness is the real deployment decision
The point of a readiness gate is not to stop agent adoption. It is to make the next level of autonomy earned and inspectable.
A small company does not need enterprise bureaucracy. It needs a named owner, trusted inputs, narrow authority, visible exceptions, explicit approval points, a rollback path and an outcome worth measuring.
Before the next agent goes live, ask three questions:
- Who owns the exception?
- How do we reverse the action?
- Which business outcome will prove this works?
If the organisation cannot answer all three, the workflow is not ready for agent autonomy.
Build that readiness first. Then let the agent execute.
Sources
[1] https://www.infosys.com/newsroom/features/2026/enterprises-scaled-agentic-ai.html — Infosys–HFS Report Shows Only 14% of Enterprises Have Scaled Agentic AI