The Oracle AI Support Platform is a modular, event-driven architecture assembled from best-in-class components, each responsible for a specific layer of the autonomous support workflow.
The four-layer architecture. Every incident enters at Layer 1 and exits at Layer 4 — either as a diagnostic report or a governed, audited fix.
Each layer is independently deployable and testable — the platform can be built incrementally, starting with read-only diagnostics before enabling autonomous fix execution.
The ingestion layer is the platform's front door. It receives incident reports, validates the payload structure, and routes the request to the correct diagnostic workflow. The design principle: capture everything, decide nothing — the ingestion layer gathers raw context without making diagnostic judgments.
The primary ingestion mechanism is a Webhook listener in n8n that receives JSON payloads from the Oracle AI support portal. A secondary path accepts alerts directly from Oracle monitoring tools — when a concurrent manager failure or tablespace threshold alert fires, it triggers the platform without human submission. An LLM-based Router agent classifies each incident into domain (Financials, Supply Chain, or DBA) and dispatches to the correct diagnostic branch.
Frontend where users submit Oracle incidents with structured form fields per module.
Receives JSON payloads, validates structure, and initiates the workflow for each incident.
Classifies incident domain and dispatches to the correct diagnostic branch.
Secondary ingestion from Oracle monitoring tools — enables proactive alerting without user submission.
The diagnostic layer executes the production diagnostic scripts from scripts.williamagreen.com, captures raw SQL output and REST API responses, and transforms the data into structured JSON for LLM analysis. The AI agent operates under a restricted read-only database schema — write access is handled separately through the approval-gated execution path in the delivery layer.
For Oracle EBS R12.x, n8n connects via JDBC with a restricted schema and executes SQL*Plus scripts. For Oracle Fusion Cloud, where direct database access is unavailable, the diagnostic layer uses Fusion REST APIs — the same access methods documented in the 15 Fusion-specific scripts in the library. Raw output is cleaned and normalized using n8n's Code node, producing structured JSON that strips verbose content and preserves the diagnostic signal.
Direct database connectivity for EBS R12.x — read-only schema for diagnostics, approval-gated schema for fixes.
Fetch diagnostic data, job statuses, and module-specific logs from Oracle Fusion Cloud via authenticated REST calls.
Production scripts covering AP, AR, GL, FA, PO, INV, OM, WIP, PA, HCM, and System modules.
JavaScript/Python normalization — converts raw SQL output and REST responses into structured JSON for LLM consumption.
The intelligence layer is where structured diagnostic output is analyzed, root causes are identified, resolutions are synthesized, and knowledge is retrieved from prior incidents. This layer orchestrates three distinct AI subsystems: the LLM analysis engine, the RAG knowledge retrieval pipeline, and the Playwright browser automation agent.
Claude is the preferred LLM for Oracle diagnostic analysis — its large context window handles verbose diagnostic output without truncation, and its reasoning performance on structured technical output is strong. The RAG Pipeline queries Milvus for prior resolutions matching the current incident. The Playwright Browser Agent retrieves My Oracle Support knowledge articles in parallel with the LLM analysis, meaning both internal analysis and Oracle-sourced content arrive together.
Root cause identification, resolution path generation, and knowledge base article drafting from diagnostic output.
Semantic search over prior resolutions, filtered by ERP version, module, and error code.
Containerized MOS knowledge retrieval — authenticated, session-persistent, and stealth-mode.
Converts diagnostic output and resolutions into vector embeddings for storage and retrieval in Milvus.
The delivery layer is where the platform's output reaches human actors. For Low-Risk diagnostic actions, the augmented report — combining diagnostic results with Oracle Support documentation and LLM analysis — is sent directly to the user via the support portal. No human approval required, typically within two to three minutes of incident submission.
For High-Risk fix actions, the delivery layer triggers the Human-in-the-Loop workflow. n8n serializes the proposed fix context and sends a structured Slack or Teams notification to the designated approver. No fix executes without a signed decision. Every action — autonomous or approved — generates a signed audit record capturing the agent identity, the approver identity, the exact command executed, and the before/after state. This is the foundation of the platform's SOX/ITGC compliance posture.
Diagnostic results merged with Oracle Support documentation and LLM analysis — delivered to the user via the support portal.
Decision Tower notification with Approve, Reject, and Edit SQL buttons for high-risk fix decisions.
Approval-gated fix execution — the exact SQL shown in the approval notification runs without modification.
SOX/ITGC-compliant record capturing agent identity, approver, SQL executed, and before/after state.
The table below maps each step of the ORA-01652 resolution to the specific entity responsible, the action taken, and the output produced.
| # | Entity | Action | Output |
|---|---|---|---|
| 1 | User | Submits "Invoices stuck in INCOMPLETE with ORA-01652" via support portal | JSON payload to n8n webhook |
| 2 | n8n Webhook | Receives payload, identifies ORA-01652, initiates workflow | Workflow instance created |
| 3 | LLM Router | Classifies as DBA-level tablespace issue, dispatches to SYS diagnostic branch | Diagnostic script selection |
| 4 | Script Agent | Executes Tablespace Diagnostic Script (SYS-03) via JDBC against Oracle DB | Structured JSON: tablespace metrics |
| 5 | LLM Analyst | Analyzes output — TEMP at 99.8%. Root cause confirmed. Fix: extend by 5GB | Root cause analysis + fix recommendation |
| 6 | Playwright | Authenticates MOS, searches ORA-01652, retrieves Note 123456.1 | Structured solution text from Oracle Support |
| 7 | HITL Node | Serializes fix context, sends Decision Tower notification to Lead DBA via Slack | Approval request with three-panel evidence |
| 8 | DBA | Reviews evidence and approves fix | JWT-signed approval signal |
| 9 | n8n | Validates JWT, executes ALTER SYSTEM via OracleDB node | Tablespace extended; invoices resume |
| 10 | Audit Engine | Writes signed audit record: agent, approver, SQL, before/after state | SOX-compliant change record |
| 11 | RAG Pipeline | Vectorizes resolution package, stores in Milvus with metadata tags | Knowledge base entry for future incidents |
Every component is selected for production-grade reliability, self-hosting capability, and native fit with Oracle ERP environments.
| Role | Technology | Rationale |
|---|---|---|
| Orchestrator | n8n Self-hosted | Visual workflow engine with native Oracle connectivity, encrypted credential storage, and Docker deployment. Self-hosting is non-negotiable for environments where Oracle connections cannot traverse the public internet. |
| EBS Adapter | JDBC / SQL*Plus EBS R12.x | Native Oracle database connectivity. The diagnostic agent runs under a restricted read-only schema — High-Risk scripts execute only via an API that validates the human approval signature. |
| Fusion Adapter | Oracle Fusion REST API Fusion Cloud | The only supported access method for Oracle Fusion Cloud. The platform uses authenticated REST calls to OTBI, BIP, ESS, and HCM endpoints. |
| LLM Engine | Claude / GPT-4o Configurable | Claude preferred for its large context window and strong reasoning on structured Oracle diagnostic output. Both accessed via API. |
| Browser Automation | Playwright Containerized | Node.js/Playwright containerized service for MOS retrieval. Runs separately from n8n to isolate browser automation failures from the core workflow. |
| Vector Store | Milvus / pgvector Self-hosted | Milvus for enterprise-scale vector storage. pgvector as alternative for knowledge bases under 10 million vectors — allowing workflow state and vector memory to coexist in a single Postgres instance. |
| Relational Store | PostgreSQL Self-hosted | Workflow state storage, audit record persistence, and FIX_BACKUP_REGISTRY — the central ledger of every data fix backup taken by the platform. |
| Security | JWT / HashiCorp Vault Enterprise | JWT tokens secure the approval signal path, preventing replay attacks. Credentials reside in n8n's encrypted store or HashiCorp Vault. Zero hardcoding in scripts or workflow definitions. |
We're talking to Oracle teams who want to be part of shaping the platform.
Get in Touch →