Oracle Fusion AI Agent Studio — release-26C

How a Fusion Agentic App Runs

An LLM on its own can read a question and write an answer. What makes a Fusion agentic app dependable is everything around it: the context the app hands over, the workflow that routes the request, the business objects that fetch real Fusion data, and the rules that had to pass before any of it shipped. Every stage below is a real artifact type, traced out of Oracle’s own sample corpus.

6 agentic apps 113 workflows 1,686 workflow nodes 18 of 26 node types in use 9 tool types 75 business objects 109 REST resources 1,676 authoring rules
User opens a panel clicks an action, or types a question intent THE AGENTIC APP RUNTIME 1 App context what the user just did, packed into $Ora* keys reads_app_context · invokes_workflow grounded input 2 Agent dispatch the app exposes an agent — which is a workflow exposes_agent · rendered_by · routes_app_stage START → node 3 Reasoning — the LLM node bounded work: classify, extract, summarise, branch uses_model · 282 LLM nodes chosen path 4 Action nodes do the work CODE · BO_FUNCTION · TOOL · SWITCH · PARALLEL · LOOP flows_to · converges_to · reads_output_of function call 5 Real Fusion data business object → function → REST resource calls_bo_function · calls_rest shaped result 6 Render back into the panel RETURN / END hand the answer to the panel that asked rendered_by · 42 RETURN · 119 END reads_output_of on_error_to next turn · panel state answered The panel updates grounded in Fusion data, inside the app Rules & conventions 1,676 rules that govern how this is built governs → node types governs → CLI commands Enforced at authoring time by aistudio validate — not at runtime. Findings unwired branches, unresolved references has_issue What the graph spots that a reviewer would not.
1 / 8

The same thing, in words

Six stages between a click and an answer. The names in code are the actual artifact types and relations you can search in the graph explorer.

  1. The app hands over context, not just a question

    An agentic app is a .app artifact whose panels are laid out by a page pattern. When the user clicks, the app packs the situation into context keys — $app.$OraAction, $app.$OraPanelName, $app.$OraMessageHint, $app.$OraUserContext — so the workflow starts knowing which panel asked and what was clicked. Some apps go further and call a dedicated context workflow first.

  2. An “agent” on the app surface is a workflow

    This is the part that surprises people. The app exposes_agent straight to a workflow, and each panel is rendered_by one. Of the 113 workflows in the corpus, 31 sit at the agent-team layer acting as supervisors and 82 at the agent layer. There is no separate agent runtime to reason about — the workflow is the agent.

  3. The LLM is one node type among eighteen

    Reasoning happens in LLM nodes — 282 of them — each bound to a model configuration via uses_model. Their job is deliberately narrow: classify the request, extract fields, pick a branch, phrase a summary. They do not call anything. That keeps the unpredictable part small and the auditable part large.

  4. Deterministic nodes do the actual work

    The bulk of every workflow is ordinary machinery: 458 CODE nodes, 295 BO_FUNCTION, 132 CONDITION, 102 SWITCH, plus PARALLEL, LOOP, SET_FIELDS and sub-workflows. They chain with flows_to, merge with converges_to, fail over with on_error_to, and pass results with reads_output_of.

  5. Data comes from Fusion, not from the model

    A BO_FUNCTION node calls_bo_function on a business object, and that function calls_rest against a real Fusion REST resource. 75 business objects, 193 functions, 109 endpoints. Nine tool types cover the rest: business object, document retrieval (RAG), external REST, MCP, deep link, email, calculator, user query and multi-file processor.

  6. The answer lands back in the panel that asked

    RETURN and END hand the shaped result back, and the panel rendered_by that workflow paints it — in place, inside the app, next to the data it describes. What the user did then becomes the app context for the next turn.

A real one, end to end

Accounting Exceptions — an agent-team workflow of 35 nodes behind one panel in the Cost Accounting Period Close workspace. Abridged to the spine; the branches are real but omitted.

  1. STARTThe panel asks. Accounting Exceptions begins.
  2. CODERead Application Context — pulls $OraAction, $OraMessageHint, $OraAppContext
  3. WORKFLOWGet Application Context — delegates to the shared Ledger Insights Context Workflow
  4. CODEIdentify Request Type — is this an initial display, or an action the user picked?
  5. SWITCHChoose Starting Path — routes on the app action, exactly as the authoring rule requires
  6. CODEPrepare Transaction Request — builds the query payload
  7. BO_FUNCTIONGet Transactions for Selected Issue → getTransactionsforErrorCategory() on Accounting Exceptions Lookup → /api/boss/extraction/extract
  8. BO_FUNCTIONCount Transactions by Category — a second read against the same object
  9. CODEReview Transactions for Selected Issue — shapes rows for display
  10. CONDITIONChoose Transaction Display — all of them, or just the top ones?
  11. LLMShow Top Transactions — the model writes the narrative over data it was handed, not data it recalled
  12. LLMPrepare Page Subtitle — one line of prose for the panel header
  13. ENDBack to the Accounting Exceptions panel, which is rendered_by this workflow.

Two things that differ from the generic picture

The constraints layer runs before shipping, not during

Generic agent harnesses put a policy gate in the request path, deciding at runtime whether a proposed action is allowed. Fusion’s equivalent sits earlier: 1,676 authoring rules that governs node types and CLI commands, checked by aistudio validate before an artifact is ever deployed. A rule like “for app-backed workflows, route on $context.$app.$OraAction” constrains the author, so the runtime does not have to.

The model is deliberately a small part of it

282 LLM nodes against 1,686 workflow nodes in total — about one in six. The rest is routing, data access and shaping. That ratio is the design: the reliability comes from how little is left to the model, and how much of the path around it is a graph you can read, diff and validate.