Introducing Oracle AI Database Agent Engine
At 8:05 on a Monday morning, a field-service request at Northstar Industrial Services is marked complete. Two minutes later, the related invoice is created. Both records look valid: the billed amount agrees with the billing schedule, and the invoice is ready for processing. But the final service note tells a different story:
Temporary workaround completed. Continue monitoring the equipment. A return visit may be required.
The billing record shows what was charged. The service record explains what actually happened. Neither record, viewed alone, reveals that Northstar may be billing a customer for work that is not fully resolved, and by the time someone connects the two manually, the invoice may already have been sent, disputed, and credited, or the temporary repair may have failed again.
Northstar Industrial Services is fictional; the operational problem is representative.
Announcing Oracle AI Database Agent Engine
Today we are announcing Oracle AI Database Agent Engine, generally available in Oracle AI Database 26ai.
Oracle AI Database Agent Engine executes AI agent workflows inside the database, next to the data they reason over. Approved SQL and PL/SQL tools establish the facts; Oracle AI Vector Search retrieves the supporting narrative; and a language model is invoked only at defined points in the flow, receiving only the evidence assembled for its specific task. The agent’s workflow state, tracing, and resource governance are handled within the database itself — there is no separate orchestration tier to build, secure, and keep in sync with your data.
An agent built in a separate application tier executes this workflow at a distance: rows and intermediate results move between the database, orchestration code, and the model; security and governance are duplicated across systems; and when a loosely bounded model decides which query to run next, execution paths become unpredictable. Running agentic workflows where the data lives removes that tier entirely.
The rest of this post walks through a representative use case.
Case Study: Northstar Revenue and Service Exception
The gap between what was billed and what actually happened isn’t an abstract problem. At Northstar it belongs to two people, with two different jobs to do.
Maya, Billing Lead: Her team spends hours comparing billing facts with service activity. Maya needs an exception summary that identifies the rule or inconsistency that flagged the invoice, with the supporting service evidence already attached.
Elena, Revenue Controller: Before approving a credit, rebill, or revenue adjustment, she needs defensible evidence with the facts, sources, and review status preserved. The final decision remains hers.
Their shared goal: identify a credible exception early, explain it clearly, and keep people in control of the consequential business action.
Here is a representative workflow exercised by the Revenue and Service Exception Agent. A new-invoice event invokes the agent, passing the invoice identifier and instructions to evaluate the invoice against the company policy. In the Northstar scenario, Oracle AI Database serves as the governed data and execution plane, bringing together billing and service records, notes, embeddings, policies, and the agent’s tools, so Agent Engine can execute the workflow alongside the data it uses.
What follows is not a linear chain: the runtime fans out independent work into parallel branches to gather the facts; assembles the context and invokes the model for reasoning and continues with the next steps in the workflow.
The flow starts where every good investigation does: with the facts.
1. Approved queries establish the facts — in parallel
The first stage establishes business facts. Because the checks are independent, the engine executes them concurrently:
- Was the invoiced service recorded as completed?
- Is the service request closed, reopened, or still unresolved?
- Does the amount agree with the eligible billing schedule?
- Is customer acceptance recorded where required?
- Are related credits, rebills, or repeated incidents already present?
Each check uses an approved query tool and returns a small, structured result: the answer, the relevant identifiers, the rule evaluated, and a reference to the supporting record. The model is never asked to calculate the invoice amount, determine the official service status, or decide whether an acceptance record exists. Those authoritative facts come from queries and explicit business rules.
Agent Engine can run any independent tools or sub-flows concurrently — including model-backed steps, but this stage needs none.
For most invoices, the business checks pass, and the flow ends there.
What this means for the business: most invoices are cleared by deterministic checks alone.
Northstar’s invoice does not pass.
2. A first model call turns facts into a plan.
For Northstar, the checks show that the invoice amount agrees with the billing schedule; the service request is marked complete; customer acceptance is missing; and a related incident exists for the same equipment. Facts from different business areas now need to be connected.
The workflow makes its first model call. The model receives only the structured results of the completed checks and the permitted policy labels. Its task is to consolidate them into a short triage assessment and identify additional evidence that would explain the apparent conflict. It might return:
The invoice is financially valid, but the supporting service evidence may be incomplete. Customer acceptance is missing, and a related incident suggests the completed status may not represent final resolution. Retrieve the completion note, the relevant policy language, and the related incident history before recommending review.
The model call does not decide whether the invoice can be released. It converts independent facts into a working hypothesis and a focused evidence plan, and the engine validates that plan against the flow’s allowed branches. The model can select among approved follow-up paths; it cannot invent a new tool, access an unrestricted table, or authorize a financial action.
What this means for the business: the AI proposes; the agent engine enforces.
3. Targeted evidence retrieval — again in parallel
Based on the triage assessment, three approved branches run concurrently:
- Service narrative. Oracle AI Vector Search retrieves service notes related to temporary repairs, monitoring requirements, and return visits, combining semantic similarity with keywords and relational filters such as customer, asset, service request, and date.
- Incident history. A query retrieves the detailed record behind the related incident: date, equipment identifier, current status, and its relationship to the invoiced service.
- Policy. A query retrieves the applicable completion and customer-acceptance policy, identifying the evidence required before the service can support final billing.
Each branch returns only its most relevant evidence rather than transferring broad sets of records to the model. For Northstar, the decisive find is the technician’s note describing a temporary workaround and a possible return visit; the incident and policy branches confirm the prior problem and the acceptance requirement.
What this means for the business: semantic search runs where the data lives. There is no exported corpus; no additional or duplicated sets of data and indexes to secure and govern.
4. A second model call assembles the exception story
At the next join point, the flow invokes the model again – this time with the structured check results, the triage assessment, the selected note excerpts, the incident details, and the policy evidence. Its task is to consolidate this bounded evidence into an explanation Maya and Elena can review. It does not recalculate the invoice or approve anything. The resulting summary might read:
The invoice amount agrees with the billing schedule, but the service evidence does not yet support final release. The completion note describes a temporary workaround and a possible return visit. A related incident exists for the same equipment, and the required customer acceptance has not been recorded. Review the invoice before release and confirm whether the service satisfies the company’s completion policy.
The two model calls serve different purposes: the first turns parallel facts into a focused investigation plan; the second turns the resulting evidence into a clear, source-grounded exception story.
What this means for the business: explanations are grounded in preserved sources, not model memory.
5. Maya reviews; Elena decides
The agent engine prepares an exception summary: every check and its result, the triage assessment, the retrieved evidence, the final explanation, and links to the governed supporting records — plus the permitted next actions.
The agent can detect, investigate, consolidate, and explain the exception automatically. It cannot make the consequential revenue decision on Elena’s behalf. Maya validates the billing facts and confirms that the summary is ready for financial review. Elena then decides; she can release the invoice, request additional evidence, approve a rebill or credit, or reject the recommendation.
What this means for the business: accountability remains with people.
What changes for the business
For Maya, the expected benefit is less manual reconciliation: a smaller, better-qualified set of invoices arrives with the billing and service evidence already assembled. For Elena, it is a more defensible review: visible checks, preserved sources, and a traceable explanation before any action is taken.
For the business, the expected benefit is earlier intervention: a questionable invoice reviewed before it becomes a dispute, and an unresolved service condition addressed before it damages the customer relationship.
Why running inside the database matters
Beyond fewer round trips, executing this flow inside Oracle AI Database changes five things:
Workflow state is protected and transactional. The agent’s working state, intermediate results, and review queue live in the database, under the same transactional guarantees as the business data. A step either commits or it doesn’t. There is no separate orchestrator whose view of the world can drift from the data.
Every step is traced. Each check, retrieval, model call, and decision is recorded with its inputs and sources. This is what makes Elena’s review defensible: she can see exactly which checks ran, what evidence was retrieved, and how the explanation was constructed.
One security and governance model. Tools execute as governed database procedures with defined privileges.
Database-grade resource governance. Agent workflow runs under the database’s workload management, so resource management can isolate agent workloads from production workloads; a practical concern the moment an agent monitors every invoice rather than a demo dataset.
Fail-Safe Continuity: If the model or vector step is temporarily unavailable, completed deterministic results are retained and the identified candidates remain in the review queue for later enrichment or human review. An unavailable reasoning step never erases a flagged invoice and never turns incomplete evidence into an approval.
Building an agent to run in Agent Engine
The workflow can be implemented with familiar components. The tools are approved database queries and PL/SQL procedures the organization already trusts. The agent flow is defined declaratively and executed by Oracle AI Database Agent Engine, which handles scheduling, retries, state, and tracing. Flow definitions follow the open Agent Specification standard, so agents remain portable and interoperable rather than locked to a proprietary format.
Controlled autonomy
Northstar did not need an agent to make the decision. It needed an agent to identify the mismatch, assemble the evidence, and present a clear explanation to the people accountable for the outcome. That distinction is the key takeaway: Oracle AI Database becomes the governed execution home for data-centric agents—not merely the data source behind someone else’s agent runtime.
