How we built an Oracle Fusion AI agent that reads a BIP report, releases the eligible sales order holds, emails what it did, and explains the design decisions that made it reliable.

Traditional automation handles the big, standardized processes well. It is the smaller, more specific work that tends to stay manual: the exceptions, the local rules, the steps unique to how a particular team operates. Each one is often too small or too bespoke to justify a full integration, so it quietly piles up as manual effort. Oracle Fusion AI Agent Studio changes that calculation. It lets you build AI agents natively inside Fusion that carry out real work, such as calling reports and REST services, invoking business-object actions, running logic, and sending notifications, orchestrated as a single pipeline and without a separate integration layer to build or maintain.

Building agents this way brings a few concrete benefits:

Runs unattended, on schedule: Once built, it works in the background with no one initiating it, inside the security stack you already own.

Reaches work that stays manual: Small, rule-based, recurring tasks that were never big enough to justify a project become worth automating.

Consistent and auditable: The same rule runs the same way every time, and each run can report exactly what it did.

Here is one we recently built for a client. In order management, releasing certain sales-order line-level holds was a manual, daily chore. A user opens the queue, checks whether the required quantity is available to reserve in a specific inventory organization, and if it is, releases the hold on that line. Then the next line. Then the next.

It is exactly the kind of work that is too rule-bound to be interesting and too consequential to be careless with, which is precisely what makes it a strong candidate for automation.

We built this one as a straight-through pipeline: read, decide, act, notify. What makes it worth walking through is where the decision lives. A BIP report does the deciding and flags the lines that are safe to release; the agent then acts on that list and reports back on what it did. It is designed to run on a schedule, twice a day. Because calling a BIP report from an agent is something many teams are still working out, we have documented that mechanism in enough detail to reproduce, alongside the design decisions that kept the agent reliable.

The process we set out to automate

The holds in question fall under two types, which we will call an Item Substitution hold and an Item Discontinuation hold. Both are applied automatically upstream as part of the existing order flow; how and when they get applied is a separate topic and outside the scope of this piece. Our focus is the release side, which is where the daily manual effort actually sat.

In both cases the release decision hinges on a single question: is there enough available-to-reserve quantity in the relevant organization? If the answer is yes, the line can be released and moves forward.

How the agent works, step by step

Here is the whole agent. We will walk through it node by node.

Step 1, decide in the report. A BIP report performs the availability comparison and, in a calculated column, produces an explicit ‘Good to Release Hold’ recommendation for each eligible line. It is transparent and testable with real data before the agent ever runs. Note: if your use case is more suited to calling a Business Object directly (a Fusion API), use a BO instead of BIP. It is a design choice. In practice, BIP can hold complex logic that a single BO node in an agent may sometimes struggle to achieve.

The report computes Available-to-Reserve (ATR) quantity using Oracle’s internal inventory formula, then applies a FIFO analytic window function to sequentially deduct each sales-order line’s ordered quantity from the shared ATR pool in requested-date order, thereby determining which held lines can be fully reserved if released. Only the lines for which ATR quantity is available are picked up in the report.

Make sure the report output is of csv format.

Step 2, call the report from the agent. For this step we create a Tool, and the Tool Type has to be ‘External REST’.

This is what the function (the endpoint) looks like:

Points to remember:

1. Operation Type should be HTTP POST.

2. Resource Path generally remains the same for all customers: /xmlpserver/services/ExternalReportWSSService

3. The sample body template below also generally remains the same for all customers and requirements, except the report path, which varies in every case, so mention the exact BIP path:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:pub="http://xmlns.oracle.com/oxp/service/PublicReportService">
<soap:Header/>
<soap:Body>
<pub:runReport>
<pub:reportRequest>
<pub:attributeFormat>csv</pub:attributeFormat>
<pub:reportAbsolutePath>/<Mention the report path>.xdo</pub:reportAbsolutePath>
<pub:sizeOfDataChunkDownload>-1</pub:sizeOfDataChunkDownload>
</pub:reportRequest>
</pub:runReport>
</soap:Body>
</soap:Envelope>

4. In the Headers section, set Name to ‘Content-Type’ and Value to ‘application/soap+xml’.

Step 3, read the results deterministically. The agent consumes the report output and turns it into a clean, structured list of the lines to act on, together with the hold code on each. This parsing is exact and repeatable: the same input always produces the same list.

A conditional check then inspects the output; if no rows are returned from BIP, the agent stops here and no action is taken.

Step 4, act. For every line flagged ‘Good to Release Hold’, the agent calls Oracle’s standard sales-order action business object, passing the unique line identifier (FulfillLineId) and the hold code, which releases the hold directly on the sales order lines.

This is how the node works during the actual agent run:

Step 5, notify with an audit trail. The agent compiles the results into a clean table (which lines were released, and which failed, with the reason for each carried through from the response) and emails it to the order management team, flagging anything that needs manual attention. If no eligible records are identified by the BIP report, no email is sent.

AI Agent Node to create email body:

AI agent node to send email:

Actual email received from AI agent with details of SO line released:

The payoff comes downstream. Once a line is released from hold, it schedules automatically, its scheduled ship date (SSD) populates, and it becomes ready for the next stage of fulfillment with no further human touch.

Sales Order line status before AI agent run:

Sales Order line status after AI agent run:

A design choice worth calling out

One decision shaped this agent more than any other: we kept the language model out of the critical path. In fact, this particular workflow uses no LLM node at all. The decision logic lives in the report. The handling of exact identifiers lives in deterministic code, where a fifteen-digit line ID is carried through perfectly every time. The agent framework’s value here is orchestration, stitching a report, an action, and a notification into one reliable, repeatable flow.

That is the principle we would offer other teams. Use the agent to orchestrate, and push exact or high-stakes logic, such as identifiers and decision rules, into deterministic components. It is tempting to treat ‘AI agent’ as a synonym for ‘call a language model at every step’, but an agent earns trust by being predictable, not by being clever. The language model is one tool in the box, not the whole box.

A practical note on cost, since it tends to come up. Because this agent uses no LLM node, there is no model usage to pay for at run time. And even when an agent does need a language model, selecting the OCI-hosted GPT-OSS model means those calls add no usage cost. For an agent scheduled to run every single day, that distinction adds up.

Takeaway

Small, repetitive, rule-bound tasks are where automation quietly compounds. What is new is that a platform like Fusion AI Agent Studio can now absorb these custom, deviation-heavy processes natively, with no external orchestration layer required. And the more agents we build, the clearer the discipline becomes: let the agent orchestrate, keep the critical logic deterministic, notify clearly, and always leave a trail a human can follow.