A pilot shows what an agent can do. A business needs to know what it may do, who owns the result, and what happens when the work goes wrong.
Those are different tests. Giving more people access to an agent does not, by itself, create a dependable operating capability. Connecting more tools can extend its reach without making its decisions more accountable.
The useful question is not “How many agents can we deploy?” It is “Which workflow can we operate responsibly, and what evidence would justify extending it?”
Rollout is not the same as value
Two recent announcements help make the distinction concrete.
On October 22, 2026, Uber announced a company-wide rollout of ChatGPT Work, supported by approved integrations, an internal skills library and employee training. Uber said it planned to share further insights into adoption, use cases and measurable outcomes as the rollout progressed. The announcement describes an expansion of access and its supporting practices; it does not establish realized return on investment.
On October 26, 2026, Oracle described new agentic capabilities across Fusion Applications, emphasizing business context, permissions, approvals and organizational controls. These are Oracle’s descriptions of its products, not independent evidence of customer results.
Neither announcement proves a universal formula for scale. Both illustrate an important distinction: an agent’s capability and the conditions under which an organization lets it work are separate design decisions.
Make the workflow the unit of scale
For this discussion, agentic AI means systems that can plan and take multi-step actions using tools within defined permissions. The agent participates in a workflow. It does not inherit accountability for that workflow’s business outcome.
Start with one piece of work that matters to a customer, employee or business owner. Define where it begins, what an acceptable result looks like and where responsibility changes hands.
Consider an illustrative purchase-request workflow—not a client case. An employee asks for software. An agent gathers the request details, checks approved information and prepares a requisition. A person with the appropriate authority approves the spend. An exception, such as an unclear supplier or an unusual data requirement, goes to the responsible reviewer rather than being resolved through a plausible guess.
The design is more useful than a broad promise to “automate procurement.” It identifies the work, the information the agent may use, the point where it must stop and the person who remains responsible.
A workable definition should answer:
- Outcome: What completed result does the requester need?
- Owner: Who is accountable after the pilot team moves on?
- Context: Which records, policies and tools are approved for this task?
- Authority: Which actions may the agent take, and which require approval?
- Recovery: Who handles exceptions, incorrect actions and failed handoffs?
Illustration description
Illustrative purchase-request example. Five numbered stations in sequence: 1 business outcome and owner; 2 approved context and tools; 3 bounded agent action; 4 approval or exception handling; 5 recorded result. A dashed path labelled 'Escalate to a human' runs from the bounded agent action to the owner. A solid path labelled 'Feedback to the owner' returns from the recorded result to the owner. Conceptual illustration only, not a deployed system.
Set action boundaries before adding autonomy
Access to information is not permission to change it. Permission to prepare a transaction is not permission to commit it.
Distinguish three roles when designing the workflow:
- Recommend: Suggest a next step, with supporting evidence for review.
- Prepare: Assemble a draft action or transaction that an authorized person must approve.
- Execute: Carry out an action only within explicit authority and applicable controls.
These are options for particular tasks, not stages every organization should climb. An agent might prepare a purchase request but never approve the spend. Another might execute a narrowly defined internal update while escalating anything outside its permitted scope.
Illustration description
Three equal, independent cards inside one dashed shared policy and permission boundary. Recommend suggests an option and a person decides and acts. Prepare drafts an action that waits for approval. Execute acts only within explicit authority set for that workflow. Each is chosen independently for each workflow; they are not a ladder and no option leads to another. Dashed escalation lines run from every card to a human owner.
Make the boundary enforceable in the systems and tools, not just a sentence in the prompt. Specify permitted data and actions, approval conditions, logs and escalation routes. Check what happens when the needed information is missing or conflicting.
Use deterministic checks where a rule can be tested directly—for example, whether required approval exists before a transaction proceeds. Such checks can reduce specific risks. They do not make the entire workflow risk-free.
People also need a clear way to challenge a result and get help. Training should cover when to use the agent, when not to use it and how to report a problem—not only how to write a better request.
Ask what earns the next expansion
Before the pilot expands, agree on the evidence that will support the decision. ENTAISI’s recommendation is a workflow scale gate: a short review of the work, its controls and its economics. This is decision guidance, not a certification or an industry standard.
Start with a baseline for the existing workflow. Then evaluate the assisted version against the same definition of an acceptable outcome. Faster output is not an improvement if someone else must spend more time correcting it.
The review should cover:
- Outcome quality: Is the result accurate, complete and usable for the task?
- Exceptions and rework: What requires correction or human intervention, and why?
- Authority and recovery: Do permission boundaries hold, and can the team detect and recover from a failed action?
- Full delivery cost: What do models, tools, infrastructure, human review, rework and support cost relative to accepted outcomes?
- Operational ownership: Who maintains the workflow, updates its context and acts on feedback?
Choose acceptance criteria appropriate to the workflow and its consequences. There is no single accuracy target or cost threshold that makes every agent ready for production.
Illustration description
A review sequence: 1 baseline; 2 evaluate outcomes and full costs; 3 review exceptions and recovery; 4 decide. The decision leads to three equally weighted options. Expand: a new scope needs its own review before work extends. Revise: adjust and re-test; a dashed path labelled 'Re-evaluate after revision' returns to evaluating outcomes and full costs. Stop: end or pause; the path visibly ends. No values or thresholds are shown.
Expansion is a decision to take responsibility for more work, not simply to give more people a login.
A useful review can conclude “expand,” “revise” or “stop.” All three can be sound decisions. Stopping an unsuitable workflow is better than scaling an attractive demonstration that cannot earn its operating cost or meet its control requirements.
Reuse the pattern, reassess the scope
Once a workflow earns expansion, reuse what is dependable: approved integration patterns, evaluation methods, escalation routes and ownership practices.
Do not assume the next team has the same permissions, data quality or consequences of error. Review the new scope before extending authority. A pattern that works for preparing an internal request may be inappropriate for committing money or changing customer records.
The next move can be small and concrete: choose one pilot, name its business owner and document its permitted actions, exception path and evidence for expansion. Bring the people responsible for delivery, data, risk and cost into that review.
Scale begins when the organization can explain not just what the agent does, but how the work remains accountable.
Source note: The Uber and Oracle announcements describe their own rollouts and products; they are not independent evidence of realized ROI. The purchase-request example and diagrams are illustrative. The scale gate is ENTAISI editorial guidance.