Oracle Fusion AI Agent Studio: Using Business Object and External REST Tools

In my previous post, I walked through building a simple RAG-based agent using the Document Tool—essentially giving the agent “something to read.” That works great when your answers live in documents.

But real enterprise use cases almost always need live data. In this post, I’ll walk through two additional tools that take your agent from “informational” to “operational”:

• Business Object Tool → Native Fusion data access

• External REST Tool → Connect to anything outside Fusion

Why This Matters

Business Object Tool is not just a data lookup layer; it is the bridge between conversational AI and live Oracle Fusion transactional data. Unlike the Document Tool, which reads static content, the Business Object Tool lets the agent interact with Fusion business objects such as invoices, workers, purchase orders, or expense reports. Also, every Business Object Tool request runs using the logged-in Fusion user’s token, so Fusion security is still enforced.

External REST Tool gives the agent reach beyond Fusion by allowing it to call live external APIs in real time. This is useful when the answer depends on third-party systems, public data services, or custom enterprise APIs that are not available as Fusion business objects.

Demo 1: Business Object Tool — Reading Fusion Data

Use Case

The use case is simple: “Show me my expense reports.” The goal is to identify the logged-in user, fetch their expense reports, and summarize the results cleanly.

Step 1: Create the Business Object

Before creating the Business Object, it is important to identify the correct Fusion REST API/OpenAPI endpoint and test it outside Agent Studio, such as in Postman. When defining the Business Object function, select only the response fields needed for the use case instead of exposing the entire payload. This keeps the response focused, reduces unnecessary data, and helps the agent produce cleaner answers.

Create a Business Object for Expense Reports using the Fusion REST API endpoint: /fscmRestApi/resources/11.13.18.05/expenseReports.

Step 2: Create the Business Object Tool

Next, expose the Business Object through a tool and link it to the appropriate function. This is what allows the agent to call the underlying Fusion data source during a conversation.

Step 3: Build the Agent

Add the required tools to the agent, including the seeded user session Business Object and the Expense Reports Business Object. The basic pattern is straightforward: first identify the user, then fetch the related data.

Step 4: Prompt Design

The prompt should guide the agent to resolve user context, handle date-based questions, fetch report details, and present the output in a structured and business-friendly way.

For this step, I also used Copilot to help refine the prompt and make it more focused for the agent’s purpose. I encourage others to do the same—start with your use case, ask Copilot to improve the instructions, and then test and fine-tune the prompt based on how the agent responds.

Step 5: Create the Agent Team

The final setup step is to create an Agent Team and add the agent to it. During this step, I also selected the appropriate LLM, security settings, and starter questions based on the use case requirements. The agent can be tested directly within Agent Studio first; once published, end users can access and test it from Home > AI Chats.

Step 6: Test

Finally, test the agent both inside Agent Studio and as an end user. In this setup, the agent returns real expense data, handles natural language questions, and provides structured responses that are easier for users to understand.

• Testing as a User

  

  

• Test from Agent Studio

Demo 2: External REST Tool - Beyond Fusion

Use Case

The second example moves beyond Fusion and looks up a DUNS number for a company using an external REST API.

For this demo, I used a public REST API only to keep the example simple and easy to follow. In a real-world Fusion scenario, the REST endpoint could point to an on-premises database exposed through Oracle REST Data Services (ORDS), another Oracle application such as Oracle EPM Cloud that exposes REST APIs, or any approved enterprise REST service.

Step 1: Test the API

For this test, I looked up a public REST API for DUNS number lookup and registered to get an API key. I then tested the API call in Postman to confirm the correct endpoint, request parameters, authentication header, and response format before configuring it inside Agent Studio.

Public REST API from API Marketplace — Browse Ready-to-Use APIs · Parse

Step 2: Create the REST Tool

Configure an External REST Tool and define the API endpoint the agent will call. Keep the base URL, resource path, HTTP method, and request parameters clearly separated so the tool is easier to configure, test, and troubleshoot.

Enter the instance URL on the main Authorization screen. Set the Authentication Type to “None” because the API key will be passed separately in the request header.

Step 3: Build the Agent

Attach the REST tool to the agent and configure the prompts so the agent knows when to use it. For example, DUNS lookup questions should trigger the REST tool instead of relying only on general knowledge. For prompt creation, define the tool’s purpose clearly, include when the REST tool should be used, and specify how the response should be summarized for the end user. As with the first demo, spend time refining the main prompt in the Details tab, the Summary Prompt in the LLM tab, starter questions, and response style before testing the agent.

Step 4: Create the Agent Team

Create an Agent Team and add the DUNS lookup agent to it. Select the appropriate LLM, security settings, and starter questions based on the use case requirements. After creating the Agent Team, publish it.

Step 5: Test

During testing, I chose a DUNS REST API as a quick way to demonstrate the External REST Tool. One thing I noticed was that the API did not return the expected DUNS number cleanly and instead returned a hashed value. Even so, the response clearly showed that the REST call was working and that the agent could retrieve and summarize other company information from the API in a readable format.

• Testing as a User

  

  

• Testing from Agent Studio

  

Final Thoughts

The real design work is in deciding what data the agent should access, when it should call a tool, and how the response should be shaped for the user.

That was my biggest takeaway from these examples. Creating a useful agent is not just about connecting a tool and calling it done. It is about thinking through the user’s question, choosing the right data source, and shaping the response so it feels clear, relevant, and helpful.