The Thursday question nobody could answer
A payables supervisor opens the invoice hold report on a Thursday morning and finds forty holds released overnight. Nothing about them looks wrong. The trouble starts an hour later, when the controller asks who released them and nobody can say whether it was the agent capability enabled a fortnight ago, a scheduled process, or a person on a shared role.
That is the failure mode to plan around. An agent doing something incorrect is an ordinary software problem with an ordinary fix. An agent doing something reasonable that nobody can attribute afterwards is a control problem, and it lands on the applications owner rather than the vendor.
The decisions below arrive in roughly this order whichever pillar you start in, and they are the same in ERP, HCM and supply chain. I am describing general controls rather than a feature inventory, because what exists and what it is called moves with Oracle's quarterly release cadence and differs by module. Confirm the specifics in your own environment, on your own release.
Pick a first task with an owner and an undo
The right first candidate has three properties. Somebody owns the task today and can be named in a meeting. The outcome can be reversed inside the same working day with a standard function, without a data fix request to your partner. And you already hold a number that describes how the task performs now.
Good candidates sit one step before a decision. Drafting the chase message for an overdue supplier confirmation. Proposing a coding for an expense line that a reviewer accepts or changes. Suggesting a match for a receipt that did not match automatically. A person still commits the result in every one of those.
The wrong first candidate touches the ledger or a payment with no human step. Posting journals, releasing payment runs, changing bank details, approving a hire or a pay change. Those come later, once you have evidence and a review habit. Start there and your first production incident is a financial one. If the estate is new to you, what Oracle Fusion Cloud actually is sets out the pieces you are scoping against.
The identity behind the agent is the real boundary
An agent acts through some identity. Depending on the capability and the release, that might be the signed in user, a dedicated account, or an integration identity that already exists for something else. Whichever it is, the access on that identity is the boundary. The question is never what the agent is supposed to do. The question is what it is able to do when it is asked the wrong thing.
So run the review you would run for a new joiner about to get access to financials. Pull the role assignments. Look at the data access, the business units and the ledgers it can reach, rather than the ones the demo used. If the identity can both create a supplier and release a payment, so can the agent, and your segregation of duties matrix has a row it does not cover.
Two things to settle with whoever configures this for you. Which identity appears in the record when the agent acts, and whether that answer holds across every module you plan to enable. Both vary. Both are answerable in a test environment in an afternoon, and neither is answerable from a slide.
Design the approval around the review someone can do
An approval nobody has time to perform properly becomes a rubber stamp, which is worse than no control because it produces a signature. Do the arithmetic first. Three hundred items a day reviewed by one supervisor between other work buys about twenty seconds of attention each, and twenty seconds buys a glance at an amount and a supplier name.
Design the step around that number. Review everything for the first few weeks while volume is small, then decide what stays under review on purpose. A value threshold. A random sample big enough to catch drift. Every item the agent marked as uncertain. Put the basis for the action on the same screen as the approve button, because a reviewer who has to open three pages will approve without opening them.
Then watch the approval rate, because it tells you whether the control is real. An approver who agrees with every item for six weeks is either supervising something that no longer needs supervision or has stopped reading. Only one of those is safe. The handoff between human and agent work is a design problem in its own right, better drawn before the first agent runs.
Afterwards you have to say who authorised it
Six months from now somebody will ask about one specific action. Which action the agent took, what it acted on, and under whose authority. If you cannot answer those three questions today for a test run in a lower environment, you are not ready for production. That test takes an hour, and I would run it first.
Check three things before you sign off. Whether the record distinguishes the agent from the humans, or everything lands under one service account that three integrations already share. Whether the input the agent acted on is retained anywhere, or only the outcome. How long it is kept, and whether you can export it in a form an auditor accepts. Retention and detail vary by capability and release, so ask your account team about agent execution telemetry directly.
Tell your external auditor before the first production run, not during fieldwork. Auditors mind surprises far more than they mind automation. The conversation is short when you can show the scope, the approval step and the record, and long when the first they hear of it is a population of transactions with no human initiator.
Numbers you did not capture first prove nothing later
Write down how the task performs before anything is switched on. Items per week, minutes each, how many come back wrong, how many land in a queue for a second look. Two or three numbers is enough, as long as somebody can reproduce them from a report you can name.
Without that baseline every later claim about benefit is unfalsifiable, including the ones you will make to your own steering group. Six months in, somebody says the agent saved the team a day a week, and nobody can confirm or deny it. Anyone who has sat through a metric nobody can reproduce twice knows how that meeting ends.
Give the affected team the same specificity. People rarely object to an agent drafting a message for them. What they want to know is what it does when it is unsure, and that is the conversation that helps. Say what happens at low confidence, who the item goes to, how fast, and what the person is expected to do with it.
Be honest about the effect on their day. If the agent clears the easy items, the queue left behind is denser and slower per item, so average handling time gets worse while volume falls. A supervisor who hears that from you in week one defends the change in week six.
Decide who can switch it off and how fast
Agree the exit in writing before the first production run. What the off switch is for this capability, whether that is a configuration change, a role removal or a support request. Who may use it at two in the morning without waking a director. How long it takes to take effect, and whether anything already in flight carries on afterwards.
Then rehearse it once in a lower environment and time it. A team that has switched it off on purpose will do it decisively at month end, while a team that has only read the procedure spends twenty minutes working out who owns it. Removing the role assignment is usually the fastest action available, one more reason to know which identity the agent uses.
Here is what I want in place before the first agent is enabled in production. If a line has no name against it, that line is the next thing you do.
- The named owner of the task, and the named owner of the agent configuration.
- The identity the agent acts through, with its roles and data access reviewed and written down.
- The approval step, sized against the daily volume and the time the reviewer actually has.
- The baseline numbers for the task, from a report you can name and rerun.
- Proof from a lower environment that you can reconstruct one action end to end.
- The off switch, who may use it, how long it takes, and the date you rehearsed it.
- A briefing for the affected team covering what the agent does when it is unsure.
