Inside a production Agent Studio workflow: 8 patterns that actually ship.

The workflow in one paragraph

A user types a natural request — "ship these items, these quantities." The agent parses it, bulk-fetches every open PO line for the supplier via REST, runs a deterministic FIFO allocation against available quantities, presents the allocation to a human for approval, then generates a shipment number and posts the ASN through Fusion's receiving API — and finally reports back in plain language, including anything it couldn't fulfil. Total AI involvement: two nodes out of thirty. That ratio is the first lesson.

Pattern 1 — The LLM belongs at the edges, never in the middle

The single most important design decision in the whole build: the language model only parses the user's request and writes the final report. Everything between — the allocation math, the payload building, the API calls — is deterministic Code nodes and Business Object calls.

Why this matters: an allocation that moves real inventory must produce the same answer every time for the same inputs. It must be auditable ("why did PO 4711 get 40 units?" — because FIFO by due date, look at the code), and it must be trusted by the approver. An LLM doing arithmetic across 8,000 PO lines is none of those things. The rule we'd defend in any design review: LLM for language, code for logic, APIs for facts.

Pattern 2 — The human gate, done properly

Before anything touches the ledger of reality, the workflow hits a HUMAN node: a chat approval showing exactly what will happen — items requested vs allocated, every partial fulfilment flagged, total line count. Three details worth stealing:

• The approval message shows the deltas, not the data dump — requested vs allocated vs shortfall. An approver decides in ten seconds.
• Rejection isn't a dead end — the node loops back to the allocation step with the user's change request ("remove item X, reduce Y to 50"), and re-runs.
• Max iterations is set (five, in this build) — an agent that can loop forever with a human is a meeting, not a workflow.

Pattern 3 — Pagination is your problem, not the platform's

Fusion REST resources cap what one call returns (this build pulls in pages of 499 rows). The workflow needed all open PO lines — thousands of them — before allocation could start. The production answer is unglamorous: a chain of page-fetch nodes with increasing offsets, then a merge node that concatenates every page into one array before the logic runs.

Two field notes the docs won't give you:

• Defensive output parsing everywhere. A Business Object node's output sometimes arrives as items, sometimes nested under response.items, occasionally as a string needing JSON.parse. The merge code checks all three. Assume shape variance; it's cheaper than debugging it at 11 p.m.
• Size your page count to the data's growth, not today's row count. The build allocates for the worst realistic backlog, not the demo dataset.

Pattern 4 — Deterministic allocation: boring code, total trust

The FIFO core is ~60 lines of deliberately boring JavaScript: filter matching lines per item, sort by due date with a stable tie-breaker (oldest document id), walk the list allocating min(remaining, available), and record a shortfall entry the moment demand can't be met. Then a summary pass labels every item FULL or PARTIAL.

Notice what that gives the business : the approval message (Pattern 2) and the final report both come straight from the allocation output — one source of truth, three audiences (the code, the approver, the requester).

Pattern 5 — Never trust the clock, never invent a number

Two subtle production habits worth copying:

• The shipped-date comes from the server session, not from the client or the LLM — fetched via a session-details call. Timezones and user clocks lie; the server doesn't.
• The document number comes from Fusion's sequence API, not from string concatenation hope. The workflow requests a sequence value and prefixes it — collision-proof, audit-friendly.

Pattern 6 — The skip-flag: agents must know how to do nothing

What if none of the requested items have open PO availability? The naive agent errors out or, worse, creates an empty transaction. This build sets a skip flag: if the allocation produced zero lines, the transaction step is bypassed entirely and the report says, in plain language, "nothing created — here's what was unavailable and why." Graceful no-op is a feature you must design, not a default you inherit.

Pattern 7 — Custom Business Objects are your API contract

The REST calls aren't scattered through the workflow — they're wrapped as custom Business Objects with tokenized parameters (the page offset is a token, the payload is a token) and saved sample queries. That makes each call testable in isolation, reusable across workflows, and readable by the next consultant. Treat BO definitions like code: named, documented, versioned in your head if nowhere else.

Pattern 8 — The reporting prompt is a contract, not a vibe

The final LLM report node doesn't say "summarize the result." It defines strict branching rules: if nothing was created, say exactly this and list shortfalls; if success, state the document number, the count — not every line — and any partials; if error, show the return message and what was attempted. Plus a hard length cap. An LLM with rules is a UI; an LLM without rules is a liability.

What this means for your interviews

Agent questions are arriving in Fusion interviews faster than prep material exists. If you can narrate even three of these patterns — LLM-at-the-edges, the human gate, graceful no-op — you will sound like the one candidate in the stack who has actually shipped one. And if a panel asks "how would you automate shipment creation safely?", this article is the senior answer, pattern by pattern.

Published July 2026 · Related: Oracle Fusion AI Agents field guide · Payables scenario questions · Release Radar.