Go with the (work)flow or wing it? Oracle AI Agents

I want to talk about the advantages and disadvantages of Workflow AI Agents versus the traditional Hierarchical (teams/chatbot) agents. In Oracle (and all platforms, really) the paradigm looks to be shifting to more workflow agents. It seems obvious why… right? More deterministic outcomes, less token usage, maybe it can even go grocery shopping for me.

It’s not so simple. Sometimes our traditional hierarchical agents can be more powerful. What makes them strong is the tools they can use and how they are configured.

Policies in the Workplace

Let’s say that I want to understand a specific policy in my workplace: how many PTO days I have.

Normally, I would troll through the companylLeave & absence policy documents to find what I’m looking for. But what if we made a workflow for it? What would it look like?

Exhibit 1: Notice how many touch points I use tokens.

Taking a step back for a moment, the agent is pretty cool. It can complete the task. However, there’s a lot of touch points for tokens to be used. Also, is searching for an answer in a document as simple as if A then B (more on this logic later)?

Before we answer the question, let’s redesign the agent as a normal chatbot agent to compare.

Exhibit 2: Notice only two touchpoints for token usage.

Here, we see a more condensed flow.

Side note: don’t focus on the design of either agents, both styles can be made differently. Instead, focus on the logic behind using the two agent styles for the use case.

So, is the answer to which agent style is better for answering leave and absence policies clear? It shouldn’t be.

Why isn’t it clear?

The reason the answer to our earlier question isn’t obvious is because simplicity should not be assumed as an easier solution. Neither should complexity. Instead, there are two major qualities that drive decision making: accuracy and token usage.

Accuracy is how well the agent completes the task. Token usage is literally how much the agent costs to use. Let’s dive into it

Token usage is straightforward to reason about. Look back at Exhibit 1 (the workflow agent). Every node that touches the LLM burns tokens: parsing the user’s question, classifying it, searching the document, extracting the answer, formatting the response. That’s potentially five or six LLM calls for one question. Now look at Exhibit 2 (the chatbot agent). The user asks a question, the agent retrieves context from the document via RAG, and the LLM generates a response. Two touchpoints. For a simple policy lookup, the chatbot agent is significantly cheaper to run.

But here’s where it gets interesting. Accuracy doesn’t follow the same pattern.

Remember when I said “is searching for an answer in a document as simple as if A then B”? Let’s unpack that. Leave and absence policies are deceptively complex. How many PTO days do you get? Well, it depends. Are you salaried or hourly? How long have you been with the company? Are you in California, where the rules are different? Are you part-time?

Let’s work through a more complicated workflow agent design handling this logic.

Specifically, branching logic:

IF tenure > 5 years, THEN 20 days. IF location = California, THEN apply state accrual rules.

The problem is that you have to anticipate every branch. If a user asks “do my unused PTO days roll over?” and you didn’t build a node for that, the workflow either fails or gives a wrong answer. You’ve hardcoded the happy path, and policy documents are full of unhappy paths.

The chatbot agent, on the other hand, just searches the document. It doesn’t need you to pre-map every possible question. It retrieves the relevant section and lets the LLM reason over it. For unstructured, nuanced questions about a policy document, this flexibility is a real advantage.

Flipping the Script

Let’s change the scenario. Instead of answering questions about a policy, let’s say we want to process an invoice. The steps are well-defined: receive the invoice, extract the supplier name and amount, validate it against a purchase order, flag discrepancies, and route it for approval.

This is where workflow agents shine. Every step is deterministic. The order matters. You don’t want the LLM deciding whether to validate before extracting, or skipping the approval step because it “reasoned” it wasn’t necessary. You want control. You want auditability. And because each node does one specific thing, you can optimize token usage by only calling the LLM where you actually need reasoning (like extracting data from an unstructured PDF) and using code nodes or business object functions for everything else.

Oracle’s own documentation puts it well: workflow agents sit on the deterministic end of the agentic spectrum, but they bring agentic behaviors like dynamic path selection and multi-agent collaboration where needed.

Putting it Together

What I’m getting at with all of this is that there is a lot of nuance to understand which type of agent is better to use. However, there are ways to make the decisioning easier.

Let’s walk though some scenarios and try to think which agent type would be better here.

1. A structured/streamlined with a definable number of outcomes
2. A high reasoning activity that could lead in multiple directions
3. An agent to review information and drive a decision

Let’s talk through them.

For 1. the answer is likely to be a workflow agent? Why? because it’s more deterministic.

For 2. the answer is likely to be hierarchical. It has more “creative” outcomes.

But what about for 3.? Not so simple is it? We can think of this recursively by driving to requirements and reframe in terms of scenarios 1. and 2. Doing so can help us as agent developers drive structured designs for our agents.

Conclusion

So, what’s the answer? It’s the question itself. The fact that you’re asking “which agent style should I use?” means you’re already ahead of most people building agents today. Too many teams default to one pattern because it’s what they know, not because it’s what the task demands. The real work isn’t building the agent. It’s designing the task. Once you understand the shape of the problem (is it structured or open-ended? are the steps predictable or not?), the agent style can be driven by answering these questions. Accuracy and token usage aren’t competing priorities. They’re design constraints. And like any good design, the best solution is the one that respects both.

So, go with the workflow or wing it? Depends on the task. And that’s the whole point.

Bonus

I talked earlier about using an If A then B logic structure. That’s in testing at Oracle right now! They’re working on the Policy Tool, which will search through policies and create rules. It’s heavy upfront token usage to parse the document and create rules, but lower going forwards.