What Oracle AI Agent Studio is, and who is already using it
Oracle AI Agent Studio is where Oracle Fusion Cloud customers and partners create, extend, test and deploy AI agents and agent teams. Oracle announced it on 20 March 2025 at CloudWorld London, on top of the more than 50 agents it had already embedded in Fusion Applications, and made it available at no additional cost. On 15 October 2025 Oracle added the Fusion Applications AI Agent Marketplace for partner-built agents, and on 24 March 2026 it added an Agentic Applications Builder, multi-step orchestration "with rules that control how work moves between steps, built-in logic, and human oversight," and ROI reporting per agent.
That makes it the default agent platform for a very large installed base of US enterprises that already run finance, procurement and HR on Oracle Fusion Cloud ERP. Oracle says more than 63,000 certified experts have been trained on it. If your company runs Fusion, Agent Studio is already in your tenancy, and somebody on your team is probably building with it.
The question this page answers is narrow and practical. When an Oracle AI agent can reach money, which controls actually stop a bad payment, and where do they stop working? We went to Oracle's own API specification rather than the brochure, and we credit Oracle where its controls are real, which is more often than with most vendors in this series.
Oracle AI agents that touch money today
Oracle ships finance agents whose documented work runs right up to payment. The Payables Agent, enabled by default from release 26B, ingests invoices from email, portals, EDI and PDFs, extracts and matches them to purchase orders and receipts, and takes them, in Oracle's words, "from capture to payment readiness." The Payments Agent, in early adoption from 26A, evaluates dynamic discounting, virtual card and supply chain finance options, drafts offers to suppliers and automates payment scheduling and submission. The Quote to Purchase Requisition Agent turns emailed supplier quotes into requisitions.
Then there are the agents you build. Agent Studio gives a custom agent an External REST tool that can call any live API, and since release 26A an MCP tool that connects to external MCP servers "without building additional REST wrappers." That is the line that matters for finance. A custom agent with an MCP tool pointed at a payment MCP server such as Stripe's, or a REST tool pointed at a card issuer or an ad platform, can move money that never becomes a Fusion document.
Partner agents sit in between. The Marketplace launch named an Infosys invoice collection agent powered by Stripe that handles invoice payment processing and reminders. Each partner agent brings its own tools and its own reach into outside systems.
Where Oracle's controls are real, and we mean it
Oracle deserves more credit here than most platforms we have measured, and it would be misleading to say otherwise.
First, Oracle's own money agents keep a person in the decision. The 26A documentation for the Payments Agent says draft recommendations, offers and schedules "always require user review and confirmation before any action is taken," and that the assistants "operate within your existing security, approval, and segregation-of-duties framework and do not bypass access controls or validations." The Payables Agent routes exceptions to people who cancel, correct or release them. Neither is an autonomous payer.
Second, anything an agent creates as a Fusion document meets Fusion's controls. A requisition an agent drafts goes through your requisition approval rules. If you run Budgetary Control, it gets a funds check. The Procurement API models this in detail: a requisition carries BudgetaryControlEnabledFlag, FundsStatus, InsufficientFundsFlag and FundsOverrideApprover. That is an enforced money control, and it applies to agent-created documents the same way it applies to human ones.
Third, Agent Studio workflows can include checkpoints and approvals between steps, which Oracle has promoted since the 2025 launch. So the honest summary is that Oracle governs spend very well wherever spend takes the form of an Oracle document.
How we measured what the Oracle agent API can express
We use the same method on every vendor in this series: read the machine-readable model the vendor publishes, run two vocabulary passes over it, then run the same passes over a part of the same vendor's model that obviously handles money, so we know the method can see money when it is there. Oracle makes this easy, because it publishes a full OpenAPI file for every Fusion REST API on docs.oracle.com with no login. Everything below was downloaded and run on 21 September 2026.
The agent surface is in the REST API for Common Features in Oracle Fusion Cloud Applications, release 26C, spec version 2026.08.27 (4,455,301 bytes). It contains every operation under the Fusion AI orchestrator: the A2A agent card at /.well-known/agent.json, agent search, the JSON-RPC endpoint that handles tasks/send, message/send and tasks/get, message streaming, and the agent team invokeAsync and status calls. That is 7 operations. Following every schema they reference gives 39 schemas carrying 215 properties.
The controls are the Financials REST API (version 2026.08.27, 96.5 MB) and the Procurement REST API (version 2026.08.06, 77.8 MB) from the same release. The money pass looks for amount|currency|budget|spend|price|cost|payment|invoice|monetary|dollar|purchase|limit|funds. The scope pass looks for merchant|vendor|supplier|counterparty|allowlist|approval|threshold|daily|monthly|cumulative|aggregate|payee|ceiling|max.
The claim this supports is precise. It is about the agent contract Oracle publishes, not about what a customer could configure with custom fields or flexfields, and not about the Fusion documents an agent may create.
The finding: 215 agent properties and not one is an amount
Across all 215 properties in the Oracle agent API, the money pass matched one, and it is a false positive: CollectionIdentity.limit, the maximum number of records a list call returns. The scope pass matched zero. There is no budget on the agent card, no amount on a task, no currency on an invocation, no supplier or counterparty anywhere in the agent contract.
The closest thing to a control in the typed fields is invocationMode, an enum with exactly two values, ADMIN and USER, which sets whose privileges the run uses. That is an access control, and a sensible one. It cannot express "this agent may spend 5,000 dollars a month with these four suppliers and anything above 1,000 needs the AP manager."
The configuration objects tell the same story from the other side. workflowConfig, agentConfig, toolsConfig and llmConfig are all declared as untyped objects that accept any keys, and parameters on an agent request is free-form. So an amount can travel through an Oracle agent run as an opaque value, and nothing in the published contract types it, totals it or refuses it. The same is true of the A2A agent card Oracle exposes to outside agents: it advertises name, skills, capabilities and authentication schemes, and nothing about what the agent may spend.
The control worked, so the zero is real
A zero from a regex only means something if the same regex fires hard on money elsewhere in the same vendor's model. It does. In the Financials API, 9,466 of 94,736 properties matched the money pass, spread over 3,137 of 8,792 schemas. A single Payables invoice response matched 30 of its 101 fields, including InvoiceAmount, AmountPaid, InvoiceCurrency and ControlAmount. A payment response matched 30 of 88, including PaymentAmount and BankChargeAmount. In the Procurement API, 4,803 of 74,444 properties matched across 1,598 schemas.
That is roughly one property in ten in Financials and one in fifteen in Procurement, against one in 215 on the agent surface, and that one is pagination. Oracle models money in extraordinary depth wherever a document carries it. The agent contract is where it is absent, and on this evidence that is a scoping choice: agents act through documents and tools, and the money rules live on the documents.
Oracle calls its human buyers procurement agents, and they have no amount either
One trap for anyone searching the Oracle APIs: Oracle has used the phrase "procurement agent" for decades to mean a human buyer. The Procurement API has a /procurementAgents resource, and it has nothing to do with AI.
It is still revealing. A procurement agent record carries 41 fields, and its authority is expressed as 12 yes-or-no permission flags: ManageRequisitionsAllowedFlag, ManageOrdersAllowedFlag, ManageSuppliersAllowedFlag, AnalyzeSpendAllowedFlag and eight more. None is a dollar figure. Oracle bounds a buyer's money through approval rules and Budgetary Control on the documents the buyer touches, not on the buyer.
That design works for people because everything a buyer does in Fusion becomes a document. It works for an AI agent under exactly the same condition. The moment the agent acts through an External REST or MCP tool instead, there is no document, so the approval rule and the funds check never see the payment.
The gap in one sentence: spend that never becomes an Oracle document
Put the findings together and the exposure is specific. Oracle controls spend that becomes a requisition, a purchase order, an invoice or a payment process request. It does not control spend an agent causes somewhere else, because the agent contract has nowhere to hold a limit.
Concretely, these are outside Budgetary Control and outside your approval rules: a custom agent using an MCP tool to call a payment MCP server; a REST tool that buys ads, cloud capacity or data; a partner agent from the Marketplace that uses its own payment rail; an outside agent that reaches your published Oracle agent over A2A and triggers work with a cost; and an agent that pays a card, a subscription or a metered API through x402. None of those produce a Fusion document before the money moves.
Workflow checkpoints help only if someone built one into that specific workflow, and a checkpoint asks a person to approve a step, not an amount. It cannot aggregate what one agent spent across a month, and it cannot refuse the 40th small payment that pushes an agent past its budget.
Oracle AI Agent Studio pricing and AI Units
Oracle states in its own announcements that AI Agent Studio is available at no additional cost to Fusion Applications customers, and that its prebuilt agents are included with Fusion. That is the primary source and the part you can rely on.
Consumption is where cost appears. Partner and analyst write-ups describe Fusion AI usage as metered in AI Units: an included monthly allocation per Fusion subscription, reported as 20,000 AI Units a month that do not roll over, with Oracle's default open model consuming no units for standard actions and premium or bring-your-own models consuming them. Agentic Applications are reported to need a separate platform subscription for production. Those figures come from secondary sources, not an Oracle price list, so confirm them on your order form.
We break the finance side down line by line in Oracle Payables Agent cost and controls. For a business case, notice what the meter measures. AI Units price the model calls. They say nothing about what an agent pays to suppliers, which lands in accounts payable or on a card statement and never reaches the AI meter. The same split shows up at Salesforce, where Flex Credits meter actions, and at Google, where the consumption cap governs the model bill.
Where a spend policy layer fits next to Oracle
The clean split is simple. Oracle governs what an agent may do inside Fusion, and Fusion's approval rules and Budgetary Control govern the documents it creates. A spend policy layer governs what that same agent may pay through anything that is not a Fusion document, and it does not need to know that Oracle built the agent.
In practice that means giving each agent with an External REST, MCP or partner tool that can transact a per-agent spending limit that totals across a day, a week and a month; a merchant-locked virtual card so an agent allowed to renew one vendor cannot pay a different one; an approval threshold that holds a payment above an amount you choose for a named person; and an audit trail that records which agent paid whom under which rule, in dollars, ready to reconcile against your Oracle ledger.
The test is short. If your Oracle agents only read data, draft documents and hand them to Fusion workflows, Oracle's controls cover you and you can stop here. If any agent holds a tool that can pay, buy or commit money outside Fusion, you are governing access and trusting the amount to a prompt. Pick a plan and put a ceiling on the first agent in minutes.
How Oracle compares with the other agent platforms we measured
Seven vendors, seven published models, one pattern, and Oracle is the most careful of them. Microsoft Agent 365: 48 agent-governance types, 623 properties, zero money. Salesforce Agentforce: 178 money objects and 41 agent objects out of 1,757, with an intersection of zero. AWS AgentCore: one optional per-session USD amount that resets every session. Gemini Enterprise: a real hard cap scoped to a billing project, not an agent. ServiceNow AI Control Tower: 84 agent columns, zero money, and a dollar limit only on a human approver's job code.
Oracle is the seventh: 215 agent properties, no amount, and real money controls that apply only when the agent's action becomes an Oracle document. Every vendor governs identity, access and capability, and none of them lets you write down what a specific agent may spend with a specific counterparty. For the category view, see AI agent governance and the comparison of accounting and ERP MCP servers, which covers NetSuite, Oracle's other ERP.