Introduction

In the companion post, Workflow Agents Should Orchestrate Systems — Not Just Conversations , we looked at why workflow agents should be designed as governed process orchestrators. This post goes one level deeper: how to structure the workflow so each node has a clear job, each system call has a clear contract, each failure path has a defined outcome, and the LLM is used where reasoning adds value.

The goal is not to use every available node. The goal is to use the smallest set of nodes that makes the process clear, testable, and supportable.

We will use the same purchase-request example: a requester provides a supplier quotation and expects the system to help create a draft requisition, route approval if needed, and notify the right people when the flow completes or fails.

Reference Scenario Recap

The scenario is intentionally narrow: a requester wants to create a purchase request from a supplier quotation. The quotation may arrive as a PDF, email attachment, or text input. The workflow should review the information and help create a draft requisition.

A good first workflow agent should not attempt to automate the entire procurement lifecycle. It should automate a bounded process with clear inputs, outputs, and failure paths.

Oracle documents a similar pattern through the seeded AI Agent: Quote to Purchase Requisition Assistant. The workflow-agent documentation also shows a related architecture with business object lookups, document processing, LLM-based extraction, conditional checks, requisition creation, and failure notification.

Node-by-Node Architecture

The exact list of workflow nodes will depend on the release, product family, and environment, so validate the available nodes in your target pod. As a design pattern, the workflow might look like this.

Trigger

Start with the event that begins the process.

This might be a user action, an uploaded file, an email, a scheduled trigger, or an external invocation. The trigger should capture only the information required to start the flow.

For this scenario, the trigger might include:

  • Requester identifier
  • Quotation document
  • Business unit
  • Optional supplier name
  • Optional requested delivery date

Avoid making the trigger carry the entire enterprise context. The workflow can retrieve authoritative data later.

Document Processor or Input Extraction

The quotation is usually unstructured. Use a document processor or extraction step to convert the document into text or structured fields that downstream nodes can use.

The goal is not to make a final business decision here. The goal is to extract candidate values.

{
  "supplierName": "Vision Supplies",
  "quotedAmount": 12500,
  "currency": "USD",
  "items": [
    {
      "description": "Laptop docking station",
      "quantity": 25,
      "unitPrice": 500
    }
  ]
}

Treat this as extracted input, not verified truth.

Business Object Function

Once values have been extracted, use Business Object functions for authoritative Fusion data when available.

This is where the workflow should retrieve or validate things like requester preferences, supplier information, valid currencies, units of measure, procurement categories, or draft requisition creation.

The design principle is simple: if Fusion owns the data or action, prefer the Fusion business object capability over a generic REST call.

That keeps the workflow aligned with the application model and reduces unnecessary integration logic.

RAG Document Tool

Some decisions depend on policy, guidance, or reference content rather than transactional data.

For example, the workflow may need to retrieve purchasing policy guidance for supplier onboarding, spend thresholds, restricted categories, or approval requirements. This is a good use for a RAG Document Tool or retrieval step.

Keep the retrieval focused. Ask for the specific policy evidence needed for the decision. Do not pass entire policy libraries into an LLM node.

Oracle vector node guidance makes a similar point for enterprise knowledge: keep retrieval precise, use metadata filters, validate retrieved results, and add fallback logic when retrieval is weak or empty. See Vector Write and Read Nodes for the related pattern.

LLM Node

Use the LLM where reasoning, language understanding, or transformation is useful.

Good LLM node tasks include:

  • Extracting structured data from messy text
  • Mapping quotation text to a draft JSON structure
  • Summarizing policy evidence
  • Producing a user-readable explanation
  • Normalizing ambiguous descriptions into a controlled format

Poor LLM node tasks include:

  • Acting as the only source of truth
  • Making final approval decisions without controls
  • Performing deterministic calculations that code should handle
  • Holding large raw payloads when smaller structured input is enough

A useful design test is this: would I be comfortable explaining this node behavior to an auditor? If not, the node is probably doing too much.

Code Node

Some transformations should be deterministic.

For example, use code or rule-based logic to normalize strings, validate required fields, calculate thresholds, remove unsupported fields, or shape a payload before submission.

Do not ask an LLM to do work that should be exact every time.

IF, Switch, Loop, and Parallel Control

Branching is where the workflow becomes a process rather than a prompt.

Use IF or Switch logic for routing decisions such as:

  • Supplier found vs. supplier not found
  • Amount below threshold vs. amount above threshold
  • Policy evidence found vs. no policy evidence found
  • Draft requisition created vs. creation failed
  • Approval required vs. approval not required

Loop and parallel control should be used carefully. They are useful when the process naturally repeats across a bounded set of records or can safely perform independent work in parallel. They should not be used to hide an unclear process model.

Oracle 26A readiness content groups workflow nodes into categories such as AI, Communication, Data, Logic, and Workflow Control, including nodes like LLM, Agent, RAG Document Tool, Send Email, BO Function, External REST API, Code, Human Approval, IF, Loop, Switch, Run in Parallel, and Return. Those categories are useful because they reinforce that the agent is not one large reasoning step. It is a coordinated sequence of specialized steps. See Fusion AI Agent Studio 26A readiness content for release-specific details.

Human Approval

Approval nodes are important because not every action should be fully automated.

Use a human approval step when the workflow reaches a risk boundary. Examples include high-dollar purchases, new suppliers, restricted categories, low-confidence policy retrieval, or payloads generated from incomplete quotation data.

This is not a weakness in the automation. It is part of the control model.

The workflow should make the approver job easier by presenting:

  • Extracted request details
  • Supplier validation result
  • Relevant policy evidence
  • Draft action to be taken
  • Reason approval is required

The approval step should not be a vague “please review.” It should be a structured decision point.

Send Email or Return

Finally, return a clear outcome.

A successful run might return the draft requisition number, supplier name, amount, approval status, and next step.

A failed run should return the reason, the failed node or category, and what the user can do next.

{
  "status": "FAILED_SUPPLIER_VALIDATION",
  "message": "The supplier from the quotation could not be matched to an active supplier.",
  "nextStep": "Review supplier name or initiate supplier onboarding."
}

That output is much more useful than a generic apology.

Choosing the Right Node for the Job

A common design challenge is deciding which node should own each part of the process. Here is a simple decision guide.

  • Use a Business Object Function when the workflow needs authoritative Fusion data or an action against a Fusion business object.
  • Use an External REST API when the workflow needs a non-Fusion system, custom service, or external validation endpoint.
  • Use a RAG Document Tool when the workflow needs evidence from policy, procedure, knowledge, or reference documents.
  • Use an LLM Node when the workflow needs language reasoning, extraction, summarization, mapping, or explanation.
  • Use a Code Node when the workflow needs deterministic transformation, validation, formatting, or payload shaping.
  • Use an Approval Node when the workflow crosses a business, financial, compliance, or confidence boundary.
  • Use IF, Switch, Loop, Run in Parallel, and Return nodes to control execution rather than relying on the model to decide the entire path.

The design objective is not to use every node. The objective is to use the smallest set of nodes that makes the process clear, testable, and supportable.

Design Anti-Patterns to Watch For

A workflow agent should make a process easier to understand, test, and govern. The anti-patterns below tend to show up when a promising demo is moved toward production without enough attention to process boundaries, system ownership, and operational behavior.

The LLM Does Everything

This is the most common anti-pattern.

The workflow starts with a large prompt and keeps adding responsibility to it. The LLM extracts data, validates policy, chooses tools, decides routing, builds the payload, handles exceptions, and writes the final response. That may look efficient in a demo because so much behavior is concentrated in one place. In production, it becomes hard to test, hard to troubleshoot, and hard to explain.

The better pattern is to separate responsibilities. Use workflow logic for sequencing and routing. Use Business Object functions or REST APIs for system access. Use retrieval tools for grounded evidence. Use code nodes for deterministic transformations. Use the LLM where language reasoning adds value.

For example, consider a purchase-request workflow that receives a supplier quotation. The anti-pattern is to ask one LLM prompt to read the quote, determine whether the supplier is valid, decide whether approval is required, create the requisition payload, and tell the user the result. A better design would extract candidate values, validate the supplier through an authoritative system call, retrieve any required policy evidence, branch deterministically on approval thresholds, and use the LLM only where summarization, mapping, or explanation is needed.

This is also where modular design becomes important. In Designing Modular Agentic Experiences: Context Passing in Fusion Agentic Apps, Yilmaz Ozturk describes how agentic workflows can become mega-workflows as teams keep adding interpretation, retrieval, disambiguation, drill-down, and downstream actions into one experience. That same warning applies here: a workflow agent should be composed around clear boundaries, not grown into a monolith.

REST API Used Where Business Object Access Is Available

REST APIs are useful, especially when the workflow needs to reach a non-Fusion system, custom service, or external validation endpoint. But REST should not be the default just because it is familiar.

If the workflow is operating on Fusion-owned data or actions, first evaluate whether a Business Object function is the better fit. Business Object access keeps the design closer to the application model and can reduce the amount of custom integration logic the workflow has to own.

For example, if a workflow needs to validate a supplier before preparing a draft requisition, the anti-pattern is to call a broad REST endpoint, return a large supplier payload, and then ask the LLM to decide whether the supplier is usable. A better pattern is to use the appropriate Business Object function, return only the fields required for the decision, and branch based on clear attributes such as supplier status, business unit, or payment hold indicators.

The decision rule is simple: use REST when the process needs integration flexibility; use Business Object functions when the process needs authoritative Fusion business data or actions.

Full Payload Passed to the Model

LLMs do not need every field from every upstream system. Passing full payloads into the model increases latency, token usage, cost, and failure risk. It can also expose more sensitive or irrelevant data than the task requires.

The fix usually starts upstream. Select only the fields needed. Reduce page size. Paginate where possible. Filter before the LLM. If upstream controls are not enough, add a defensive payload-control step before the model.

For example, a supplier lookup may return addresses, contacts, sites, payment attributes, audit fields, descriptive flexfields, and status history. The workflow may only need supplier ID, supplier name, active status, business unit, and payment hold status. Passing the full response to the LLM is unnecessary and fragile. Shape the payload first, then pass the smaller structure into the model.

This is the same pattern discussed in Fusion AI Agent Studio: Handling Large Payloads Before the LLM, where a Business Object call returned a very large response and the full payload was passed into the model, causing a token-limit failure. The practical takeaway is directly relevant to workflow agents: constrain the payload before the LLM, and treat payload size as an architecture concern rather than a prompt-tuning issue.

Treating Ambiguity as Precision

Enterprise language is often ambiguous. A user may say “Acme,” “the Singapore supplier,” or “the quote from last week,” and there may be multiple valid matches.

The anti-pattern is to let the agent guess and continue the workflow as if it found the right record. That creates risk. The workflow may validate the wrong supplier, retrieve the wrong policy, draft the wrong transaction, or route the wrong approval.

A better pattern is to make ambiguity an explicit part of the process. Return a shortlist. Let the user choose. Then continue using a validated identifier rather than a vague natural-language label.

For example, a requester uploads a quote and says it is from “Vision.” The supplier lookup returns Vision Supplies US, Vision Services Ltd, and Vision Distribution Singapore. The anti-pattern is to pick the first result and continue. The better design is to present a structured shortlist with distinguishing attributes, capture the selected supplier ID, validate it, and only then continue to requisition drafting.

This is the core idea in Great Agentic Search Starts with Ambiguity, Not Precision, which frames ambiguity as a normal starting point for enterprise search: discover broadly, let the user disambiguate, then use the selected record ID for a confident drill-down. Workflow agents should use the same discipline when a downstream action depends on selecting the right business object.

Passing Full Business Context Between Experiences

This anti-pattern appears when one agentic experience hands work to another.

The first experience finds a record, retrieves a large response, enriches it, and then passes the full object into the next experience. That may feel convenient, but it creates tight coupling. It also makes the receiving workflow depend on data it did not retrieve, validate, or authorize within its own boundary.

A better pattern is to pass a pointer, not the data. Send the selected identifier and minimal intent. Let the receiving workflow validate the input and retrieve authoritative data through its own logic.

For example, a supplier search experience should not pass the full supplier profile, all site records, contacts, payment attributes, and recent transaction history into a requisition workflow. It should pass the selected supplier ID, entity type, and intent. The requisition workflow can then validate the supplier and retrieve only the fields it needs.

This is another place where the modular context-passing pattern is useful. The key design point from Designing Modular Agentic Experiences is that context should act as a pointer, not a payload. That keeps ownership boundaries cleaner and allows each workflow to enforce its own validation, authorization, and business rules.

No Failure Branch

Every meaningful system step can fail.

Document extraction may miss a required field. Supplier validation may return no match. A REST endpoint may time out. An approval may be rejected or a user may not have access.

The anti-pattern is to design only the happy path and rely on a generic final response when something goes wrong which makes the workflow hard to support because failures are not classified, routed, or recoverable. A better workflow has explicit failure behavior for each major step. The failure path might retry, route to manual review, ask for clarification, stop with a structured message, or continue with a lower-confidence branch.

For example, a quotation-processing workflow may extract the supplier and amount but fail to identify the requested delivery date. The anti-pattern is to let the LLM infer a date or continue with a blank field. A better design is to branch to a clarification step: “I found the supplier and amount, but I could not identify the requested delivery date. Please provide the date before I prepare the draft requisition.”

Failure paths should be designed as part of the workflow, not added after the first production incident.

No Approval Boundary

Some actions should not be fully automated, even when the workflow has enough data to perform them.

Approval boundaries are important when a process crosses financial, operational, compliance, or confidence thresholds. The goal of the workflow agent is not to remove every human decision. The goal is to make the decision faster, better informed, and easier to audit.

The anti-pattern is to let the workflow complete a sensitive action just because all required fields are present. Required fields are not the same thing as business approval.

For example, a workflow extracts a quote for $95,000, validates the supplier, finds relevant procurement policy, and prepares a draft requisition. If that spend level requires review, the workflow should route a human approval with the extracted quote details, supplier validation result, and policy evidence. It should not create or submit the transaction as if the amount were low risk.

A good approval boundary is specific. It should explain why approval is required, what evidence was used, and what action will happen if approved.

No Measurable Output

A workflow agent should produce more than a polished response. It should produce an outcome that can be measured, monitored, and supported.

The anti-pattern is to end the flow with a conversational summary such as, “I reviewed the quote and created the request.” That may be friendly, but it does not give operations, support, or business owners enough information to evaluate the process.

A better output includes structured status, identifiers, key decisions, and next steps.

For example, instead of returning:

Your purchase request has been reviewed.

Return something closer to:

{
  "status": "APPROVAL_REQUIRED",
  "supplierId": "300000123456789",
  "supplierName": "Vision Supplies US",
  "quotedAmount": 95000,
  "currency": "USD",
  "policyEvidence": "Capital equipment threshold exceeded",
  "nextStep": "Awaiting procurement manager approval"
}

That output can be logged, reported, monitored, and used by downstream processes. It also gives the user a clearer answer because the workflow can explain exactly where the request stands.

The larger point across all of these anti-patterns is the same: do not let the agent hide process design inside a prompt. Make the process visible. Keep context lean. Resolve ambiguity explicitly. Use authoritative data sources. Add approval boundaries where the business requires them. Then use the LLM where reasoning actually improves the flow.

Testing the Orchestration

Testing a workflow agent should look more like testing an integration flow than testing a chatbot.

Start with each node independently in order to validate that the trigger receives the expected input. Test document extraction with known quotation samples and business object lookups with valid and invalid suppliers. Be sure to test retrieval with policy documents that should match and documents that should not. Test LLM output with expected schemas, approval routing, and notification content.

Then test the full path. At minimum, include:

  • Happy path
  • Missing supplier
  • Invalid requester access
  • Missing required quotation field
  • Policy not found
  • Approval required
  • Approval rejected
  • Downstream action failure
  • Retry or fallback behavior

Don’t forget to test authorization. The workflow should run under the right access model, and users should only be able to trigger and view what they are allowed to access. AI Agent Studio access and external REST API tool usage have specific role and privilege considerations, so include security setup in the test plan rather than treating it as a deployment detail.

Finally, test latency and token usage. If a workflow passes large payloads into multiple LLM calls, the user experience and operating cost can change quickly. Smaller, more deterministic steps are usually easier to optimize.

Operationalizing the Flow

Once the workflow is working, treat it like an enterprise process.

Begin by documenting ownership to define who supports it. Capture release assumptions and track the nodes used and confirm they are available in the customer environment. Next, maintain test payloads and keep policy content current. Always review any failure logs and re-run evaluations after changing prompts, tools, documents, or business object mappings.

Importantly, you it helps to know beforehand what should happen when the process changes. For example:

  • Who owns supplier validation logic?
  • Who owns policy content?
  • Who approves prompt changes?
  • Who reviews failed runs?
  • Who updates the workflow after a Fusion quarterly update?
  • Who validates that the approval boundary still reflects policy?

Final Thoughts

A workflow agent is production-ready only when each node has a clear responsibility, each handoff has a clear payload, each failure has a path, and each outcome can be observed.

The LLM is still important, but it should be one controlled capability inside a governed flow. Use it where language reasoning, summarization, extraction, mapping, or explanation improves the process. Use workflow control, business objects, retrieval, code, approvals, and structured outputs for the parts that need to be consistent and supportable.

Review one existing agent design and look for places where the LLM is doing work that should be handled by workflow logic, Business Object functions, retrieval, code, approval, or failure handling. That is usually where the design becomes easier to test, easier to support, and safer to run in production.

Happy hunting!