The Gist: The best thing AI can do for people is make them more capable, not unnecessary. This week at Oracle AI World, we put that power in their hands. We announced Deep Insight Agents on Oracle AI Data Platform, and underneath them the thing my team has been building: a Semantic Reasoning Engine that turns business questions into checkable pipelines, written in a query grammar built for AI, over an enterprise ontology the platform writes for itself. For a business, that changes what is possible. Decisions that took a team weeks now take one person minutes, and they are proven rather than estimated, whether the question is which routes keep their aircraft when capacity runs short or how to save a morning’s connections when a dust storm hits. The know-how that used to walk out the door with your best people stays in the business. Every answer carries its own audit trail, nothing is copied out of the systems you already run, and nothing changes until a person says yes. None of it replaces anyone. It makes every person as capable as a room of experts. This essay is about why it takes all three (the ontology, the grammar and the engine) to do that, why none of them works alone, and what 53 customers told me at the booth and in many EBCs.
Last week I argued that insight is not a throughput problem. The point of AI is not to do what we already do, cheaper. It is to let us do what we could not do at all. I said the industry had quietly brought back an old motto with a new ending (move fast and replace people), and that it was the least imaginative bet available to the most powerful technology of our lifetime.
Then I made a promise: at Oracle AI World, we would put that idea in people’s hands. And I handed you a question to ask of everything you saw there, ours included.
Does this make my people capable of something they could not do before? Or does it do what they already do, slightly cheaper and considerably less reliably?
This week we kept that promise. Now comes the part most launch posts skip. Anyone who hands out a test owes it to everyone to take it themselves, in public, without grading their own paper. So here is what happened on screen, what is underneath it, and why I think the combination underneath is the most important thing we have built.
It helped that we were not the only ones saying it. Oracle CEO Clay Magouyrk built his keynote around the only question that matters now: now that AI works, what are we going to do with it? Part of the answer was ours. Oracle announced the pieces of Oracle AI Data Platform this essay is about: business ontologies that an AI Discovery agent generates and domain experts approve; the Oracle Semantic Reasoning Engine, which assembles business context before anything reaches the model; Deep Insight Agents, which investigate hard questions while a person reviews and approves; and Oracle Agent Hub, where business users find those agents and work with them. Last week I called this a governed context layer.
T.K. Anand, Oracle’s executive vice president, gave it its proper name:
To scale them reliably, enterprises need a system of context that reflects how the business actually works.
He said in one sentence what took me an entire essay.
T.K. Anand’s keynote - a must watch to get an overview of the launch
Oracle announced something I care about just as much: the Oracle AI Data Platform Innovation Service. Oracle experts work with a customer’s own team to define the business outcome, then design, build, validate, deploy and operate the solution, bringing forward deployed engineering and ongoing support with them. A tool that makes people more capable still needs people who know how to put it in their hands. Technology does not walk itself into a customer’s building. People do.
One more promise kept: I said coding agents already make great engineers greater because code comes with complete context, and that we intended to do the same for the analyst, the planner, the scientist and the CFO. This week you met the analyst and the planner. Here is what they could do.
What we showed
Two demos, two industries, one pattern: explain, predict, decide, and leave a receipt. Both run on synthetic data, so read the numbers below as illustrations of what the system does, not results we are claiming.
An airline, and a question that used to take weeks
NovaSky Airlines, a fictional carrier we built for the demo, has to decide which routes deserve its aircraft hours. Today that question takes analysts weeks. Weeks, in an industry where the price of fuel moves every day. They consult operations and supply chain, then pull numbers out of Fusion Data Intelligence, EPM and the airline’s own data warehouse, three systems that were never designed to talk to each other.
Before anyone asked a question, the Semantic Reasoning Engine read those systems where they live, together with the airline’s document repository and wiki, and wrote down what it found: 156 concepts of institutional knowledge and six experts. Every relationship it inferred carries a confidence score and a sentence a human can check. My favourite:
“Raw allocations contain multiple cost-pool and driver rows per route-month; aggregate ALLOCATED_AMOUNT before joining to Actual profitability rows.”
That sentence is a decade of analyst folklore. It used to live in one person’s head. Now it lives in the ontology, and every question inherits it.
Then the analyst asked three questions, each harder than the last.
Explain. Which routes lost the most money in Q4 2025 against budget, and why? Amsterdam, Heathrow and Seoul led the losses, at $8.24 million, $7.13 million and $6.11 million below budget. Amsterdam and Seoul lost passengers; Heathrow paid more for fuel. The five largest misses explain 45.57% of a $63.15 million shortfall, and each comes with an action. The answer ends with a section most AI products would rather hide: how it was measured, and what else the question could have meant.
Predict. Which routes will miss budget in Q1 2026, and what is driving it? Three expert agents (route forecast risk, network and operating drivers, cost allocation methodology) worked in parallel while an independent analysis reviewer checked their work. The miss repeats: 45 of 46 routes, $58.65 million below budget, led by Heathrow. Fuel price per block hour is the clearest driver, and the engine says plainly that it is only a partial explanation.
Decide. Aircraft availability falls 5% short of plan. Which routes keep their hours? The analyst stated the rules in plain words: every route keeps at least 80% of its flights, London and Paris keep all of them, and no route flies more than its budget. A mathematician agent and a solver weighed all 46 routes together and proved the optimum: a fully allocated result $30.3 million above budget while flying only 95% of the hours, about $50 million better than cutting every route evenly.
Now watch what happened next, because it is the most important moment in either demo. There is a principle older than any of us: nemo iudex in causa sua. No one should be the judge in their own case. That goes for agents, too. The independent reviewer returned its verdict: pass with caveats, 98% confidence. The solution was mathematically correct and independently verified, but the economic interpretation was high risk. Allocated overhead does not disappear when a flight does, and every one of those routes still made a positive variable contribution. Use this as a merit order and a starting point, it said, and re-optimize with whole flights and avoidable costs before you change the schedule. Then it stamped the decision with a warrant number, so anyone can audit it later. Read that again. The machine told the analyst where not to trust the machine. That is not a weakness in the product. That is the product.
The forecast behind all of this was not a language model’s guess. It came from the airline’s own model, compared against a baseline in MLOps and registered before the agent was allowed to use it. And nothing was copied: the data stayed in Fusion Data Intelligence, EPM and the warehouse, federated through an external catalog.
An airport, a dust storm and nine systems
Five in the morning at a major hub, where about three of every four passengers are connecting. A dust storm rolls in, visibility drops, and 18 inbound flights will now land 20 to 45 minutes late, straight into the seven o’clock departure bank. More than 3,000 connections and 4,000 transfer bags suddenly have less than the minimum connect time.
Every answer the duty manager needs exists somewhere: stands in the operational database, bags in the baggage system, queues at transfer security, crews, buses and the airline’s own plan. Nine systems and a phone in every hand. By the time the picture is complete, the wave has broken.
On Oracle AI Data Platform, the same morning runs differently. The platform connects to all nine systems where the data lives (workforce, finance and maintenance data come from Oracle Fusion through Fusion Data Intelligence) and copies nothing. It generates an ontology of the airport on its own: flights, stands, passengers, bags, connections, security lanes and teams, and how each one depends on the others.
See. Which connections in the seven o’clock bank are at risk? 3,140 passengers on 26 departures, with London, New York, Manila and Johannesburg carrying the most.
Explain. Why? The engine traced every connection through the ontology. Four late arrivals had been planned onto remote bus stands, adding 14 minutes to the gate (1,180 connections). Transfer security would peak at 38 minutes (1,420). Belt four would carry 2.1 times its normal transfer load (910). Some connections faced more than one of these. It is not the delay that breaks the connection. It is what happens after landing.
Decide. Replan the morning to save the most connections. This is a decision, not a lookup: one optimization across stands, gates, bag runners, security lanes and departure holds, under every rule the airport runs by. Holds of no more than 10 minutes, no stand conflicts, slot times protected, and only staff who are actually on shift in Oracle Fusion HCM. The plan saves 2,470 of 3,140 connections, 79%.
Act, with permission. Nothing changed until a person clicked approve. Then five action agents carried out 19 actions: the stand plan in the operational database, transfer bags re-prioritized, teams dispatched, hold requests to the airline, a new gate on every affected passenger’s phone, extra shifts on the Fusion roster. Every action went into one audit record.
By 7:40 the wave had closed. The 670 passengers who could not be saved were rebooked, with hotels, before they reached the gate rather than after. The cost of the morning, $1.2 million, was already posted in Oracle Fusion, and the executive summary named three causes to fix before the next storm. That is the move from a digital twin, which shows you the airport, to a decision twin, which sees, decides and acts in minutes on the systems the airport already runs.
The ontology: the business, written down
Strip away the airplanes and both demos rest on the same foundation: a written-down account of what the business is made of and how its parts depend on each other.
That is all an ontology is. Routes, cost pools and allocation drivers. Flights, stands, bags, connections, lanes and teams. What “fully allocated result” means at this airline, which revenue table finance actually trusts, and which rule (aggregate the allocations first) every new analyst learns the hard way. Most enterprises have this knowledge. Almost none have it written down anywhere a machine can use.
The industry has tried before, and I have watched the attempts die. A team spends a year drawing boxes and arrows, and the diagram is stale the day it is approved. So we made two decisions.
The ontology writes itself. It is generated from the schemas, the documents and the query logs, and kept current as they change. Nobody draws it. In the airline demo it found 156 concepts and six experts before the first question; in the airport demo it found the dependency between a late arrival, a remote stand, a bus and a belt.
Humans stay in charge of what matters. Every inferred relationship carries a confidence score and a plain-English description. Every definition carries a review status, and the ones that matter wait for a person to confirm them. Where the business needs formality (a regulated measure, a contractual definition) a formal, human-governed ontology sits on top, and the generated semantics fill in everything the formal model never got around to describing. The two are distinct, and simply bridged.
In my last essay I argued that the next frontier is not the search but the search space itself: how a problem is described, what the model is told the world contains, which questions it can even ask. The ontology is the search space. The airport’s answer to why (it is not the delay, it is what happens after landing) was not hidden in any one system. It only existed in the relationships between them, and the ontology is where those relationships are written down.
The grammar and the engine
Why do coding agents make great engineers greater while most knowledge workers get a slightly better search bar? Because the engineer works inside a complete context. The programming language is a composable grammar a machine can check. The comments explain why the code is the way it is. The repository is the ontology, the tests are the guardrails, and the compiler and the build are the receipts. The analyst gets free text and forty systems. That is not a fair fight, and it never was.
Our answer to that asymmetry is a query grammar built for AI: a pipeline-based language for asking questions of a business, and for acting on it. Every question becomes a pipeline of small, precise steps that snap together (a measure, a filter, a forecast, a constraint, a write), and every step is expressed in the ontology’s own terms. It is easy for AI to write and easy for a machine to check before anything runs. So when the analyst types “every route keeps at least 80% of its flights, and London and Paris keep them all,” the engine does not improvise SQL from scratch. It compiles a sentence into a constraint it can check, over concepts it already understands, against data it is allowed to see. The enrichment you saw in the airline demo plays the role that comments play in code: the human explanation, sitting right next to the thing it explains. And because the grammar covers most of what Python can express, the engine reads a formula symbolically. It can tell that two findings are related by algebra, not by a fuzzy guess that two paragraphs sound alike.
The Semantic Reasoning Engine is what runs those pipelines, and the demos showed each of its jobs.
It plans. In the thinking activity you can watch it decide what to aggregate, which drivers to inspect and which cost allocations to check before it writes a word.
It picks up the right instrument. The forecast came from the airline’s own registered model. The decision came from a solver that proves its optimum. For the hard question it found 23 expert agents and called the ones it needed, including a mathematician. The language model earns its keep on what the data means and on knowing which instrument to pick up, not on doing arithmetic in its head.
It checks itself. An independent reviewer verified the airline’s decision and then told the analyst where not to trust it. Every answer says how it was measured and what else the question could have meant.
It leaves receipts. The airline’s decision carries a warrant number; the airport’s morning carries one audit record covering 19 actions. Anyone can trace an answer back to the concepts and the rows it rested on.
It acts, with permission. The same layer that explains the business can change it, through writes and structured workflows under the same governance. In the airport demo nothing moved until a person clicked approve.
It remembers. An expensive answer becomes a finding the next person and the next agent start from, instead of evaporating in a chat history. Never pay for the same insight twice.
And underneath all of it, the data never moved. It stayed in Fusion, in EPM, in the warehouse and in nine airport systems, under its owners’ rules. The computation went to the data, and only the answer came back.
Why it takes all three
Each piece gives the next one something to stand on, and each fails on its own.
A question arrives in plain words, becomes a pipeline of checkable steps in the ontology’s terms, and runs where the data lives; the answer comes back up with the receipt that proves it.
That last row is the economics I complained about last week. Context is amortized reasoning: you pay once to understand the business, and every question afterward inherits that understanding instead of paying a model to rediscover your enterprise from scratch.
What it changes for the people doing the work
Go back to the question from last week, the one I told you to ask of everybody, starting with us. Does this make people capable of something they could not do before? Yes. Here is how.
The analyst. Weeks became minutes, but speed is the least of it. The NovaSky analyst did not get a faster chart. She got a forecasting model she did not have to build, a mathematician and a solver she did not have to hire, and a reviewer who told her where the answer was weak before her CFO did. That is the work of a small analytics department, at one person’s desk.
The planner. The duty manager did not get a dashboard of nine systems. She got a decision across all of them, under every rule the airport runs by, in the time it used to take to make the phone calls. That is not a lookup made faster. It is a decision that was never possible at five in the morning.
The CFO. The cost of the morning was posted in Oracle Fusion before the executive summary was written, and the airline’s schedule decision carries a warrant anyone can audit. Finance stops asking where a number came from, because the number carries its own receipt.
The scientist. We did not show the scientist this week. The same pattern (an ontology of the domain, a grammar for asking it questions, an engine that picks up the right instrument) is how a planner or a researcher who has never written a line of Python gets a simulation or an optimization on serious compute. That is what comes next.
Now notice what neither demo did. It did not replace anyone. The duty manager is still the person who clicks approve. The analyst is still the person who decides whether the caveats matter. What changed is the height of the floor they stand on. Last week I described the aim as making every person in your company as capable as your best analyst on her best day. This week a duty manager at five in the morning, in a dust storm, had a team of experts at her elbow and the authority to use them.
What we heard at the booth
A keynote is where you make an announcement. A booth is where you find out whether anyone believes it. Here is what the week looked like from my viewpoint.
I met 53 customers.
I uncovered more than 20 features I now want to build. That is what happens when you stop presenting and start listening.
I trained more than 30 forward deployed engineers, business developers and solution architects, the people who will put this in customers’ hands.
I got a fair number of hugs, from customers and from Oracle colleagues excited to see it work.
Hugs are not a metric, and I will not pretend they are. But nobody hugs a product that is coming for their job. People hug the thing that makes them better at it.
Now we take it to general availability.
What comes next
Deep Insight Agents are in preview on Oracle AI Data Platform, Oracle says the new capabilities will be available within the next 12 months, and the Semantic Reasoning Engine underneath them is the part I would ask you to judge us on. Not the chat window. Not the charts. The ontology that writes itself, the query grammar that turns a business question into something a machine can check, and the engine that plans, computes, checks itself, asks permission and leaves a receipt.
Three things to watch from here. The engine will reach more of the world a business operates in: documents, images, sensor streams and the public record, turned into facts with their evidence attached. Findings will compound across teams, so the second person to ask a hard question starts where the first one finished. And the instruments on the bench will get heavier, until a planner or a scientist can run a serious simulation the way the NovaSky analyst ran a solver this week.
Last week I said every great revolution made the same bet: give people better tools and they will do something more interesting than anyone predicted. The other bet, the one the industry keeps making, is that people are the cost to be cut. This week, in a fictional airline and a dust storm at five in the morning, we placed the first bet in public. I know which side of that bet I want to be on. Move fast and replace people was never the only way to move fast.