A four-layer event-driven system built for Oracle ERP.

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.

Four layers. Every incident passes through all of them.

Oracle AI Support Platform Four-Layer Architecture — Ingestion Layer, Diagnostic Layer, Intelligence Layer, and Delivery Layer spanning the Oracle ERP Environment

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.

A
Layer 1
Ingestion Layer — The Entry Point

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.

Interface

Support Portal

Frontend where users submit Oracle incidents with structured form fields per module.

Entry

n8n Webhook Listener

Receives JSON payloads, validates structure, and initiates the workflow for each incident.

Routing

LLM Router Agent

Classifies incident domain and dispatches to the correct diagnostic branch.

Proactive

Monitoring Integrations

Secondary ingestion from Oracle monitoring tools — enables proactive alerting without user submission.

B
Layer 2
Diagnostic Layer — The Hands on the System

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.

EBS Connectivity

JDBC / SQL*Plus

Direct database connectivity for EBS R12.x — read-only schema for diagnostics, approval-gated schema for fixes.

Fusion Connectivity

Oracle Fusion REST APIs

Fetch diagnostic data, job statuses, and module-specific logs from Oracle Fusion Cloud via authenticated REST calls.

Script Library

65 Diagnostic Scripts

Production scripts covering AP, AR, GL, FA, PO, INV, OM, WIP, PA, HCM, and System modules.

Transformation

n8n Code Node

JavaScript/Python normalization — converts raw SQL output and REST responses into structured JSON for LLM consumption.

C
Layer 3
Intelligence Layer — The Brain

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.

LLM Analysis

Claude / GPT-4o

Root cause identification, resolution path generation, and knowledge base article drafting from diagnostic output.

Vector Retrieval

Milvus RAG Pipeline

Semantic search over prior resolutions, filtered by ERP version, module, and error code.

Web Automation

Playwright Agent

Containerized MOS knowledge retrieval — authenticated, session-persistent, and stealth-mode.

Embedding

OpenAI / HuggingFace

Converts diagnostic output and resolutions into vector embeddings for storage and retrieval in Milvus.

D
Layer 4
Delivery Layer — The Result

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.

Reporting

Augmented Report

Diagnostic results merged with Oracle Support documentation and LLM analysis — delivered to the user via the support portal.

Approval

HITL Slack / Teams

Decision Tower notification with Approve, Reject, and Edit SQL buttons for high-risk fix decisions.

Execution

n8n OracleDB Node

Approval-gated fix execution — the exact SQL shown in the approval notification runs without modification.

Compliance

Signed Audit Record

SOX/ITGC-compliant record capturing agent identity, approver, SQL executed, and before/after state.

ORA-01652 — Step by Step

The table below maps each step of the ORA-01652 resolution to the specific entity responsible, the action taken, and the output produced.

#EntityActionOutput
1UserSubmits "Invoices stuck in INCOMPLETE with ORA-01652" via support portalJSON payload to n8n webhook
2n8n WebhookReceives payload, identifies ORA-01652, initiates workflowWorkflow instance created
3LLM RouterClassifies as DBA-level tablespace issue, dispatches to SYS diagnostic branchDiagnostic script selection
4Script AgentExecutes Tablespace Diagnostic Script (SYS-03) via JDBC against Oracle DBStructured JSON: tablespace metrics
5LLM AnalystAnalyzes output — TEMP at 99.8%. Root cause confirmed. Fix: extend by 5GBRoot cause analysis + fix recommendation
6PlaywrightAuthenticates MOS, searches ORA-01652, retrieves Note 123456.1Structured solution text from Oracle Support
7HITL NodeSerializes fix context, sends Decision Tower notification to Lead DBA via SlackApproval request with three-panel evidence
8DBAReviews evidence and approves fixJWT-signed approval signal
9n8nValidates JWT, executes ALTER SYSTEM via OracleDB nodeTablespace extended; invoices resume
10Audit EngineWrites signed audit record: agent, approver, SQL, before/after stateSOX-compliant change record
11RAG PipelineVectorizes resolution package, stores in Milvus with metadata tagsKnowledge base entry for future incidents

Key Integration Technologies

Every component is selected for production-grade reliability, self-hosting capability, and native fit with Oracle ERP environments.

RoleTechnologyRationale
Orchestratorn8n Self-hostedVisual 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 AdapterJDBC / SQL*Plus EBS R12.xNative 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 AdapterOracle Fusion REST API Fusion CloudThe only supported access method for Oracle Fusion Cloud. The platform uses authenticated REST calls to OTBI, BIP, ESS, and HCM endpoints.
LLM EngineClaude / GPT-4o ConfigurableClaude preferred for its large context window and strong reasoning on structured Oracle diagnostic output. Both accessed via API.
Browser AutomationPlaywright ContainerizedNode.js/Playwright containerized service for MOS retrieval. Runs separately from n8n to isolate browser automation failures from the core workflow.
Vector StoreMilvus / pgvector Self-hostedMilvus 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 StorePostgreSQL Self-hostedWorkflow state storage, audit record persistence, and FIX_BACKUP_REGISTRY — the central ledger of every data fix backup taken by the platform.
SecurityJWT / HashiCorp Vault EnterpriseJWT 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.
Security posture: The platform runs behind the corporate firewall or connects via VPN to Oracle EBS instances. Location-based access control restricts the n8n instance to the Fusion environment IP range. The AI agent operates under a restricted database schema — it can only execute High-Risk scripts via an API that validates the human approval signature.

Continue Exploring the Platform

Start the Conversation → See the Full Incident Walkthrough

Ready to talk about autonomous Oracle support?

We're talking to Oracle teams who want to be part of shaping the platform.

Get in Touch →