#1147 - OIC Agents - counting tokens

Introduction

Building on the previous post, how can we find out how many tokens are being used in the LLM calls?

Let's run the agent again - 

The integration that runs the agent is -

I check out the activity stream - 

I search the log for "token" - 

the LLM Conversation payload is - 

Think
I need to retrieve the integration flow instances for two integrations given: 
1. UPDATE_ORDER in project AA_ANOMALY_DETECTION
2. CREATE_ORDER in project AA_ANOMALY_DETECTION
By invoking the function RETRIEVE_INTEGRATIO_INSTANCES twice with each projectId and integrationId, 
I can get the flow instances and their execution times. From the durations, 
I can analyze for anomalies where flows took longer than usual.
Action
I will call the function RETRIEVE_INTEGRATIO_INSTANCES for both integrations in parallel as they are independent of each other.
"tool_calls":[{\"type\":\"function\",\"function\":{\"name\":\"RETRIEVE_INTEGRATIO_INSTANCES\",
\"arguments\":{\"projectId\":\"AA_ANOMALY_DETECTION\",
\"integrationId\":\"UPDATE_ORDER\"}},\"id\":\"call_julG58UCC7IP3cy4IhDVijpB\"},{\"type\":\"function\",\"function\":
{\"name\":\"RETRIEVE_INTEGRATIO_INSTANCES\",\"arguments\":{\"projectId\":\"AA_ANOMALY_DETECTION\",\"integrationId\":
\"CREATE_ORDER\"}},\"id\":\"call_yrTHmJSPC9vLVb9gCY8EKXqK\"}]}",

The next occurrence of llmConvTotalTokens - 

Note also the logging of the model name - gpt-4.1-mini-2025-04-14.

Here the payload is - 

Think
I have retrieved the integration flow execution instances for the two integrations, 
UPDATE_ORDER and CREATE_ORDER, both in the project AA_ANOMALY_DETECTION. 
Each returned data contains multiple flow instances with their respective durations. 
To detect anomalies, I will analyze and compare the flow durations to identify any that 
take significantly longer than the others.
Observe
For UPDATE_ORDER, the durations are 30016ms, 55ms, and 56ms. 
The duration 30016ms stands out as an anomaly due to being much larger than the others.
For CREATE_ORDER, the durations are 20013ms, 11ms, 56ms, and 58ms. 
The duration 20013ms is clearly an anomaly here due to being much higher than the other execution times.
Act
I will now prepare the results in tables for each integration, 
highlighting the anomalies and outputting the details as requested.
For the integrations in the project AA_ANOMALY_DETECTION,
the anomaly detection resultsin execution times are as follows:
Integration: UPDATE_ORDER
projectId          | integrationId  | totalFlows | anomaly_creationDate        | anomaly_instanceId   | anomaly_duration |
|--------------------|----------------|------------|----------------------------|---------------------|------------------|
| AA_ANOMALY_DETECTION | UPDATE_ORDER  | 3          | 2026-06-11T06:06:15.927+0000 | p_cv2WVbEfGFktn245kveg | 30016 ms         |
Integration: CREATE_ORDER\\n| projectId          | integrationId  | totalFlows | anomaly_creationDate        | anomaly_instanceId  | anomaly_duration |
--------------------|----------------|------------|----------------------------|--------------------|------------------|
| AA_ANOMALY_DETECTION | CREATE_ORDER  | 4          | 2026-06-11T06:05:25.694+0000 | iiXTE2VbEfGk-wer2fD-QA | 20013 ms 
|The above tables show the total number of flow instances and highlight specific flow instances where 
the execution duration was significantly longer than usual, indicating anomalies.

The token count is equal to input prompt + model output response. 

To validate all of this, let's run the agent again, setting the trace on ReAct Pattern Intg to debug -

here we see the 2 invokes of the LLM.

The llmConvTotalTokens value is per LLM invoke.

So the total cost in tokens for this agent run is 4812 + 781 = 5594.

 

#1146 - 26.04.2 Release - New OIC Home Page

Introduction 

The Home Page has been revamped, from this -

to this - 

Let's check it out in some more detail -

Key metrics surfaced - 

Get Started immediately - 

Continue where you left off - 

Keep up to date - 

#1145 - Anomaly Detection for OIC Instance Flows

Introduction 

A customer is asking for the following -  anomaly detection capability to monitor integration runtimes and

identify performance degradation trends across a group of integrations.

Here is a simple solution, based on an Agent, leveraging the OIC factory api.

OIC Factory API 

I use the following api - 

I test it out on the following simple integration from my project AA-Anomaly-Detection - 

This create order integration is simply a stub, the only logic being to execute a WAIT of 20 seconds on orderNr 310138.

This is how I will generate an anomaly or 2.

I execute this integration a couple of times, including once with the orderNr 310138. I then execute the api in postman - 

As you can see, the response contains fields such as - creationDate, instanceId, integrationId, duration etc. 

The duration field gives us the execution time.

OIC Agent Tool

I create an integration that invokes the OIC Factory api, that we just covered.

This is then exposed as a tool.

This integration has the following request payload - 

The response is set to the result I receive in postman.

OIC Agent

The agent uses the tool we've just discussed. Its configuration is as follows - 

I now execute the create order integration a couple of times - 

I now run the agent - 

I edit the prompt to also include the overall number of flows and then re-run the agent - 

Looks good! Now let's add another integration to the mix.

This also includes the WAIT of 30 secs on orderNr 310138.

I amend the agent guidelines as follows - 

I update the template - 

I run the create order integration 3 times, the update order  run 5 times. Each has an anomaly.

Summa Summarum

This is a simple demo, which I could improve on. For example, I could include a scheduled integration that runs every nn hours. This could invoke the agent via the OIC AI Agent Native action. I could also include a Notification tool - based on a simple integration that sends the output via email to all interested parties.

 

 

#1144 - OIC Agents powered by OCI GenAI

 Introduction

This is a new feature, available with the 26.04 release, the ability to use one of the models, available with OCI GenAI, as your LLM.

I will go through the setup, step by step.

Let's begin by checking our OIC instance has access to OCI GenAI. I do this by creating a simple integration that uses the OCI GenAI native action.

Validate OIC has access to OCI Gen AI 

Mapping is as follows -

Type = 'TEXT'

Text = request field 'prompt'

Role = 'USER'

I run the integration with prompt set to - who was cathal brugha -

The only extra prep required was to create a policy allowing my OIC instance to use the GenAI family in the relevant compartment (the one in which OIC is running).

Here's an example of such -

Allow dynamic-group yourDynamicGroup to manage 

generative-ai-family in compartment yourCompartment

 
The dynamic group will have entries such as - 

resource.id = 'yourOIC Instance ClientID'

The client id can be found in the entry for your OIC instance, created under Oracle Cloud Services -

You can filter by 'Integration', if you have a lot of entries - 

Once you find your instance, click on OAuth configuration - 

Scroll down and you will see the Client Id - 

Copy this, including the _APPID suffix.

Check out the models available to you

Please check the following page, when using OCI GenAI as the LLM provider for your OIC Agent -

My OIC instance is in Phoenix, so I see the relevant GenAI region is Chicago (ORD).

Now you can open your OCI console and navigate to GenAI -

Ensure you are in the correct region, in my case, Chicago, then click on Chat. Select your compartment where OIC is located -

Here is the list of models available to you.

As I'm in the us-chicago-1 region, I see some models from Cohere, Meta, OpenAI, Google Gemini and grok. Google Gemini is not hosted in the Oracle Datacenter, so I'll not choose it. I go for openai.gpt-oss-120b.

I ask the usual - who was Cathal Brugha question - 

Which models are actually hosted on OCI? 

Data residency is often a reason for choosing to use OCI Gen AI models. However, as just mentioned, the Google Gemini models are not hosted on OCI. Check out this page for more information - 

I check out the Google Gemini models - 

Ergo, if you use any of these models, your data is being passed to GCP, i.e. it's leaving your OCI region.

Another point to note - the US regions leverage Chicago, another region in the US. In Europe it's a bit different - EU data centers use Frankfurt. The UK uses LHR (uk-london-1).

Data Privacy 

You can check out the data handling in GenAI here - 

Net, net - no data is stored or shared, if you use models hosted on OCI.

Back to our case at hand, let's use the xai.grok-4 model

OIC Agents using GenAI LLMs

I'm back in my order processing demo project; here I'll create a new Agent Pattern - 

Note the pre-seeded settings - 

There is a input field on the right, this is for the model type; here I enter openai.gpt-oss-120b.

Some other artifacts have also been created. One is the integrations that orchestrates agent actions - 

You can treat this as a blackbox, but it's good to know why it is there.

A new lookup has also been created - 

This you need to configure - 

I enter my compartment id and destination region, in my case, ORD,  (us-chicago-1)

These values are used by the aforementioned integration, when invoking the LLM.

The final artifact created is the following Library - 

This, too, is invoked by the auto-generated integration'

Now to the Agent - 

This agent is a clone of the one I already described in previous posts, so I will not go into the gory details again.

I run the new agent - 

Summa Summarum

There are multiple reasons for using the OCI GenAI based LLM. They include - 

• common billing - costs come out of the same universal credits pot as OIC
• data privacy
• ease of use

Do try it out!