An anomaly score is useful, but it is rarely a business decision.
Imagine that an insurance company receives a new claim and its machine-learning model determines that the transaction does not resemble the claims it normally processes.
The amount may be unusually high. The customer may have submitted several claims recently. The service provider may have a history of alerts. Important evidence may be missing.
The model has detected the exception, but the claims team still needs to answer several questions:
What made this claim unusual?
Which information should be investigated first?
Is the customer’s history the main concern?
Should the provider be examined?
Does the policy require a manual review?
Would requesting additional evidence be enough?
When is there sufficient information to stop investigating?
This is where many anomaly-detection demonstrations stop. They display a score and leave the remaining process to a person or another application.
For this demo, I wanted to go one step further.
Oracle Machine Learning identifies the statistical exception. A Select AI Supervisor then coordinates a small team of specialist agents to investigate the business context. Once enough evidence has been collected, an Action Agent selects one permitted next step.
The final database update is still controlled by deterministic PL/SQL.
The result is not a chatbot generating SQL and it is not an LLM making an unrestricted decision. It is a controlled workflow in which machine learning, generative AI and database rules have different responsibilities.
Typical claims remain simple and fast. Only anomalies activate the agentic investigation.
In this article
We will build the solution in five parts:
The objective — The business experience we want to create.
The architecture — How OML, Select AI and PL/SQL divide responsibilities.
Building the OML model — How the database learns what a typical claim looks like.
Building the agent team — How the Supervisor investigates an anomaly and decides when to stop.
Running the demo — Three claims that follow three different decision paths.
1. The objective
From the application’s perspective, processing a claim should remain simple.
The database already knows the customer, their policy, the service provider, previous claims and any provider alerts. The application only needs to submit the new business transaction:
submit_claim(
p_customer_id => 102,
p_policy_id => 5002,
p_provider_id => 702,
p_claimed_amount => 4500,
p_incident_date =>
to_date('2026-08-19 14:00','YYYY-MM-DD HH24:MI'),
p_submission_date => date '2026-08-23',
p_result => l_result
);This example represents a claim of 4,500 submitted by customer 102, under policy 5002, for a service associated with provider 702.
Behind that single call, the database must decide whether the claim can follow the normal path or requires further investigation.
The desired outcome is one of three business states:
ACCEPTED
AWAITING_DOCUMENTS
MANUAL_REVIEWThe application does not coordinate the model or the agents. It submits the claim and receives the result of the complete process.
2. The architecture
The architecture separates detection, investigation and action.
Detection
Oracle Machine Learning determines whether the new claim resembles the normal population used during training.
If it looks typical, the claim is accepted and the process ends.
Investigation
If the claim is anomalous, the Select AI Supervisor receives the feature values and coordinates the investigation.
It does not automatically call every agent. It chooses the specialist most relevant to the signals found in the claim.
Action
When the Supervisor has sufficient evidence, it delegates to the Action Agent.
The Action Agent selects one permitted operation, but a PL/SQL function validates the business rules again before changing the database.
3. Building the OML model
Representing a normal claim
The model is trained with 500 synthetic rows representing ordinary claims.
Each row contains seven features:
| Feature | Business meaning |
|---|---|
CLAIMED_AMOUNT | Financial size of the claim |
INCIDENT_HOUR | Time at which the incident happened |
PREVIOUS_CLAIM_COUNT | Number of recent claims |
PREVIOUS_12M_AMOUNT | Amount claimed during the previous year |
CUSTOMER_TENURE_MONTHS | Length of the customer relationship |
PROVIDER_RISK_SCORE | Known risk associated with the provider |
DAYS_TO_SUBMIT | Delay between the incident and submission |
The values are concentrated around a plausible baseline:
Moderate claimed amounts.
Incidents during normal hours.
Few previous claims.
Established customers.
Low-risk providers.
Short submission delays.
Why use a One-Class SVM?
The training data represents normal claims. It does not contain a labelled catalogue of every possible type of suspicious behaviour.
A One-Class Support Vector Machine learns the shape of this normal population and identifies new observations that fall outside it.
The model does not require a target column:
begin
dbms_data_mining.create_model(
model_name => 'IC_CLAIM_ANOMALY_MODEL',
mining_function => dbms_data_mining.classification,
data_table_name => 'IC_ML_TRAINING',
case_id_column_name => 'CASE_ID',
target_column_name => null,
settings_table_name => 'IC_ML_SETTINGS'
);
end;
/Using OML as the gateway
When SUBMIT_CLAIM receives a transaction, the procedure calculates the same seven features and scores the new row.
For this demo:
Prediction
1means the claim is typical.Prediction
0means the claim is anomalous.
A typical claim is accepted immediately. An anomaly activates the Select AI team.
This makes OML the gateway to the agentic part of the process.
Generative AI is not used for every transaction. It is reserved for the smaller set of cases in which contextual investigation is useful.
4. Building the Select AI investigation team
The image below shows the Select AI team created for the claims investigation:
IC_CLAIMS_TEAM contains four specialist worker agents. Each agent performs one task and can use only the tools assigned to that task. IC_SUPERVISOR, configured separately as the team’s Supervisor Agent, selects these workers dynamically at runtime.
The diagram is useful because it shows the complete set of capabilities available to the Supervisor.
It does not represent a fixed execution flow. The Supervisor does not necessarily invoke the agents from top to bottom, and it does not have to invoke all of them.
Instead, it examines the anomaly context, selects the most relevant worker, waits for its result and decides what to do next.
The team uses a sequential process:
"process":"sequential",
"supervisor_agent":"IC_SUPERVISOR"Sequential means that one worker runs at a time. The Supervisor dynamically determines the worker order.
The History Agent
IC_HISTORY_AGENT investigates the customer’s previous claim activity.
Its task has access to two tools:
| Tool | Purpose |
|---|---|
IC_HISTORY_TOOL | Retrieves the customer’s previous claims and recent totals |
IC_HISTORY_COMPARE_TOOL | Compares that activity with the normal OML training population |
The History Agent always begins by retrieving the exact customer history.
If the customer has at least three previous claims or has claimed at least 15,000 during the previous twelve months, it also invokes the comparison tool.
Its purpose is to answer:
Does the customer’s recent activity help explain why OML detected an anomaly?
The Policy Agent
IC_POLICY_AGENT verifies the policy associated with the claim.
Its task uses one tool:
| Tool | Purpose |
|---|---|
IC_POLICY_TOOL | Returns policy status, coverage, deductible and manual-review threshold |
The Policy Agent does not decide the final status and does not update the claim.
It provides the Supervisor with the contractual evidence required to answer:
Does the claimed amount require human review under this policy?
The Provider Agent
IC_PROVIDER_AGENT investigates the service provider and, when appropriate, the claim documentation.
Its task has access to:
| Tool | Purpose |
|---|---|
IC_PROVIDER_TOOL | Returns provider risk, status and alert evidence |
IC_DOCUMENT_GAPS_TOOL | Identifies missing claim documents |
The Provider Agent always checks provider risk first.
If the risk score is at least 0.80, or an alert has severity 4 or higher, it returns the risk evidence immediately. Checking missing documents would not address the main concern.
For a lower-risk provider, it can continue with the document-gap tool and determine whether additional evidence is required.
Its purpose is to distinguish between two different situations:
High-risk provider
-> Return risk and alert evidence
Lower-risk provider
-> Check whether documents are missingThe Action Agent
IC_ACTION_AGENT converts the collected evidence into one operational action.
It has access to:
| Tool | Purpose |
|---|---|
IC_REQUEST_DOCUMENTS_TOOL | Requests an allowed missing document |
IC_MANUAL_REVIEW_TOOL | Sends a qualifying high-risk claim to human review |
The Action Agent is instructed to call exactly one tool.
If the evidence contains a high-risk provider, a severe provider alert or a policy threshold violation, it selects manual review.
Otherwise, for a lower-risk anomaly requiring more evidence, it requests PHOTO_EVIDENCE.
The tool then invokes a PL/SQL function that validates the database conditions again before performing the update.
How the Supervisor reasons
When OML detects an anomaly, SUBMIT_CLAIM sends the Supervisor the generated claim_id and the feature snapshot.
For example:
claim_id: 1002
claimed_amount: 4500
previous_claim_count: 4
previous_12m_amount: 22000
provider_risk_score: 0.18
days_to_submit: 4The Supervisor uses those values to identify the dominant business signal.
Its reasoning process is:
1. Read the feature snapshot.
2. Select the most relevant starting point:
High provider risk -> Provider Agent
Unusual history -> History Agent
3. Receive the worker evidence.
4. Decide whether another business area is relevant:
High amount -> Policy Agent
Low-risk provider -> Check document gaps
5. When the evidence is sufficient:
Call the Action Agent once.
6. Return the final conclusion and stop.The main routing rules can be summarised as follows:
| Initial evidence | Expected investigation |
|---|---|
Provider risk at least 0.80 | Provider Agent first |
| At least 3 previous claims | History Agent first |
Previous 12-month amount at least 15,000 | History Agent first |
| High claimed amount | Policy Agent when the policy threshold is relevant |
| Lower-risk anomaly with missing evidence | Request documents |
| Strong provider or policy evidence | Manual review |
The Supervisor is not applying one large IF/ELSE statement. These rules guide the model towards the relevant specialist, but the result returned by each worker becomes new context for the next decision.
The investigation stops when another specialist would not materially change the action.
The following examples show how that reasoning applies to three different claims.
5. Running the three demo cases
The three claims use the same procedure, OML model and Select AI team. What changes is the evidence available for each transaction.
The routes below are the expected routes according to the Supervisor instructions. The actual workers and tools executed can be verified afterwards using the Select AI history views.
Demo case 1: a typical claim
The first claim contains no particularly unusual signals.
| Relevant data | Value |
|---|---|
| Claimed amount | 3,500 |
| Previous claims | 1 |
| Previous 12-month amount | 1,800 |
| Customer tenure | 72 months |
| Provider risk | 0.10 |
| Submission delay | 4 days |
The amount, customer history, provider risk and submission delay all resemble the normal training population.
OML therefore classifies the claim as typical.
OML
|
+-- TYPICAL
|
+-- ACCEPTEDSelect AI is not invoked because there is no anomaly to investigate.
Classification: TYPICAL
Agent team invoked: NO
Final state: ACCEPTEDDemo case 2: unusual customer history
The second claim has a moderate amount and a low-risk provider, but the customer’s recent activity is unusual.
| Relevant data | Value |
|---|---|
| Claimed amount | 4,500 |
| Previous claims | 4 |
| Previous 12-month amount | 22,000 |
| Provider risk | 0.18 |
| Policy review threshold | 25,000 |
OML classifies the claim as anomalous. The dominant business signals are the four previous claims and the accumulated amount of 22,000.
The Supervisor reasons as follows:
Provider risk is below
0.80, so it does not start with the Provider Agent.The history thresholds are exceeded, so it starts with the History Agent.
The History Agent confirms that the recent activity is above the normal population.
The Provider Agent confirms that the provider is low-risk but finds that
PHOTO_EVIDENCEis missing.The amount is below the policy review threshold, so manual review is not justified.
The Action Agent requests the missing evidence.
History Agent
|
v
Provider Agent
|
v
Action AgentThe final action is proportionate to the evidence: the claim requires more information, but it does not contain a strong provider or policy signal requiring immediate human review.
Classification: ANOMALY
Main signal: Unusual customer history
Missing evidence: PHOTO_EVIDENCE
Final action: REQUEST_PHOTO_EVIDENCE
Final state: AWAITING_DOCUMENTSDemo case 3: high amount and high-risk provider
The third claim has no unusual customer history, but its amount and provider risk are far outside the normal population.
| Relevant data | Value |
|---|---|
| Claimed amount | 72,000 |
| Previous claims | 0 |
| Provider risk | 0.96 |
| Maximum alert severity | 5 |
| Policy review threshold | 50,000 |
OML classifies the claim as anomalous.
The Supervisor reasons as follows:
Provider risk exceeds
0.80, so it starts with the Provider Agent.The Provider Agent confirms the high-risk status and severe alerts.
Because the provider is already high-risk, checking missing documents would not address the main concern.
The Policy Agent confirms that
72,000exceeds the50,000manual-review threshold.Customer history is not relevant because the customer has no previous claims.
The Action Agent selects manual review.
Provider Agent
|
v
Policy Agent
|
v
Action AgentThe conclusion is supported by two independent signals: the provider risk and the policy threshold.
Classification: ANOMALY
Main signals:
- Provider risk: 0.96
- Review threshold exceeded
Final action: MANUAL_REVIEW
Final state: MANUAL_REVIEWComparing the outcomes
| Case | OML result | Supervisor route | Final state |
|---|---|---|---|
| Typical claim | Typical | Not invoked | ACCEPTED |
| Unusual history | Anomaly | History → Provider → Action | AWAITING_DOCUMENTS |
| High-risk provider | Anomaly | Provider → Policy → Action | MANUAL_REVIEW |
The comparison shows the complete pattern:
OML decides whether an investigation is required.
The Supervisor selects the relevant evidence path.
The specialist agents explain the anomaly in business terms.
The Action Agent selects one permitted next step.
PL/SQL validates and performs the final update.
Conclusion
The main value of this demo is not the number of agents. It is the separation of responsibilities.
Oracle Machine Learning determines whether the claim resembles the normal population.
The Select AI Supervisor investigates only the anomalies and chooses the specialists relevant to each case.
The worker agents collect focused business evidence, while the Action Agent selects one permitted next step.
Finally, PL/SQL validates and performs the operational update.
OML
Detect the exception
SELECT AI SUPERVISOR
Investigate the context
PL/SQL
Govern the actionThe three examples demonstrate how the same architecture adapts to different evidence:
A typical claim is accepted without invoking Select AI.
An unusual customer history results in a request for additional evidence.
A high-risk provider and policy threshold result in manual review.
This creates a process that is adaptive without giving the language model unrestricted control over operational data.
Detection is only the first step. The real business value comes from turning the anomaly into an explainable and governed action.
The full code for the demo will be found here soon.