• From Rule-Based to Agentic Automation 

Traditional automations rely on static rules. Agentic AI introduces intent recognition + autonomous tool invocation. Instead of hardcoding flows, the model interprets the query and decides which API (tool) to call.

• LLMs + Tool Calling = Enterprise Agents

Tool calling is the mechanism that bridges LLM reasoning with enterprise APIs. In practice, this means defining tools, exposing them as JSON contracts, and letting the model dynamically select and execute them. 

I will showcase a working example of such an agent built using Oracle Integration and OCI Generative AI with tool calling utilizing Cohere Command R models. This AI-powered agent intelligently responds to user queries by invoking APIs to fetch invoice or receipt details—no manual configuration, no static flows. Through seamless orchestration between integration flows and Gen AI prompts, the agent behaves autonomously, executing the right action based on user intent. 

• Defining Business Tools

In Oracle Integration, each REST API can be registered as a tool. For example: 

"tools": [ 

  { 

    "name": "get_invoice_details", 

    "description": "Fetches Oracle Fusion invoice details for a given transaction number.", 

    "parameterDefinitions": { 

      "transactionNumber": { "description": "The invoice or transaction number to retrieve.", 

"type": "str",  

"isRequired": true } 

    } 

  }, 

  { 

    "name": "get_receipt_details", 

    "description": "Fetches Oracle Fusion receipt details for a given receipt number.", 

    "parameterDefinitions": { 

      "receiptNumber": { "description": "The receipt number to retrieve.", 

 "type": "str", 

 "isRequired": true } 

    } 

  } 

] 

• Oracle Fusion REST API calls 

get_invoice_details

Method: GET
Endpoint: /fscmRestApi/resources/11.13.18.05/receivablesInvoices?q=TransactionNumber={TransactionNum}

Response:

{

"TransactionType": "TRXTYE",

"TransactionSource": "Distributed",

"InvoiceStatus": "Complete",

"BusinessUnit": "US_BU"

}

get_receipt_details

Method: GET
Endpoint: /fscmRestApi/resources/11.13.18.05/receivingReceiptRequests?q=ReceiptNumber={ReceiptNum}

Response:

{

"ReceiptSourceCode": "VENDOR",

"VendorName": "CHIXXT",

"VendorNumber": "187AAW"

}

• How the Agent Decides

The first GenAI call parses the user query and generates toolCalls. The LLM Model decides which tool to be picked based on the preamble given. Example: Preamble "You are a cautious and precise assistant that helps users retrieve Oracle Fusion Accounts Receivable information using tools only. You do not generate, infer, or assume any invoice or receipt data.   Your role is to: 1. Detect clearly formatted invoice or receipt numbers in user queries. 2. Call the appropriate tool(s) based on what the user is asking:    - Call 'get_invoice_details' if a valid invoice number (e.g., INV1234) is provided.    - Call 'get_receipt_details' if a valid receipt number (e.g., 10020000002) is provided.    - Call both tools if both identifiers are valid and clearly present in the request.   Strict tool usage rules: - Never fabricate or infer invoice or receipt numbers. - Only act when the input contains valid and unambiguous information. 

- Never respond with any invoice or receipt detail unless returned by a tool. 

Do not call any tools if: 

- The request is vague or refers to incomplete identifiers (e.g., my last order, ends in 7582). 

- The number format is invalid or missing. 

- The message contains multiple unclear or conflicting references. 

- The user asks unrelated or irrelevant questions. 

In such cases, respond with the following fallback message: 

> *I can only assist you with correct invoice or receipt inquiries. To assist you, please provide a valid invoice number or receipt number.* 

--- 

Tool Outputs:

get_invoice_details returns:

• TransactionType

• TransactionSource

• InvoiceStatus

• BusinessUnit

get_receipt_details returns:

• ReceiptSourceCode

• VendorName

• VendorNumber

 Examples of valid messages:

• Give me invoice details of INV1234

• Can you get receipt details for 10020000002?

• I want both invoice INV1234 and receipt 10020000002 details

Examples of invalid messages (do not call tools):

• Can you check my last payment?

• Check invoice ending 7582

• My receipt from last week

• I think the invoice was INV or something like that

• Give me the thing I bought last month

• Track my order (no invoice/receipt present)

• Show me invoice INV1234 and maybe also check that receipt that ends with 02 (ambiguous)

You must always be accurate, never assume, and act only when the user's input includes valid and clearly formatted invoice or receipt identifiers.

"Tool Calls"

 [

{

"name": "get_invoice_details",

"parameters": {

"transactionNumber": "INV123"

}

},

{

"name": "get_receipt_details",

"parameters": {

"receiptNumber": "RCPT1"

}

}

]

 The model’s reasoning step determines whether to call one or both integrations. 

get_invoice_details 

get_receipt_details 

• Processing Tool Results 

Once Oracle Integration executes the APIs, responses are wrapped as toolResults: 

"toolResults": [

{

"call": {

"name": "get_invoice_details",

"parameters": {

"transactionNumber": "INV123"

}

},

"outputs": [

{

"TransactionType": "TRXTYE",

"TransactionSource": "Distributed",

"InvoiceStatus": "Complete",

"BusinessUnit": "US_BU"

}

]

}

]

{

"call": {

"name": "get_receipt_details",

"parameters": {

"receiptNumber": "RCPT1"

}

},

"outputs": [

{

"ReceiptSourceCode": "VENDOR",

"VendorName": "CHIXXT",

"VendorNumber": "187AAW"

}

]

}

The final LLM step merges this data into a user-facing response. 

• Prompt Engineering for Precision

Developers must enforce guardrails via preamble prompts. Example rules:

• Accept only Invoice and receipt Numbers

• Never infer or guess IDs

• Reject vague queries (e.g., "my last invoice")

This ensures reliable tool invocation and avoids API misuse.

• Maintaining Context with Chat History

When chaining queries, pass prior toolCalls and toolResults in chatHistory. This enables context retention.

• End-to-End Workflow in Oracle Integration

Step 1: Define REST APIs in OIC (get_invoice_details, get_receipt_details)

Step 2: Expose them as tools in the GenAI request

Step 3: Capture model toolCalls

Step 4: Dynamically route to OIC integrations

Step 5: Return outputs as toolResults

Step 6: Pass back to the LLM for final synthesis

• Scaling Beyond Orders

The same pattern applies to multi-domain workflows:

HR → Leave balance lookup
Finance → Invoice payment status
Supply Chain → Shipment tracking

By combining structured OIC integrations with reasoning-capable LLMs, developers can design agentic systems that scale across business functions.