What happens after the Business Analyst hands
you the design — ADW views, ODI pipelines, dataset governance, security, and
everything the agent needs to actually work in production.
This is Part 2 of a two-part series on OAC AI
Agent design. Part 1 — The Business Analyst's Guide — covers
discovery, dataset field design, knowledge document structure, and supplemental
instructions from the BA perspective. This blog picks up where the BA handoff
package ends and focuses on the IT Architect's implementation responsibilities.
If you
have read Part 1 of this series, you know that a Business Analyst's job is to
define what the OAC AI Agent needs — the questions it must
answer, the fields it requires, the policies it must reference, and the
vocabulary it must understand. A well-executed BA design produces a complete
handoff package: field specifications, derived metric formulas, knowledge
document drafts, vocabulary maps, and supplemental instructions ready to paste
into OAC.
The IT
Architect's job is to make that design technically real — and to make it trustworthy
at scale. Not just for the first agent, but for every agent the
organisation will build after it. That requires a different mindset than
building a dashboard or a report. It requires thinking about data lineage,
pipeline governance, security boundaries, and the architectural foundation that
determines whether AI answers can be trusted at all.
This
blog covers the seven technical implementation decisions that separate a
production-grade OAC AI Agent from a demo that works once and breaks in real
life.
The
core risk to understand upfront: An OAC AI Agent
will give confident, fluent, well-formatted answers regardless of whether the
underlying data is correct, governed, or complete. The agent has no way to tell
the user "I am not sure about this number." It answers with the same
confidence whether the data is perfect or wrong. The IT Architect's job is to
ensure the data behind the agent is never the thing that fails.
1. Understand the Architecture Before You
Build Anything
An OAC AI Agent in a production Oracle environment is not a standalone feature. It is the top layer of a seven-layer architecture, and every layer below it determines the quality of what the agent can deliver. Most IT teams focus on the top two layers — the agent configuration and the OAC dataset — and treat the layers below as someone else's problem. That is the most common source of implementation failure.
Layer
7 — OAC AI Agent + Knowledge Documents + Supplemental Instructions
↑
agent queries one certified OAC dataset
Layer
6 — OAC Certified Dataset (one per agent)
↑
dataset built on ADW business view
Layer
5 — ADW Business Views (pre-joined, business-named, metric SQL defined)
↑
views built on top of EBS replica tables in ADW
Layer
4 — EBS Replica Tables in ADW (raw, cryptic column names)
↑
loaded via ODI governed pipelines
Layer
3 — ODI ETL Pipelines (data lineage, monitoring, governance)
↑
extracts from source system
Layer
2 — Oracle E-Business Suite (EBS) — transactional source
↑
secured by
Layer
1 — OCI IAM + VCN + Audit Logs (security perimeter)
The AI
Agent never touches EBS directly. It never touches raw EBS replica tables
directly. It always queries a governed OAC dataset, which sits on top of a
business-readable ADW view, which sits on top of ODI-maintained EBS replica
tables. Every layer adds value. Every layer that is missing or poorly
implemented degrades the quality of every answer the agent gives.
An
important point worth stating explicitly: Oracle Analytics
Cloud in this architecture is built entirely on data in the Oracle Autonomous
Data Warehouse — not on the transactional EBS system. OAC never connects to EBS
directly. Every query the AI Agent runs, every number it returns, every trend
it surfaces comes from the data warehouse layer. This is not just a design
preference — it is a hard architectural rule. Running AI analytical workloads
against a live transactional system introduces unacceptable performance risk,
data instability, and security exposure. The data warehouse is the right layer
for analytics. The transactional system is the right layer for transactions.
These must remain separate.
Case
study scope — this architecture applies beyond Oracle EBS: Throughout
this blog, Oracle E-Business Suite is used as the source system and Oracle Data
Integrator (ODI) as the ETL tool. This reflects a common production Oracle
environment — but it is a case study, not a constraint. The same seven-layer
architecture, the same ADW business view design principles, the same dataset
certification process, and the same Agent Registry governance apply regardless
of your source system. Whether your data originates from SAP, Workday,
Salesforce, a custom application, a data lake, or any other system — if it
lands in ADW and is modelled into a governed business view, an OAC AI Agent can
be built on top of it. Similarly, the governed pipeline principle applies
whether your ETL tool is ODI, OCI Data Integration, Informatica, Talend, or any
other tool. What matters is lineage, monitoring, and a defined refresh schedule
— not the specific tool that provides them.
The IT
Architect's primary responsibility is Layers 3 through
5 — the ODI pipelines, the ADW business views, and the OAC dataset
configuration. Layers 6 and 7 (the agent itself) are largely implemented by the
BA's design specifications. Layers 1 and 2 are typically pre-existing. The
middle layers are where the architectural work happens.
2. The ADW Business View — The Most Critical
Technical Deliverable
The ADW
business view is the single most important technical artefact in the entire OAC
AI Agent implementation. It is where raw EBS source data — with cryptic column
names like OE_ORDER_HEADERS_ALL, SOLD_TO_ORG_ID, and FLOW_STATUS_CODE —
is transformed into a business-readable, pre-joined, metric-enriched flat view
that the OAC dataset and AI Agent can work with reliably.
If the
BA's field specification is the design blueprint, the ADW business view is the
built structure. Everything the agent can answer is determined by what this
view contains and how it is constructed.
2.1 What the ADW Business View Must Do
·
Rename cryptic EBS columns to business names. SOLD_TO_ORG_ID becomes Customer_ID. FLOW_STATUS_CODE becomes Order_Status. ORDERED_QUANTITY becomes Quantity_Ordered. The
agent interprets column names when forming answers — business names produce
better answers than EBS technical names.
·
Pre-join all required EBS tables. Because
the agent works with one dataset, every table join must happen here. For an AP
agent this typically means joining AP_INVOICES_ALL, AP_INVOICE_DISTRIBUTIONS_ALL, AP_SUPPLIERS, PO_HEADERS_ALL, and approval tables
into a single flat result set.
·
Implement all derived metric calculations. Every
business formula the BA defined — DPO, late payment flag, days overdue,
three-way match status — must be implemented as SQL expressions in the view.
Not in the OAC dataset. Not in the supplemental instructions. In the view,
where the calculation is governed, consistent, and traceable.
·
Apply business rules as SQL logic. "An
invoice is late if Payment_Date exceeds Due_Date" becomes a CASE
expression in SQL. "CFO approval is required if Invoice_Amount >
500000" becomes a derived column. These rules belong in the data layer —
not the AI layer.
·
Filter out noise. Test
records, cancelled transactions, internal intercompany entries that should not
appear in business analysis should be excluded from the view at the SQL level.
3. ODI Pipeline Governance — The Rule That
Cannot Be Optional
One of
the most important governance decisions in an OAC AI Agent implementation is
also one of the simplest to state and hardest to enforce: any dataset
that backs an AI Agent must be maintained by a governed ODI pipeline. No
exceptions.
This
rule exists because of a fundamental property of AI answers — they are trusted
by users at face value. When a dashboard shows a wrong number, a user might
question it, run a cross-check, or flag it to IT. When an AI Agent confidently
states a number in natural language, users tend to accept it. The confidence of
the presentation removes the natural scepticism that would catch a data quality
issue in a traditional report.
If an
AI-backing dataset is built from an ad hoc dataflow — a manual CSV upload, a
direct EBS query, an ungoverned transformation — and that source changes or
breaks, there is no lineage to trace, no monitoring to alert, and no way to
identify when the agent started giving wrong answers. By the time the business
discovers the problem, trust in the agent may be permanently damaged.
4. OAC Dataset Configuration — Where IT and BA Design Meet
Once
the ADW business view is built and the ODI pipeline is running, the OAC dataset
configuration is where the IT Architect and the BA's design specifications
converge. This step is more consequential than it looks in the OAC interface.
4.1 Critical Dataset Configuration Decisions
|
Configuration Item |
What to Set |
Why It Matters for the Agent |
|
Treat As — Measure vs Attribute |
Numeric fields that should be summed = Measure. Time dimensions (Quarter, Month, Year, Week) = Attribute. Flag fields = Attribute. |
If Quarter is set as Measure, the agent will try to sum it. If Invoice_Amount_USD is set as Attribute, the agent cannot aggregate it. Wrong Treat As settings produce nonsense answers. |
|
Aggregation Rule |
Invoice_Amount_USD = Sum. Days_To_Pay = Average. Count fields = Count. |
The agent uses the default aggregation when a user asks "what was total spend" or "what is average DPO." Wrong default aggregation gives wrong answers to the most common questions. |
|
Column Description |
Add a one-sentence description to every column using the BA's field specification as the source. |
The agent reads column descriptions as part of its context when formulating answers. Populated descriptions improve answer quality and reduce misinterpretation of field names. |
|
Column Name |
Use the business names from the ADW view. Do not rename columns in the dataset layer unless necessary. |
Renaming columns in OAC creates a disconnect from the ADW view naming — making lineage harder to trace and supplemental instruction vocabulary maps potentially incorrect. |
|
Search Index |
Right-click dataset > Inspect > Search tab > confirm "Assistant" is checked. |
The dataset will not be queryable by the AI Agent unless it is indexed. This is the most common reason an agent says "I cannot find data to answer your question." |
|
Hidden columns |
Hide internal ID columns (like ORG_ID, CREATION_BY) that should not surface in agent answers. |
Prevents the agent from surfacing internal technical fields in answers that business users would not understand. |
4.2 The Dataset Certification Checklist
Before
any dataset is indexed for an AI Agent, IT should run through a formal
certification checklist. A dataset is Green-certified for AI when all of the
following are true:
- All column names are in business language — no EBS cryptic names visible
- All measure columns have correct Treat As and aggregation settings
- All time dimension columns are set as Attribute
- Column descriptions are populated for every field
- Dataset is backed by a named ODI pipeline
- A named business stakeholder has reviewed and confirmed that metric calculations are correct
- Search index is active and dataset is indexed for AI
- Row count and last refresh timestamp have been validated
Green /
Yellow / Red classification: Maintain a simple
spreadsheet classifying all production OAC datasets. Green = certified for AI
Agent. Yellow = usable content but needs preparation work before AI indexing.
Red = raw EBS replica, experimental, or duplicate — never index for AI. With
50-100 production datasets in a typical Oracle environment, this classification
prevents an ungoverned dataset from accidentally backing a production agent.
5. Security — The Unique Risks AI Agents
Introduce
OAC AI
Agents introduce security risks that do not exist in traditional dashboards. In
a dashboard, users can only see the data that the specific visualisation shows
them. In an AI Agent, users can ask any question — which means they can
potentially surface data they would not have found through a pre-built report.
An IT Architect must design security with this expanded query surface in mind.
6.The Semantic Layer — The Long-Term Quality
Ceiling
The ADW
business view solves the immediate problem: the agent needs a clean,
pre-joined, business-named dataset to query. But as the agent program matures
and more domains are added, a more fundamental architectural question emerges —
where does business logic live, and is it consistent across all agents?
Without
a semantic layer, every ADW business view defines its own version of
"revenue," its own fiscal year logic, its own hierarchy rollups. Two
agents in different domains may calculate the same metric differently —
producing different answers to the same question depending on which agent a
user opens. This is the consistency problem that destroys confidence in AI at
scale.
Closing Thought — The Foundation Is the Work
The
most visible part of an OAC AI Agent implementation is the agent itself — the
chat interface, the natural language answers, the policy citations. That is
what the business sees and what gets demonstrated in a proof of concept. It is
not where the implementation work is.
The
implementation work is the ADW business view that transforms cryptic EBS source
data into a clean, business-readable, metric-enriched flat view. It is the ODI
pipeline that ensures that view is refreshed reliably and that any data quality
failure is caught before it reaches the agent. It is the dataset certification
process that confirms every column is correctly configured before indexing for
AI. It is the security model that ensures the expanded query surface of AI does
not expose data to users who should not see it. And it is the Agent Registry
that ensures every agent deployed stays governed, maintained, and accurate over
time.
Two
principles from this blog are worth carrying into every OAC AI Agent
conversation, regardless of your organisation's source system or ETL tooling.
First: OAC AI Agent is built on data warehouse data, not transactional system
data. That separation is non-negotiable — analytically and architecturally.
Second: the patterns described here — governed pipelines, business-named views,
certified datasets, security layers, and an Agent Registry — are source-system
agnostic. Whether your data comes from Oracle EBS, SAP, Workday, Salesforce, or
a bespoke application, the foundation you build in ADW determines everything
the agent can deliver.
The
Business Analyst defines what the agent needs to know. The IT Architect ensures
that what the agent knows is true, current, and trusted. Both roles are
essential. Neither is sufficient alone.
The agent
is only as intelligent as the foundation beneath it. Build the foundation
right, and the agent delivers value that compounds over time. Build it poorly,
and no amount of supplemental instruction tuning or knowledge document
refinement will produce answers the business can trust.
This two-part series covers the complete
design and implementation of an OAC AI Agent:
Part 1 — The Business Analyst's Guide: Discovery,
dataset field design, knowledge document structure, vocabulary maps,
supplemental instructions, validation, and the IT handoff package.
Part 2 — The IT Architect's Guide (this post): Architecture layers,
ADW business view design, ODI pipeline governance, OAC dataset certification,
security model, semantic layer strategy, Agent Registry, and performance
considerations.
About the Author
Shriram Gupta is an Oracle Solution Architect at BizInsight Consulting, specialising in Oracle Analytics Cloud, Autonomous Data Warehouse, Oracle Data Integrator, and Oracle E-Business Suite implementations. This blog is drawn from hands-on experience designing and implementing OAC AI Agent programs on production Oracle EBS environments.
