A Business Analyst's perspective on what actually makes an OAC AI Agent work — and what most implementations get wrong.
Oracle has made it genuinely easy to create an AI Agent in Oracle Analytics Cloud. Navigate to Create, select AI Agent, choose a dataset, paste some instructions, upload a document. You can have an agent running in under twenty minutes.
I know because I built one.
And here is what I learned quickly: the ease of setup is a trap.
The agent I built in twenty minutes could not answer half the questions I asked it in plain English. It answered the same question differently depending on how I phrased it. And when I rephrased those same questions using the exact field names from the dataset, it answered correctly every time.
The agent was not broken. The design was incomplete.
The three components that actually determine whether an OAC AI Agent works
An OAC AI Agent is built from three components — a governed Dataset, a Knowledge Document, and Supplemental Instructions. Oracle's configuration screen makes all three look equally simple to set up. They are not equally simple to design.
The Dataset is not just a table you point the agent at. It is a carefully designed flat view where every field is named in business language, every categorical value is meaningful without a lookup table, and every derived metric is pre-calculated using your organisation's specific business formula. A dataset designed for reporting will work for an AI Agent — but only if it was designed thoughtfully. Most datasets in production Oracle environments were not.
The Knowledge Document is not a policy PDF you upload. It is a retrieval index. The agent does not read it — it retrieves the most relevant chunks when a question touches on policy or business rules. A document written for human reading retrieves poorly. A document written for retrieval — short sections, specific rules, no cross-references, no legal language — retrieves accurately and produces answers that cite the right policy section every time.
The Supplemental Instructions are the bridge between how your business users speak and how your data is structured. Before writing a single instruction, the most valuable exercise a Business Analyst can do is build a vocabulary map — left column is what users say, right column is what the data contains. Every row in that map is a candidate instruction. The 6,000 character limit forces you to prioritise ruthlessly — which is exactly the right discipline.
Who should own this design work?
This is fundamentally a Business Analyst's responsibility — not an IT task. A BA who understands the business domain, can extract requirements from stakeholders, and can translate business language into data specifications is the right person to design all three components. IT implements the dataset in ADW and configures OAC. The BA defines what that implementation must deliver.
I have written a detailed guide covering the full design process — discovery questions, dataset field design principles, knowledge document structure, supplemental instruction frameworks, validation approach, and the IT handoff package a BA should produce.
If you are planning to build an OAC AI Agent — or if you have already built one and it is not performing as expected — the guide is worth reading before you touch the configuration screen again.
Read the full guide here:
Shriram Gupta is an Oracle Solution Architect at BizInsight Consulting specialising in Oracle Analytics Cloud, Autonomous Data Warehouse, and Oracle E-Business Suite. Subscribe to this blog for practical Oracle implementation insights.
Tags: Oracle Analytics Cloud | OAC AI Agent | Business Intelligence | Oracle EBS | OCI GenAI | Business Analyst | Dataset Design | Knowledge Management | RAG | Supplemental Instructions
