An agent can produce an impressive demonstration without improving the operation around it. A service response still needs to reach the customer. An updated record still needs to be correct. A completed task still needs to cost less, or create more value, than the process it replaces.
For leaders deciding where to invest next, we suggest starting with a narrower question: which piece of work can we improve, how will we recognise success, and who will own the result?
What the research adds
BCG’s September 2026 Applied AI Index surveyed more than 1,300 executives and senior leaders. Its article reports that 42% of companies expect to give agents autonomy by 2030, while only 5% have its full set of critical controls in place. These are BCG’s findings about its sample, not Emerge results or a forecast for an individual business. Read BCG’s research and methodology context.
The practical approach below is Emerge’s perspective on implementation: make the unit of delivery small enough to inspect, and the ownership clear enough to act on what you learn.
Give every agent
a business outcome.
- Choose the work
One workflow. One accountable owner.
- Define the boundary
Approved data, actions and escalation.
- Prove the result
Quality, service and cost per outcome.
- Earn the next step
Expand only when the evidence holds.
Choose a workflow you can actually finish
Write down the trigger, the final business action and the person responsible for exceptions. “Improve customer service” is too broad for a first release. “Prepare a response to an order-status enquiry using an authenticated customer record, with a person approving the reply” is specific enough to test.
Before building, examine a representative set of real cases. Include the awkward ones: incomplete records, conflicting policies, duplicate customers and requests outside the normal process. Record the current handling time, rework and customer outcome. An average from the easiest cases will create an unreliable comparison later.
Use a short workflow brief:
- Outcome: the customer or operational change you want to see.
- Baseline: current volume, completion time, quality and cost.
- Authority: what the agent may read, propose and execute.
- Exceptions: what requires a person, and where that person receives the work.
- Owner: the role accountable for accepting or stopping the release.
Give autonomy an explicit boundary
Separate retrieving information from changing a business system. An agent that can find an invoice does not automatically need permission to alter it. A tool that prepares a refund should not quietly gain the ability to authorise one.
Start with the least authority needed to test the workflow. Use distinct read and write permissions, approved destinations, action limits and a record of what was attempted. Make retries safe: repeating a request must not create duplicate orders, bookings or payments.
Decide how staff will intervene before launch. They need enough context to understand an escalation, a way to stop further actions and a known recovery procedure. Reviewers also need time in their workload; an approval queue without capacity is another operational bottleneck.
For a business operating across the UAE and Australia, include language, operating hours, data location and cross-border access in the design review. Validate the requirements of the specific organisation and engagement rather than assuming one deployment pattern fits both markets.
Measure the whole cost of an accepted outcome
Model usage is only one line in the operating cost. Include retrieval, third-party tools, runtime, monitoring, human review and remediation. Track retries and failed attempts against the workflow that caused them.
A worked planning example — hypothetical, not a client result: suppose a process handles 2,000 cases a month at an average handling cost of AED 30. Its baseline is AED 60,000. A proposed assisted process might budget AED 24,000 for human handling, AED 6,000 for technology and AED 8,000 for operation and review. That totals AED 38,000, leaving a modelled AED 22,000 monthly difference before implementation costs.
That difference is not automatically cash saved. If staff remain in the same roles, the benefit may be capacity available for other work. Report that separately from reduced expenditure. Reject the business case if lower cost comes with unacceptable errors, repeat contacts or poorer service.
Use actual measured values to replace the assumptions. Agree in advance how long the observation period must be, and which quality failures would stop expansion.
Keep the operating model independent of the vendor
Choose technology after the workflow requirements are clear. Compare your existing business platforms and cloud services against the same criteria: identity, data access, action controls, evaluation, observability, latency, cost and exit options.
AWS, Azure, Google Cloud and Cloudflare can be considered within that assessment alongside application-native and open-source approaches. Technology independence does not mean every product is interchangeable. It means documenting why a particular combination fits, which dependencies it creates and what would be required to change it.
Keep the workflow specification, evaluation cases, ownership records and cost reporting portable wherever practical. Those artefacts make a future platform decision easier to assess than a collection of prompts without operational context.
Start where the work is concrete
These are illustrative starting points, to be validated against the organisation’s systems and policies:
| Industry | A bounded first workflow | A result to measure |
|---|---|---|
| Retail and commerce | Prepare an order enquiry response from verified order and delivery records | Correct resolution, repeat contact and handling cost |
| Financial services | Assemble supporting documents for a human-led review | Completeness, review time and exception quality |
| Real estate | Qualify an inbound enquiry and prepare an adviser handoff | Handoff accuracy and time to an appropriate response |
| Professional services | Draft a project brief from approved discovery notes | Review effort, factual corrections and brief acceptance |
| Government | Classify a request and propose the responsible service team | Routing accuracy, accessibility and escalation quality |
| Technology and software | Prepare a support investigation from approved logs and documentation | Useful diagnoses and time to human resolution |
Release in stages, with a decision at each one
Observe: run representative cases through the proposed process without allowing production changes. Compare the outputs with the existing process and investigate failures.
Assist: put the output in front of the people doing the work. Record corrections, review time and whether the assistance is useful. Keep the existing fallback available.
Delegate selectively: permit a limited class of approved actions after the earlier evidence supports it. Monitor the same measures, with explicit limits and escalation. Expand the scope only when the owner accepts the results.
The next release may need better data, a simpler policy or a different handoff rather than a more capable model. Let the observed failure determine the next investment.
Bring one workflow to the conversation
Emerge connects strategy and transformation, agentic AI and automation, data and intelligence and security and governance.
Bring an example of the work, the systems involved and the outcome you want to improve. We can use that conversation to identify the baseline, dependencies and decisions needed for a scoped next step.