Oracle announced Fusion Companion and Fusion Agentic Home on October 26, 2026, describing a way for employees to state a business objective and have Fusion coordinate the transactions, workflows, approvals and agents needed to carry it out. The governance consequence is that workflow selection becomes part of what enterprise application owners need to evaluate, alongside the permissions on each individual action.
Oracle says the capabilities work within established enterprise controls. The announcement is a vendor description, not evidence of independently tested control effectiveness. It does not specify a dated general-availability schedule, pricing or universal customer eligibility for Companion.
What changes in the interaction
According to Oracle's announcement, Companion uses business context, data and user permissions to select and coordinate work. Supported AI tools such as ChatGPT can provide an entry point; Agentic Home supplies a native Fusion experience for delegation and progress tracking. Oracle also describes coordination with other enterprise systems and escalation of decisions requiring human judgment.
AgentsCalling's separate coverage highlights the unresolved rollout details and distinguishes Companion from the specialized agents doing the work. It has not independently tested the product. Naming ChatGPT does not establish access for every ChatGPT user or prove a particular integration protocol.
Maetra's analysis below concerns how an application owner could evaluate this objective-to-workflow design. These are proposed acceptance tests, not findings about Oracle deployments.
Review the selected workflow before measuring success
A useful evaluation begins with a narrowly defined business objective and a record of the workflow the system selects. The reviewer should be able to see which applications, agents and transactions were involved and why they were relevant to the request. A completed task alone offers little evidence about whether an unnecessary action occurred along the way.
For example, imagine a supply-chain employee asking for options to resolve a delayed order. This hypothetical task could permit analysis and preparation of a recommendation while reserving supplier changes for a separate decision. The evaluation should check whether the selected workflow respects that distinction. It should also show how the owner can discover that a new integration introduced another possible action.
Keep the test focused on the organization's actual authority model. Some permitted actions may run automatically; others may require review or be prohibited. Oracle's references to approval controls should not be interpreted as a promise that every step receives human approval.
Check the composed transaction
Several individually permitted steps can produce a result that exceeds the original request. Application owners should therefore test both component permissions and the final business effect. A workflow that changes a record, sends a message and triggers a downstream process needs a clear account of how those steps fit together.
A compact acceptance record could include:
| Test | Evidence to request |
|---|---|
| A request with two plausible workflows | Selected path, relevant context and resulting actions |
| A step outside the employee's authority | Refusal or escalation, with no unauthorized effect |
| Permission withdrawn during a long task | Observed behavior at the next consequential action |
| A repeated request after an interruption | Evidence of completed steps and handling of duplicates |
These are buyer questions. They do not imply that Oracle currently provides a particular log field, cancellation behavior or duplicate-prevention mechanism. Ask for the supported behavior and then inspect it in the configuration you intend to deploy.
Trace authority across system boundaries
Cross-system coordination adds another review point. When a workflow leaves Fusion for an outside application or agent, identify the acting identity, delegated authority and data sent across the boundary. Determine which system owns the resulting record and how an operator investigates a partial failure.
Start with a capability inventory that names the tools and transactions available to the selected workflow. Link each consequential effect to the policy that permits it and the evidence retained afterward. If the workflow can choose among several agents, verify how changes to that set are reviewed. A new route to the same business objective can alter the operational risk even when the user's words remain unchanged.
The deployment decision should rest on observed results for those boundaries and written answers to availability questions. A persuasive demonstration of the happy path is useful, but it cannot establish what happens when permission changes, a dependency fails or the request is repeated.
Oracle's announcement makes this a timely evaluation problem for Fusion application and platform teams. Before expanding delegated work, choose one objective, map its possible transactions and test the resulting authority boundaries. Maetra's documentation explains capability inventory and policy controls that can help structure that review. It does not establish an Oracle integration or replace the controls in the applications executing the work.