Oracle’s supply-chain agent demo keeps approval and execution out of the model

Oracle’s newest runnable agent reference makes a useful distinction that many conversational-data demos blur: the model can explain and present a recommendation, but it does not own the approval, the database credential or the write path. The example turns a stockout investigation into an inventory-transfer workflow spanning ChatGPT, Claude, Gemini Enterprise and a standalone browser. Its real contribution is not the number of protocols involved; it is where authority remains when the interface changes. Oracle’s implementation guide and source repository document the boundary.

Five tools, not arbitrary SQL

The Oracle Database MCP Java Toolkit exposes exactly five supply-chain operations: find a bounded set of stockout-transfer recommendations, retrieve one recommendation, reserve a transfer ID, approve a transfer through a stored procedure and count the resulting records. User-controlled database values are bound and validated server-side. The agent cannot substitute an unrestricted SQL endpoint for those operations, according to the published configuration.

That design narrows the model’s job. Governed SQL calculates the feasible source, destination and quantity. The agent decides when to request the recommendation and how to explain it. It cannot invent the transaction parameters after the database has returned them.

Approval is a capability, not a chat message

The MCP App’s model-visible tool is read-only. When the Java service returns recommendations, it also creates a short-lived, single-use approval handle bound to the actor and the exact rows shown. That handle is placed in widget-only metadata rather than exposed to the model. Only app-side approve or reject controls can use it.

The distinction matters for natural-language analytics products that are adding actions. “The user said yes” is not a durable authorization primitive if the model can rewrite the pending operation between recommendation and execution. Binding approval to the exact database result makes the reviewed object and the executed object the same object.

After approval, the stored procedure locks the relevant inventory positions, recalculates source surplus and target shortage, rejects stale or excessive transfers, writes the audit record and reserves inventory in one database statement. A separate count tool verifies the resulting record. The host renders the decision surface; Oracle AI Database remains the transaction and audit authority.

A reference architecture, not production proof

The repository is unusually inspectable for a vendor tutorial: it includes SQL, Java, TypeScript, YAML tool definitions, setup scripts, smoke tests and host-specific adapters. It also records compatibility limits, including separate A2UI versions for the standalone browser and Gemini Enterprise paths and a Claude PWA retest that remained unresolved.

Still, this is a reference application with seeded inventory data, not a measured customer deployment. Oracle publishes no throughput, failure-rate or operator-adoption results. Practitioners should treat it as an implementation pattern to test, not evidence that the pattern has survived a live supply chain.

The transferable lesson is narrower and stronger: rich agent interfaces should collect intent, not inherit authority. Keep database credentials in the tool service, expose purpose-built operations, bind approval to immutable parameters, revalidate under transaction locks and read authoritative state back before reporting success.