The future of OIC Process Automation

For twenty years we automated processes by drawing every possible path in advance. Agents now let us describe the work instead, and put determinism only where it earns its place. This paper lays out the patterns in use today, the architecture we believe all of it converges on, and how Oracle Integration gets you there by reusing what you already run.

The arrival of agents

Business process management gave us a shared language. BPMN turned a whiteboard sketch into an executable model: a lane for every owner, a diamond for every decision, and a task for every step. CMMN followed for work that refused to be sequenced: a case worker chose the order, but the tasks were still modeled ahead of time. Both standards therefore rest on the same premise: someone has to anticipate the possibilities in advance, and update the model when the business changes.

Until recently, the limits of software left no other way to model processes, so automation took the well-travelled path, and the judgement calls, the incomplete inputs, the customer whose case fit no template stayed manual. When the business changed, updating the process definition often required IT involvement and funding for a new project.

The arrival of agents changes this. An agent is a language model put to work: given a clear goal, a written procedure, a set of reliable tools and a boundary for when to stop, it can read a situation and reason its way to the outcome the business wants. It can carry a case through a process it has never seen drawn, weigh the variables in front of it, and ask for help at the points the business chooses. This changes what a process model is: no longer a description of the path, but a description of the goal, the surrounding context, the tools the agent may use and the limits it must respect.

The case for agents is compelling, but their adoption is uneven. In customer estates today we see two patterns: deterministic flows, which increasingly invoke an agent as a step, and probabilistic flows, where the agent holds control. We expect both to converge on one architecture, and we are building Oracle Integration (OIC) to be the platform for it. The rest of this paper covers what agents change for the business, the architecture the patterns converge on, and how the processes you already run map onto it.

What agents change

Set the technology aside for a moment. What matters to the business is that three things get better.

The business owns the process

Today a process definition is a developer artifact. The business can read it and sign it off, but cannot change it. The procedure an agent follows is prose. It reads like the guidance you would hand a capable new hire on their first day: what the goal is, what done looks like, which thresholds apply, what to do when the purchase order is missing, when to escalate. The people who understand the work can write it, review it and change it. For the first time, the process belongs to the people who run it. The division of labour is clear: the business owns the procedure, engineering owns the tools and the controls around them. Earlier attempts to give the business this control, from business-readable notations to low-code designers, drifted back to IT because the artefact still had to be complete and precise in the machine’s terms. A procedure does not: it is written in the form the business already uses to describe work.

Complexity gets handled

Every process has its exceptions: the misspelled vendor name, the invoice that cites two purchase orders, the dispute that is part billing error and part late delivery. They are where the real complexity of a process lives, and a modeled process cannot handle what it did not anticipate, so they go to a human task queue, and the queue is where most of the cost and delay in a process actually sits. An agent takes the case as it finds it. It reads the invoice, checks the vendor record, weighs the two purchase orders, and either resolves the case or hands it to a person with the groundwork done. Fewer exceptions reach people, and the ones that do arrive framed rather than raw: the person sees the case, what the agent found, what it recommends and why, and the one decision it needs from them. The exception queue stops being where work is investigated and becomes where it is decided. That is the difference between automating the easy cases and automating the full process.

The process grows with the business

When policy changes, a new supplier category appears, or a regulator asks for an additional check, a modeled process has to be redrawn, re-mapped, retested and redeployed, and that work sits with developers. An agent-led process changes where the know-how lives: in the procedure, which the people who own the process rewrite themselves, and the agent follows the new version from the next case. The feedback loop tightens too. Every human override of the agent’s recommendation shows where the procedure is incomplete, and it can be folded into the next version in a day rather than a release cycle. The process stops being something you rebuild and becomes something you tend.

None of this removes the need for control. It relocates it. The old model controlled risk by refusing to automate anything uncertain. The new one controls risk by choosing, per step, how much judgement to delegate and where a person must be accountable.

Agent patterns in use today

Walk through any customer’s process automation estate this year and you will find two ways of automating work: a flow that owns control, or an agent that does.

Deterministic

The process engine is in charge. Every branch is a gateway, every call to another system is a service task, every rule is a decision table, every human step is a task in a queue. It is fast, cheap to run, fully testable and predictable, which is why it still carries the bulk of transactional volume: payment runs, order confirmations, employee onboarding or anything where the logic can be written down in full and the cost of a wrong answer is high. Increasingly these flows invoke an agent as one of their steps, to extract fields from a document or classify a request, but the flow keeps control, so the pattern is unchanged. Its weaknesses are the ones described in the previous section: complexity it did not anticipate goes to a queue, the people who own the process cannot change it, and every change is a project. Neither cost is abstract. The first is the headcount in the exception queues; the second is the change requests waiting on IT, and most organisations can put a number on both.

Probabilistic

The agent is in charge. It receives a goal and a case, reads the procedure, and does everything that touches a system through deterministic tools: integrations, decision tables, knowledge lookups, human approvals. The probabilistic part is the agent’s judgement about which tools to call, in what order, and what to make of the results; the deterministic part is the tools themselves, and they behave the same way every time. The pattern succeeds because it combines the two disciplines rather than choosing between them: judgement from the model, reliability from the tools. Latency and cost per case are higher, and the path through any two cases may differ, but in exchange the process covers the cases the old model could not: high-variance, judgement-heavy work like dispute resolution, complex onboarding, supplier queries and service triage.

Choosing between the two

Two patterns means a choice for every process. The teams making it well are not asking “should this process be agentic?” They are asking a handful of questions about each process, and usually about each step within it.

The answers rarely place a whole process in one pattern. They place steps. That is the observation that leads to the architecture in the next section: a process is a mix of steps that should be deterministic and steps that should be reasoned, and the right design is one where the mix is a configuration choice rather than a re-platforming decision.

The end state

Our view is that the two patterns converge on a single architecture: one where an agent leads every process, and the deterministic work is packaged into the tools it calls. In this architecture the key is how much work sits inside each tool. Give the agent a few large tools, each running a whole sequence of steps, and the process behaves like a deterministic flow: the agent decides little. Give it many small tools, each doing one thing, and the agent does the orchestration. Same architecture, same agent, same governance. The only thing that moves is how much autonomy sits with the agent, and that is a setting the business chooses.

Saying that clearly matters, because it frames every investment. Nothing built for the deterministic pattern is wasted; it becomes tooling. Nor does the architecture require you to hand a finance process to an unconstrained model. You decide, per step, how much the model touches.

Skills and instructions

An agent carries two layers of instruction. Its own instructions define who it is: its role, how it behaves and how it uses its tools. They describe the agent, not the process, and they rarely change. The skill defines what process it is running, and it is the component that most changes who can shape it. Skills contains what you would tell a competent new hire: the goal and what “done” means; the policies and thresholds that apply; the usual order of operations, stated as guidance rather than as gates; the known edge cases and how to handle them; and the explicit conditions under which the agent stops and asks a person. It is written in prose and versioned like any other artefact, and before a new version is promoted it should be run against a library of known cases with known right answers. That practice answers the most common objection to procedure-based automation, that prose cannot be tested. It can, in the same way a person’s competence is tested: give it the cases and check the outcomes. Keep that library with the procedure; every exception a person resolves is a candidate for updating it.

Tools

Tools are the agent’s hands, and every one of them is deterministic. This is where the risk model becomes concrete, because the size of a tool is a design choice.

Deterministic integrations. A tool can be a single call (“look up purchase order 4471”) or an entire orchestration (“run the three-way match, apply the tolerance, post the invoice, return any exceptions”). The second is five interactions wired together in an integration, tested and versioned, doing the same thing every time. The agent never sees the five steps; it sees one verb. That choice is the autonomy dial. For high-volume, regulated, well-understood work, put the orchestration in the tools: the agent classifies the case, chooses the right tool and handles the exceptions, and everything else runs deterministically. For novel, judgement-heavy, low-volume work, expose the individual services and let the agent sequence them, reasoning at each step. Most processes sit somewhere between the two, and where they sit can change as confidence in the agent grows. The boundary is a configuration decision, not an architecture decision, which is precisely what a flowchart never allowed.

Human in the loop. HITL stops being a swimlane and becomes a tool the agent calls. The agent requests a decision, and the request should always carry a recommendation, the reasons for it, and the evidence the agent used: the case, what it found, which policy applies, what it proposes. A person approves, rejects, amends or sends it back, and the agent continues. Sequences of human steps are modeled as one workflow rather than stitched together: tiered approval when a decision escalates through levels by amount or risk, parallel approval when several parties sign at once. What the approver sees is what determines whether the human step adds judgement or just adds latency: a raw case makes them investigate; a framed one lets them decide. Every override should be recorded and fed back to whoever maintains the skill.

Knowledge base. Policies, contracts, product data, prior cases, the reference material a person would look up. The agent does not hold all of it; it retrieves the relevant piece for the case at hand, at the moment it needs it. This is what grounds the agent’s reasoning in the organisation’s actual rules rather than the model’s general knowledge, and it is what keeps the procedure short: the skill says “apply the payment-terms policy”, the knowledge base contains the policy.

Decisions. Structured, business-owned rules that should produce the same answer every time: match tolerances, approval limits, eligibility criteria, routing by region or category. These belong in a decision model, not in the procedure and not in the agent’s judgement, because they are exactly the class of logic that can be enumerated completely and that the business changes on its own timetable. The agent calls the decision; the business owns the table.

MCP Apps. People enter an agent-led process at two points: at the start, when someone submits a request, and in the middle, when an approver reviews what the agent has done and acts on it. Both need more than a message. MCP Apps are the interactive surface for those moments, rendered from the result of a tool the gateway exposes and returning a structured answer: a request form that captures what the agent needs to begin, an approval view that shows the case, the recommendation and the reasons, with the approve, reject and send-back actions on the same screen. The same surface serves the in-flight questions an agent puts to a person, such as choosing between candidate purchase orders or correcting extracted fields.

Tool governance

Tools are how an agent interacts with the enterprise: every system it reads, every record it changes, every person it asks, it reaches through a tool. That makes the tool layer the place where control has to sit. An MCP Gateway is the single point through which agents reach tools, and it governs that access in three ways. First, it controls what each agent can see and call: tools are filtered per agent, and role-based access applies to agents in the same way it applies to people, so an accounts-payable agent never discovers a payroll tool, let alone invokes it. Second, it applies security policy to the traffic passing through it, detecting and masking personal data in tool requests and responses, so what reaches a model or leaves a system is what policy allows. Third, it applies business policy: when an agent takes an unusual action, such as a call outside its normal pattern, a value above a threshold, or a volume that does not fit the case, the gateway notifies the people who own the process. Every invocation is recorded, which gives the organisation observability over its agents: what each one did, with which tool, on which case, and why. When an agent gets something wrong, that record is how the organisation finds out, and the correction goes into the procedure or the policy rather than waiting for the next complaint. One place to see, one place to set policy, regardless of how many agents or tools exist.

Does every flow need an agent?

Even a flow whose logic can be written down in full belongs in this architecture for three reasons. Start with exceptions. The happy path may be deterministic, but no real flow is only its happy path: there are always cases the logic never anticipated, and today every one of them lands on a person. Put an agent at the edge of the flow and those cases go to the agent instead, while the deterministic work carries on in tools exactly as before. Then there is change. Because the flow is built as tools behind an agent, the line between them can move later without re-platforming: cut the same work into finer-grained tools and the agent takes on more of the orchestration; cut it into coarser ones and it takes on less. The procedure holds the policy at the edges, and that part the business changes itself. Finally, governance. When every flow reaches its tools through the same gateway, policy is enforced once and observability covers everything, rather than each flow carrying its own. How much the agent does in any one flow is the business’s call, and for a flow like this it may be no more than handling the exceptions. What matters is that every flow in the estate handles exceptions, absorbs change and is governed the same way.

Building it on Oracle Integration

This is the future we are building for in OIC, and the reason we can describe it this concretely is that each component above already has a home on the platform.

Where your existing processes live now

Most customers reading this have a body of structured (BPMN) and dynamic (case-style) processes in production. The instinct is to ask which tool they migrate to. The better question is where each element of those models belongs in the architecture, because a BPMN diagram always mixed three concerns in one drawing: logic control, automated action, and human intervention. Modernising is the act of giving each its own home.

A worked example: accounts payable invoice processing

Take a typical BPMN model for supplier invoices. It is a good test because it is neither trivial nor exotic; almost every enterprise runs some version of it.

The model as it stands. An invoice arrives by email or portal. A service task extracts header and lines. A validation task checks the vendor against the master. A three-way match compares invoice, purchase order and goods receipt. A gateway tests the match; failures go to an AP clerk’s task list, who investigates and re-submits. A second gateway routes anything over ten thousand to a manager, then a controller, in sequence. The invoice is posted and scheduled for payment. On paper it is clean. In operation, a substantial share of invoices fail the match for reasons that have nothing to do with fraud: a PO number missing from the invoice, a partial delivery, a unit-of-measure difference, a vendor name spelled differently on the invoice and in the master. All of those land on the clerk, and the clerk’s queue is the process’s real cycle time.

The procedure. The skill for the AP agent runs to about a page. Its goal: every valid supplier invoice posted within terms, with no invoice posted twice and nothing over the threshold posted without approval. Its guidance: run the match; if it fails, work out why before escalating. If the PO reference is missing, search open purchase orders for the vendor by amount and date; if exactly one fits, use it; if several fit, present them to AP. If the mismatch is a partial delivery, match against received quantity and hold the balance. If the vendor name does not match exactly, check the tax id and bank details from the knowledge base before treating it as a new vendor. If anything suggests a duplicate, hold and flag. Never post over the threshold without the tiered approval outcome. The people who wrote that page were the AP team leads, because it is what they already told every new clerk.

The tools, and where the dial sits. This is a high-volume, regulated process, so the orchestration sits in the tools. Intake is an integration tool that picks invoices up from where they already arrive, the mailbox and the supplier portal, and starts the agent. Extraction, vendor validation and the three-way match are a second integration tool: the agent calls “match invoice” and receives a structured result with a reason code on failure. Posting and payment scheduling are a third integration tool, and that integration checks for a recorded approval outcome before it executes for anything over the threshold. Match tolerances by spend category and the approval tiers by amount are Decisions, owned by finance. The payment-terms policy and vendor contracts sit in the knowledge base, retrieved when the agent needs to reason about terms or identity. The MCP App is where people meet the process when the process needs them. Approvers act through it, and the agent presents candidate purchase orders there when it needs a clerk to choose, because three options on one screen is faster and safer than a message thread. It is also the intake for the ad hoc invoice, which a person submits through the app and which then runs through exactly the same procedure and tools as everything else. The tiered approval is a single HITL workflow, manager then controller, and the agent’s request carries its recommendation and the reasons for it, so the approver is deciding rather than investigating.

What changed, and what did not. The agent’s judgement is confined to reading the invoice, choosing which path to take through the procedure, and framing the exception for a person when it cannot resolve it. Every action against the ERP system is deterministic and identical to what the old service tasks did. The approval chain is the same people in the same order, with better context. The audit trail is richer: every tool call is logged under the invoice’s correlation id, the agent records why it chose each path, and every human decision is captured with what the agent recommended. The clerk queue, which was the process, now holds only the exceptions the procedure does not yet cover, and each one that reaches a person is a candidate edit to the procedure. Over three or four revisions that queue gets short. That is what “the process grows with the business” means in practice. What it took to get there is also worth stating: one procedure, written by the AP leads in a day; three integrations, two of which already existed; one Decisions table; one HITL workflow; one app. The systems were already connected, the rules were already known, the approvers were already named. None of that had to be built again.

The same decomposition applies to a dynamic process. A customer dispute modeled as a case, with stages, milestones and discretionary tasks, maps even more naturally: the stages become the skill’s definition of done, the discretionary tasks become the agent’s latitude, the milestones become the points at which it reports or asks, and the dial sits further toward the agent because the volume is lower and the variance is higher.

Key takeaways

It would be easy to read this paper as an argument to move from one technology to another. The argument is different: what changes is not the tooling but what a process actually is. The diagram was our best guess at the work. A procedure with tools and boundaries is a description of it. Moving between them is the act of separating logic, action and human intervention that were always tangled together in one drawing, and giving each a home built for it. The value is the one set out at the start: the process belongs to the people who run it, the exceptions get handled instead of queued, and the process keeps pace with the business without a project each time. Three things follow:

1. Better architecture

Orchestration, business policy, human work, context and judgement each get their own place instead of sharing one diagram. That separation is also what gives you control over autonomy, per step: put determinism where it earns its keep, judgement where it is needed, and move the boundary later without re-architecting. Wherever a named person must own an outcome, a HITL step holds it, however much autonomy the agent has. Because everything an agent does passes through the tool layer, one gateway governs what it can reach and records what it did.

2. More valuable automation

Agents take on the work a diagram could never hold: reading the situation, handling the exception, deciding the next step. The measure is what changes for the business: the process owners can change the process themselves, the exceptions that used to sit in a queue get handled, and the process keeps up with the business without a project each time.

3. A practical transition

Nothing you built is wasted: the estate you run today is the tool layer of the estate you will run tomorrow. There is no need for a portfolio-wide programme. Start where the exception queue is longest and the maintenance heaviest: the processes already due for change, dominated by exception handling, or being extended with AI anyway. Write the procedure with the people who own the process. To begin with, have the agent recommend and a person confirm, and treat every override as an edit to the procedure; when people stop overriding it, let it act on its own.

This is the architecture we would build new process automation on today, and increasingly the one we would move existing automation towards. Every component it needs already has a home on the platform. The transition is practical for a reason that is easy to overlook: the hard part of automating a process, connecting the systems, discovering the rules, agreeing who approves what, was done when you built it the first time, and none of it is lost in the move. What changes is how little process it now takes to express what you already know.

For the next process on your backlog, do not start with a process diagram. Start with the work: what can be enumerated, where judgement enters, and where a person must be accountable, then build the simplest arrangement of tools, procedure and workflow those answers require. Ask the same questions of the processes you run today, and let the answers, not a platform mandate, decide which one comes first.