Taking Select AI Further: Building AI Agent in Oracle Autonomous Database

In my previous post, I shared how Select AI in Oracle Autonomous Database lets us ask questions in plain English and get SQL-generated answers from the database. That alone is a powerful capability, especially for teams that want easier access to data without writing every query manually.

But after trying that, the next question naturally came to mind: can we go beyond asking questions and actually guide the database through a small business process?

That is where Select AI Agent becomes interesting. Instead of only converting natural language into SQL, it allows us to define an agent that can follow instructions, ask follow-up questions, use approved tools, and carry a conversation across multiple steps. In simple terms, regular Select AI helps us ask the database questions. Select AI Agent helps us create a controlled assistant that can work through a defined task.

To see how this works beyond theory, let’s build a practical example. While you can build agents for complex orchestrations, it's best to start with a contained, high-value enterprise workflow.

What We Are Building

For this walkthrough, I am changing the example to something more relevant for Payables teams: a Supplier Inquiry Agent. This agent is not meant to be a supplier-facing chatbot. The idea is to create an internal assistant for Supplier Management, AP, or Procurement teams to quickly look up supplier setup information.

I do not want to overstate this use case. In most supplier systems, internal users already have screens or reports where they can look up supplier status, sites, and payment terms. So the point of this example is not that supplier inquiry suddenly becomes impossible without an agent. The point is that it gives us a simple, familiar scenario to understand how Select AI Agent can combine natural language, controlled tools, follow-up questions, and business context.

Instead of walking through every object as a lab exercise, I will keep this at a practical level and focus on six parts:

• Define the internal supplier inquiry use case.

• Create a small supplier data model and read-only inquiry function.

• Expose that function as a Select AI Agent tool.

• Define the task and guardrails.

• Create the AI profile, agent, and team.

• Test the agent with natural language prompts.

[User Prompt] ──> [Select AI Agent Team] ──> [Evaluates Task & Guardrails] ──> [Calls PL/SQL Tool] ──> [Multi-Step Conversation]

Step 1: Start with a Focused Supplier Inquiry Use Case

Before creating any agent objects, I would first define the use case in plain language. For this example, the agent is an internal assistant for Supplier Management, AP, and Procurement users. It is not supplier-facing, and it does not update supplier records.

The questions I want this agent to handle are simple but useful: is the supplier active, what supplier number is on file, what is the primary pay site, what payment terms are configured, and whether anything looks incomplete for invoice processing.

We'll look at code snippets for a couple of steps, but otherwise, I am keeping this high-level to ensure the end-to-end agent workflow stays clear and easy to follow.

Step 2: Prepare a Simple Supplier Data Model and Inquiry Function

For the demo, we'll keep the data model intentionally small: supplier details, supplier sites, and supplier payment setups. Together, these tables can represent supplier number, name, status, primary pay site, payment terms, payment method, and banking setup status.

On top of those tables, create a read-only PL/SQL function named get_supplier_inquiry_details. I like this approach because the agent does not need broad access to every table. It uses a controlled function that returns only what the inquiry use case requires.

CREATE OR REPLACE FUNCTION get_supplier_inquiry_details (
    p_supplier_num IN VARCHAR2
) RETURN CLOB
IS
    l_result CLOB;
BEGIN

    SELECT JSON_OBJECT(
        'supplierNumber' VALUE s.supplier_num,
        'supplierName'   VALUE s.supplier_name,
        'status'         VALUE s.status,
        'primaryPaySite' VALUE ss.site_code
    )
    INTO l_result
    FROM supplier_details s
    LEFT JOIN supplier_sites ss
        ON s.supplier_id = ss.supplier_id
       AND ss.primary_flag = 'Y'
    WHERE s.supplier_num = p_supplier_num;

    RETURN l_result;

EXCEPTION
    WHEN OTHERS THEN
        RETURN JSON_OBJECT('error' VALUE SQLERRM);
END;
/

Step 3: Turn the Inquiry Function into an Agent Tool

Once the function is compiled, we expose it to Select AI Agent Agent framework by registering as a tool. In this example, the tool can be called Supplier_Inquiry_Tool. The tool points to get_supplier_inquiry_details and describes when the agent should use it.

For example, if the user asks, “What payment terms are on file for this supplier?” the agent should first make sure it has enough information to identify the supplier. If the supplier name is missing or ambiguous, the agent should ask a follow-up question instead of guessing.

BEGIN
  DBMS_CLOUD_AI_AGENT.CREATE_TOOL(
    tool_name  => 'Supplier_Inquiry_Tool',
    attributes => '{
      "instruction": "Use this read-only tool for supplier inquiries. 
                      Ask for supplier name or number if missing, 
                      and clarify if the supplier is ambiguous.",
      "function": "get_supplier_inquiry_details"
    }',
    description => 'Read-only supplier inquiry tool.'
  );
END;
/

Step 4: Define the Task and Guardrails

The task is where the agent gets its operating instructions. For this example, I would keep the instructions direct and business-friendly:

• Ask for the supplier name or supplier number when needed.

• Return supplier status, primary pay site, payment terms, payment method, and banking setup status.

• Call out missing setup information, such as no payment terms on file or inactive pay site.

• Explain whether the supplier appears ready for invoice processing.

• Stay read-only and do not create, update, or inactivate supplier records.

Note: The Oracle built-in DBMS_CLOUD_AI_AGENT.CREATE_TASK can be used to define these task instructions and guardrails. In this step, the task tells the agent when to ask follow-up questions, when to use the supplier inquiry tool, what details to return, and which actions it must avoid.

Step 5: Create the AI Profile, Agent, and Agent Team

After the tool and task are defined, create the AI profile, agent, and team. The AI profile connects Select AI Agent to the model provider. The agent defines the role, and the team connects the agent with the task.

A simple agent role could be: You are an internal Supplier Inquiry Assistant for Supplier Management, AP, and Procurement users. Help internal users look up supplier setup details, including supplier status, supplier number, primary pay site, payment terms, payment method, and missing setup information. Do not update supplier records.

Note: The Oracle built-ins DBMS_CLOUD_AI.CREATE_PROFILE, DBMS_CLOUD_AI_AGENT.CREATE_AGENT, and DBMS_CLOUD_AI_AGENT.CREATE_TEAM can be used in this step. The profile connects Select AI Agent to the model provider, the agent defines the assistant’s role, and the team links the agent to the supplier inquiry task so the interaction can run as a guided workflow.

Hierarchically, this is how the pieces fit together in this use case: the OCI credential supports the AI profile, the AI profile is assigned to the agent, the agent is added to an agent team, the agent team connects the agent with the supplier inquiry task, the task uses the supplier inquiry tool, and the tool calls the read-only supplier inquiry function.

AGENT TEAM (Supplier_Inquiry_Agent_Team)
|-- AGENT (Supplier_Inquiry_Agent)
   |-- AI PROFILE (OCI_GENAI_GROK)
       |-- AI CREDENTIAL (AI_CREDENTIAL)
   |-- TASK (Supplier_Inquiry_Task)
       |-- TOOL (Supplier_Inquiry_Tool)
           |-- PLSQL Function (get_supplier_inquiry_details)

Step 6: Test the Supplier Inquiry Agent

Once the team is created, test the agent using natural language prompts. This is where the use case becomes easier to understand because the interaction feels closer to how an internal user might actually ask the question.

For example:

select ai agent show me supplier details for Acme Industrial Supplies;

The agent may respond with the supplier number, active status, primary pay site, payment terms on file, payment method, and banking setup status.

Then you can continue:

select ai agent what payment terms are on file for Acme Industrial Supplies;

The agent can answer with the payment terms and also mention whether the supplier site is active and enabled for payments.

Continue the conversation:

select ai agent list suppliers missing payment terms;

The agent can return suppliers that need follow-up because payment terms are not defined in the sample setup data.

This was the most interesting part for me. The experience feels conversational, but it is not just a chatbot response. The agent is following a defined task, asking for missing supplier details when needed, and using a controlled read-only tool to return useful supplier setup information.

Optional Step: Add Conversation Memory and Context with RUN_TEAM

The SQL command line is useful for quick testing, but in a real application you may want more control over the conversation. This is where DBMS_CLOUD_AI_AGENT.RUN_TEAM is useful. Instead of sending one isolated prompt at a time, you can create a Select AI Conversation using DBMS_CLOUD_AI.CREATE_CONVERSATION and pass the conversation ID into each RUN_TEAM call. This allows the agent team to keep track of prior prompts and responses, so the interaction feels more continuous.

In this supplier inquiry example, that means the user could first ask about a supplier, then ask follow-up questions such as “What payment terms are on file?” or “Can invoices be processed?” without repeating all supplier details every time.

Why This Matters

To me, the value is not that a supplier inquiry screen is being replaced. Most ERP applications already provide ways to get these details. The more interesting idea is that Select AI Agent gives us a pattern for building guided, conversational workflows close to the data, where an agent can ask clarifying questions, call approved tools, and explain the result in business language.

Where This Pattern Fits Best

The supplier inquiry example is intentionally simple. I would treat it as a starting point, not the final destination. The pattern becomes more interesting when the agent can connect related information, ask clarifying questions, explain exceptions, and help the user decide what to do next.

• Good fit: guided troubleshooting, such as combining supplier setup details with invoice hold information to explain why an invoice may not be ready for payment.

• Good fit: internal assistants that summarize missing setup items, suggest the right follow-up path, or combine database results with policy and procedure guidance.

• Good fit: situations where the user benefits from a short business explanation instead of just seeing rows from a query.

• Not a good fit: simple or highly deterministic lookups where an application page, report, direct SQL query, or rule-based logic is faster, cheaper, and clearer. If the answer does not need reasoning or conversation, an LLM call may add unnecessary cost and complexity.

• Not a good fit: fixed financial reports, dashboards, scheduled extracts, high-volume batch processing, or critical supplier master data updates without workflow approvals, validations, security, and audit controls.

For me, the sweet spot is a focused assistant that helps internal users understand related data and take the next appropriate step, without replacing the systems of record, approved workflows, or reporting controls that already exist.

My Takeaway

When I first looked at Select AI, I saw it mainly as a way to make SQL easier. After trying Select AI Agent with a simple supplier inquiry scenario, I see the bigger value as the pattern it introduces. The demo use case may be basic, but the underlying idea opens up possibilities for guided troubleshooting, exception explanation, policy-aware responses, and controlled workflow assistance close to enterprise data.

Of course, that also means we need to be thoughtful. Tool permissions, credentials, prompts, auditability, and data access controls all matter. For this blog, I am intentionally keeping the agent read-only. In a real implementation, any update capability should go through approved workflows, validations, roles, and audit controls.

Final Thoughts

If you already tried Select AI for natural language SQL, Select AI Agent is a good next step. Start with one simple and safe use case: create one read-only function, expose it as one tool, define one task, create one agent, and test the conversation end to end.

That is where Select AI Agent becomes more than a feature demo. Not because supplier inquiry itself is new, but because it gives us a safe way to experiment with conversational, controlled, database-driven assistance that could eventually support more advanced ERP scenarios.