Oracle Agent Engine: when AI workflows belong inside the database

When an invoice agent repeatedly queries a database, moves intermediate results and waits for a model, model selection is only part of the design. Where should the workflow itself run? Teams whose critical data already lives in Oracle now have another option.

On October 26, 2026, Oracle announced general availability of AI Database Agent Engine in Oracle AI Database 26ai. It runs declarative agent workflows inside the database, combining deterministic SQL and PL/SQL operations with model calls for interpretation. This is a choice about application architecture, with consequences beyond the chat interface.

Check the installed build first

The overview describes a supported subset of Agent Spec 26.1.0. External model calls still cross the database network boundary. It also marks resumability and conversations as coming in 23.26.4.2, although the launch blog describes recovery more broadly. I would verify the installed build before promising that capability.

The getting-started guide requires DBMS_AI_AGENT, DBMS_VECTOR_CHAIN, an application schema, a provider credential and network permission. Its example uses Agent Spec 25.4.1. That mismatch with the overview warrants validation in the target environment before copying the example into a deployment.

My acceptance criterion would be a small working test. The 26ai label alone does not establish availability of every described feature. Licensing, operating costs and the selected model provider's data handling also need separate checks; this article does not establish their pricing.

Make the invoice reviewable

Oracle's companion example combines invoice and service evidence with a human decision. Northstar is explicitly fictional. It illustrates the vendor's intended workflow; it is not evidence of a customer's measured return.

For my own pilot, I would choose supplier invoice discrepancies. The following is a proposed design, not a benchmark I have run:

• Use an isolated dataset of 200 completed cases, including missing attachments and repeated imports.
• Expose narrow procedures for the purchase order, goods receipt and previous review. Use code for arithmetic and duplicate detection.
• Give the model only approved evidence to explain a discrepancy, with references to records and a list of missing evidence.
• Save a proposal to a review queue. An accounts payable employee authorizes the next action; the agent cannot change bank details or issue a payment.

In this design, n8n or Make could receive the event and deliver a notification through an approved application interface. The database workflow would own a clearly bounded part of the process. This is not a claim of a tested, ready-made connector.

Where I would use it

I would consider this approach when the team already operates Oracle, most evidence is stored there and trusted procedures exist. For a workflow spanning five SaaS products, I would first retain the existing orchestration. Moving execution into the database also creates a clear need for someone to own its workload and changes.

My failure tests would disconnect the model, deliver an event twice and change a source record just before approval. I would check that only one proposal exists, approval still matches current evidence and an error never silently authorizes a pending case. A database transaction cannot recall an email that has already been sent.

Measure review time per accepted case, missed discrepancies, costs including retries and effects on ordinary database queries. The useful outcome is traceable work with less manual effort. Counting autonomous steps tells us much less.

Checked October 27, 2026. The cover is an AI-generated illustrative photograph.