OCI Enterprise AI Agents

OCI has introduced Enterprise AI Agents in OCI Generative AI as a managed way to build, run, and host agentic applications. Generative AI adoption is moving from simple prompt based experimentation to enterprise ready AI assistants that can answer questions using approved business knowledge. In this article we are going to create a knowledge base using business documents and then create OCI Gen AI agents followed by a chatbot. Here we achieve in getting answers from our own documents, policies, architecture notes, runbooks and internal knowledge. The goal of this article is to show how OCI can be used to build a governed enterprise knowledge assistant without writing application code.

1)     Create OCI Object storage bucket

2)     Upload the documents into Object storage bucket

3)     Create a Knowledge base

4)     Create an Agent

6)     Create a RAG tool

7)     Launch Chat and Query.

The assistant will use a set of documents uploaded into OCI Object Storage. These documents are added to a knowledge base. The knowledge base is then connected to an OCI Generative AI Agent through a RAG tool. When we raise prompt in chat, the agent retrieves relevant information from the knowledge base and generates a response using the selected LLM.

Create OCI Object storage bucket

In OCI Console:

Navigation menu → Storage → Object Storage & Archive Storage → Buckets

Create the bucket with default settings.

Once bucket is created, Upload documents to Object storage. These documents may be PDFs, text files, architecture notes, or other supported file types. The documents stored in the bucket become the source content for the knowledge base.

 

 

Create a Knowledge Base

As the next step create a Knowledge Base, in OCI Console:

Navigation menu → Analytics & AI → Generative AI Agents

A knowledge base is the collection of source data that the agent can use for retrieval. In this article, the knowledge base points to the documents stored in OCI Object Storage. The knowledge base does not answer questions directly. Instead, it provides the searchable enterprise context that the RAG tool can retrieve from when the user asks a question.

In the OCI console, we could see three options that we discussed earlier. As first step, create a Knowledge base and then Agents using that Knowledge base and then initiate Chat.

 

For Knowledge base creation specify the Bucket having the documents.

Either all documents in the bucket can be chosen or any specific documents.

Once documents are chosen click Create button to create the knowledge base.

 

 

The knowledge base creation will take few minutes to complete. We need to be patient. We can’t alter or delete the creation until it completes.

Once Knowledge Base is created move to creating Agent.

Create Agent

An agent is the main reasoning layer. It receives our prompts and decides how to use the available tool and generates the final response. The agent can be guided using routing instructions so that it responds in a specific style and follows enterprise rules.

 

 

To create Agent, specify Name and then Routing instructions. Instructions required to specify how to respond to chat prompts. In this article, we instruct the agent to answer only from the knowledge base, avoid guessing, provide concise responses, and escalate security or production-impacting decisions to a human owner.

In this exercise we choose detail Routing LLM type Llama.

 

After Basic information, the next step is Add RAG tool. A RAG tool allows the agent to search the knowledge base, retrieve relevant content and then use that retrieved content to generate a better answer. This is important because it helps the agent answer based on approved documents instead of relying only on the model’s general knowledge.

We need to specify name and Routing description. The description specifies how the tool should work with documents.

In the Add Tool we go with Default LLM (Llama)

 

The next step is setting up Agent endpoint. An agent endpoint is the access point used to interact with the deployed agent. Once the agent and its tools are configured, the endpoint allows users or applications to send questions to the agent. Guardrails are safety and compliance controls for the AI interaction. They help reduce risk by applying checks such as content moderation, prompt injection protection, and personally identifiable information protection. We will go with default settings for Guardrails.

 

Lets review the inputs and create agent.

Chat

Agent is ready, the next step is initiating chat.

Choose the created Agent and Endpoint.

Submit the prompts in chatbox and observe the chatbox responses.

 Automatically Start or Stop an OCI Compute Instance Using OCI Resource Scheduler

In cloud environments, compute instances are often created for development, testing, learning, troubleshooting, and temporary workloads. These instances may not be required to run all the time. If they continue running when not needed, they can increase unnecessary compute usage.

Oracle Cloud Infrastructure (OCI) provides Resource Scheduler, which helps automatically start and stop supported OCI resources based on a schedule. This can help reduce the cost of compute and database resources by stopping them when they are not required and restarting them when they are needed again.  In this article, we will create an OCI Resource Scheduler schedule to automatically stop a compute instance. We will then validate that the instance state changes based on the configured schedule.

We will use below OCI services in this article :

OCI Compute
OCI Resource Scheduler
IAM Policy

Resource Scheduler creates an automated start/stop scheduling function for supported resources across a tenancy based on the schedules created.

Prerequisites

Before starting this activity, the following items should be available:

OCI tenancy access
Required compartment
Running compute instance
Permission to create Resource Scheduler schedule
Permission for Resource Scheduler to manage the target compute instance

For this article, we will use an existing compute instance and create a schedule to stop it automatically.

Resource Scheduler needs permission to perform actions on the selected resources. If the required policy is not available, schedule creation or execution may fail. The policy requirement depends on the target resource and compartment.

A policy can be created based on the access model used in the tenancy. Below policies are required for resource scheduler.

Allow <Group> to inspect resource-schedule in tenancy

Allow any-user to manage <resource_type (instance, database, and others)> in compartment id <target_compartment_ocid> where all {request.principal.type='resourceschedule',request.principal.id='ocid_of_resourceschedule'}

 Step 1: Review the Compute Instance

First, review the compute instance that will be used for testing.

From the OCI Console, navigate to:

Compute → Instances

Open the target compute instance and confirm that the instance is in Running state.

Example instance name:

private-linux-instance

For our exercise we will configure Resource scheduler to automatically stop this running instance.

Step 2: Open Resource Scheduler

From the OCI Console, navigate to Resource Scheduler.
Governance & Administration -> Resource scheduler

Open the Schedules page and select Create schedule.

Step 3: Create Schedule

Provide a meaningful schedule name.

Example:

stop-compute-instance-schedule

Add a description.

Example:

Automatically stop the demo compute instance for testing Resource Scheduler.

Select the compartment where the schedule should be created.

Step 4: Select Schedule Action

In the schedule action section, choose the action that should be performed.

For this article, select:

Action: Stop
Resource Type: Compute Instance

This tells Resource Scheduler to stop the selected compute instance when the schedule runs.

If the requirement is to start a stopped instance, a separate schedule can be created with the Start action.

Step 5: Select Target Compute Instance

In the target resource section, select the compute instance that should be stopped.

Example target resource:

private-linux-instance

Validate that the correct compartment, region, and resource are selected. You can see Autonomous database in the screenshot. This tenancy autonomous database as well and it can he scheduled through Resource scheduler.

It is important to choose the correct instance because the schedule will perform the selected action on the target resource.

The next step is about Apply Parameters.

That Apply parameters page is mainly used when the scheduled resource/action needs an additional input payload. For Start or Stop an OCI Compute Instance, normally no JSON body is required. Resource Scheduler can start or stop the selected compute instance based on the action and resource selected in the previous steps.

Step 6: Configure Schedule Time

Now configure the schedule time.

For quick validation, select a time a few minutes ahead of the current time.

Example:

Current time: 5:43 PM
Schedule action: Stop
Schedule time: 5:46 PM

This allows us to validate the schedule execution quickly.

Depending on the console options, the schedule can be configured as a one-time schedule or recurring schedule. For a blog validation, a one-time schedule is easier to test and explain.

Step 7: Review and Create Schedule

Review the complete schedule configuration.

Validate the following details:

Schedule name
Action
Target compute instance
Schedule time

After confirming the details, create the schedule. The schedule should appear in the Resource Scheduler schedules list.

Step 8: Wait for Schedule Execution

After the schedule is created, wait until the configured schedule time is reached. Before the schedule execution, the compute instance should still be in:

Running

After the schedule runs, Resource Scheduler should initiate the stop operation.The instance state should change from: Running to Stopping and then Stopped.

Step 9: Validate Compute Instance State

After the scheduled time passes, open the compute instance details page again.

Validate that the instance state changed to:

Stopped

This confirms that Resource Scheduler successfully stopped the compute instance automatically.

Step 10: Review Schedule Status

Open the Resource Scheduler schedule details page and review the work requests page.

This helps confirm that the schedule was executed.

OCI Resource Scheduler provides a simple way to automate start and stop operations for supported resources. This is useful for development, testing, and lab environments where compute instances do not need to run continuously. It helps reduce manual effort and supports basic cost optimization without custom scripts or external automation tools.

 

 Send Email Alerts for OCI Security List Changes Using Events and Notifications

Security Lists are an important part of network security in Oracle Cloud Infrastructure. They control ingress and egress traffic at the subnet level. A small change in a Security List rule can allow new traffic, block an application, or open a port that was not expected. In real environments, it is not enough to manually review Security List changes after an issue occurs. If you want more details on how to manually review security list changes, kindly refer “OCI Logging – Auditing VCN Security list changes”.  Manual Audit Log review is useful during investigation, but it is reactive. With OCI Events and Notifications, we can make the process proactive. This pattern helps us receive immediate visibility when network security rules are changed. It is especially useful for environments where Security List changes should be reviewed by cloud administrators, security teams, or network teams.

We need a proactive alert mechanism so that administrators are notified when a Security List is created, updated, or deleted.

Oracle Cloud Infrastructure provides an event driven way to achieve this using OCI Events and OCI Notifications. In this article, we will create an email alert whenever a Security List change happens in OCI.  We will use OCI services Virtual Cloud Network, Security List, OCI Events, OCI Notifications.

Prerequisites

We need following resources to perform this alert mechanism.

OCI tenancy access
Required compartment
Existing VCN
Existing Security List
Permission to create Notification topic
Permission to create Events rule
Valid email address for receiving notification
Permission to modify Security List rules for testing

For this exercise we will use an existing Security List and add a temporary ingress rule to validate the alert.

Step 1: Create Notification Topic

First, we will create a Notification topic. This topic will be used by the Events rule to send the Security List change alert.

From the OCI Console, navigate to:

Developer Services → Application Integration → Notifications

Create a topic with a meaningful name.

Example topic name:

security-list-change-alert-topic

After the topic is created, it will be used as the target for the Events rule.

Step 2: Create Email Subscription

After creating the Notification topic, create an email subscription.

Use the following subscription protocol:

Email

Provide the email address that should receive the Security List change alerts.

Once the subscription is created, OCI sends a confirmation email to the recipient. The subscription remains in pending status until the confirmation link is accepted.

The email subscription must be confirmed before alert emails can be received.

After confirmation, the subscription status changes to active.

Step 3: Create Events Rule

Next, we will create an Events rule to capture Security List changes.

From the OCI Console, navigate to:

Observability & Management → Events Service → Rules

Create a new rule.

Example rule name:

security-list-change-alert-rule

Add a short description.

Example:

Rule for alerting security list changes. Send email notification when Security List is created, updated, or deleted.

The rule should be created in the compartment where the Security List events need to be monitored.

Step 4: Configure Events Rule Condition

In the Events rule condition, select the Networking service and Security List event types.

The important Security List event types are:

Create Security List

Update Security List

Delete Security List

For most operational scenarios, Update Security List is the most important event because adding, removing, or modifying ingress and egress rules updates the Security List.

For this article, we will configure the rule to capture Security List update, create and delete events. This makes the alert mechanism more complete.

Step 5: Configure Notification Action

After defining the rule condition, configure the action.

Use the following action type:

Notifications

Select the Notification topic created earlier.

Example topic:

security-list-change-alert-topic

After the rule is created, OCI Events will monitor Security List events and send matching events to the Notification topic.

Step 6: Modify Security List Rule for Testing

Now we will validate the setup by modifying a Security List.

Open the required VCN and select a Security List.

Add a temporary ingress rule.

Example test rule:

Source CIDR: 10.0.0.0/16

IP Protocol: TCP

Destination Port Range: 8080

Description: Temporary rule for security list alert validation

Save the Security List change.

This update should generate a Security List update event. The Events rule should match the event and send a message to the Notification topic.

Step 7: Validate Email Alert

After saving the Security List change, check the subscribed email inbox.

The alert email should include event details in JSON format. The message usually contains useful information such as:

eventType

eventTime

compartmentId

resourceName

resourceId

These fields help identify what changed, when it changed, and who performed the activity. A small delay in email delivery is normal.

Step 8: Remove the Temporary Test Rule

After validating the alert, remove the temporary test rule from the Security List.

Example rule to remove:

Source CIDR: 10.0.0.0/16

Protocol: TCP

Destination Port: 8080

After removing the rule, another Security List update event should be generated. This means another email alert may be received.

This confirms that both rule addition and rule removal are captured by the event-driven alert mechanism. For example, if an application suddenly becomes reachable on a new port or stops responding after a network rule change, the alert email can help identify that a Security List was recently modified.

This is a simple and effective governance pattern for OCI networking. It helps us move from manual Audit Log review to proactive notification whenever Security List changes happen. This approach improves visibility into network security changes without requiring Cloud Guard, Security Zones, custom scripts, or additional monitoring tools.

 Create an OCI Alarm for Compute CPU Utilization

Monitoring is an important part of cloud operations. After deploying compute instances, we need visibility into resource usage such as CPU, memory, disk, and network. CPU utilization is one of the most common metrics monitored for compute instances because high CPU usage may indicate application load, inefficient processes, or capacity limitations. Also high CPU usage will affect the workload performance and it further may create service disruptions.

Oracle Cloud Infrastructure provides the Monitoring service to collect metrics from OCI resources and create alarms when metric values cross defined thresholds. In this article, we will create an OCI alarm for compute CPU utilization. We will also simulate high CPU usage on a compute instance and validate that OCI sends an email notification when the alarm is triggered.

The test case requires OCI services -  OCI Compute, OCI Monitoring, OCI Notifications and Oracle Cloud Agent.  OCI Monitoring collects CPU utilization metrics from the OCI compute instance. An alarm is created on the CpuUtilization metric. When CPU utilization crosses the configured threshold, the alarm moves to firing state and sends a message to an OCI Notifications topic. The email subscription receives the alert.

Prerequisites

Before starting this setup, the following items should be available:  

OCI tenancy access
Required compartment
Running compute instance
Oracle Cloud Agent enabled on the instance
Compute Instance Monitoring plugin enabled
Permission to create alarm
Permission to create notification topic and subscription
Valid email address for receiving notification

Validate Compute Instance Monitoring Plugin

Before creating the alarm, the compute instance should be able to emit monitoring metrics. From the compute instance details page, we can review the Oracle Cloud Agent section and validate that the Compute Instance Monitoring plugin is enabled and running.

If the plugin is disabled, metrics may not appear in OCI Monitoring.

The metric used for this article is: CpuUtilization

Create Notification Topic

First, we will create a Notification topic. The topic will receive the alarm message and forward it to the email subscription.

From OCI Console, navigate to:

Developer Services → Application Integration → Notifications

Create a topic.

Example topic name:

compute-cpu-alarm-topic

After the topic is created, we will add an email subscription.

Create Email Subscription

Open the Notification topic and create a subscription.

Use the protocol:

Email

Provide the email address that should receive the alarm notification.

After creating the subscription, OCI sends a confirmation email. The email subscription must be confirmed before alarm notifications can be received. Oracle’s Notifications documentation explains that Notifications uses topics and subscriptions, and when a message is published to a topic, it sends the message to all subscriptions on that topic.  After confirmation, the subscription status changes to active.

More details are on this topic is available in article

“Send Email Notification When Object Is Uploaded to OCI Object Storage”

Create CPU Utilization Alarm

Now we will create the alarm.

From OCI Console, navigate to:

Observability & Management → Monitoring → Alarm Definitions

Create a new alarm.

Example alarm name:

High CPU Utilization Alarm

Select the metric details:

Metric namespace: oci_computeagent
Metric name: CpuUtilization
Interval: 1 minute
Statistic: Mean

Select the required compartment and compute instance dimension. For the trigger rule, we can use a low threshold for testing.

Example:

CpuUtilization greater than 50%

For a production environment, the threshold can be higher, such as 80% or 85%, based on workload behavior and operational standards.

For notification destination, select the Notification topic:

compute-cpu-alarm-topic

Save the alarm.

Alarm Query Example

The alarm query may look similar to the following:

CpuUtilization[1m].mean() > 50

This means OCI Monitoring evaluates the average CPU utilization over a one-minute interval. If the value is greater than 50, the alarm condition is met.

For testing, a lower threshold makes it easier to trigger the alarm. After validation, the threshold can be adjusted to a production-friendly value.

Simulate High CPU Usage

To validate the alarm, we need to generate CPU load on the compute instance.

Connect to the compute instance using SSH.

For Oracle Linux, we can use the stress tool which is easiest way.

Install stress if it is not already done. We can use yum utility or other available ways to install that.

sudo yum install -y stress

Generate CPU load:

stress --cpu 2 --timeout 300

This command generates CPU load using two CPU workers for 300 seconds.

Wait for Alarm Evaluation

After CPU load is generated, OCI Monitoring needs a few minutes to collect metrics and evaluate the alarm condition.

In the alarm details page, the alarm should move from:

OK

to:

Firing

Once the alarm enters firing state, OCI Notifications sends an email to the confirmed subscription.

A small delay is normal because metrics are collected and evaluated based on the selected interval and alarm configuration.

Validate Email Notification

After the alarm is triggered, check the email inbox.

The notification email should include details such as:

Alarm name
Alarm state
Alarm Type
Alarm Severity
Notification type
Alarm Summary
Body
Time
Query
Number of metrics breaching threshold
Dimensions
Metric values, ordered by dimension

This confirms that the CPU alarm was triggered successfully and the notification flow is working.

Stop CPU Load

After validation, stop the CPU load.

With the stress command, it stops automatically after the timeout

After CPU load stops, CPU utilization should decrease.

After the next alarm evaluation cycle, the alarm should return to:

OK

Depending on the alarm configuration, a notification may also be sent when the alarm clears.

In this article, we created an OCI alarm for compute CPU utilization and connected it with OCI Notifications. We also simulated high CPU usage on the compute instance to validate that the alarm moves to firing state and sends an email notification.

This is a useful monitoring pattern for OCI compute workloads. By using Monitoring alarms and Notifications, we can detect high CPU usage early and improve operational response without using custom scripts or external monitoring tools.