Adaptive process orchestration

What is adaptive process orchestration?

Adaptive process orchestration runs one business process in which most steps follow fixed rules and a small number of steps are decided by a model or an agent. The flow keeps the sequence, the state and the controls. At the points where no rule can settle the case, it calls a model, gives it a short list of outcomes to choose from, and routes the case on whatever comes back.

The word adaptive covers one thing. The process can now finish a case that nobody drew on the diagram, without a person having to pick it up. The rest stays where it was. The order of the steps, the approval above a threshold, the retry after a timeout and the record of what happened are all still fixed, and still the same for every case.

Camunda's architecture guidance splits the two responsibilities in a single sentence. The model "decides which tool to call, in what order, and with which parameters". Camunda "executes the selected BPMN elements, stores process state, applies retries and incident handling, and coordinates user tasks and other deterministic workflow logic".

Repeatability and judgement pull against each other

A deterministic flow has one property that makes it worth having. Microsoft's description of an agent flow in Copilot Studio, dated June 2026, says it plainly: "Agent flows are deterministic. They execute actions or tasks following a rule-based path. The same input always produces the same output." That is why an accountant will sign off on it. Run the same case twice and you get the same steps, the same amounts and the same trail.

The same property is the limit. Every branch in the diagram was drawn by somebody who imagined the case in advance. The supplier who puts the credit note number in the subject line instead of the body, the customer who sends back one item out of a three-item order and explains why in a paragraph: those land in an exception queue, and a person clears the queue.

An agent clears cases like that. What you give up is repeatability. The entry on non-determinism in LLM output goes through where that variation comes from, and the short version is that the model samples its output instead of looking it up, so the same case tomorrow can produce a different order of tool calls, a different wording and sometimes a different answer.

The deterministic spine and the judgement slot

The arrangement that holds up in production keeps the spine of the process deterministic and puts the judgement in bounded slots.

What the flow keeps

The flow decides which step comes next and holds the state of the case: the case id, the variables, the step it is on and how long it has been sitting there. It runs the controls, so the approval above an amount, the separation between who requests and who approves, and the deadline that escalates are modelled in the process and not written into a prompt. It owns every write to a system of record, and it owns recovery: the retry after a timeout, the timer that waits three days for an answer, the compensating step when something later fails.

What a bounded slot has to define

A judgement slot is more than a line that says call the model here. It is a step with a contract, and the contract has four parts.

1. A defined input. Name the fields the model gets: the order line, the return reason, the delivery date, the customer's previous returns. Handing over the whole case object makes the step impossible to test and puts data in the prompt that has no business being there.

2. A closed set of outcomes. The step returns one value from a short list, say accept, refuse or hand to a person, plus a written reason. In UiPath Maestro an agent sits in the process as a service task whose output parameters are mapped to process variables, and the next gateway routes on those. An answer outside the list is an error for the flow to handle, not a fourth outcome.

3. A refusal path. The model has to be able to say that it cannot settle this one, and that answer needs a route of its own. Camunda's design guidance is direct about it: give the agent an escalation path to a person, and do not lean on a confidence score alone to decide when that path is taken.

4. A budget and a deterministic fallback. The slot gets a ceiling on how much work it may do and a defined route when it hits that ceiling. Camunda's AI agent sub-process caps the number of model calls, defaults that limit to 10 when you do not set it, and raises the error code MAXIMUM_NUMBER_OF_MODEL_CALLS_REACHED when the agent runs past it. You catch that on an error boundary event and send the case down the same path as a refusal.

Write the contract down before you write the prompt. The prompt will change ten times over a year. The contract is what the rest of the process was built against.

A return request with three fixed steps and one judgement slot

A webshop handles around 900 return requests a month. The return policy is 30 days. Roughly 130 requests arrive after day 30 with a written reason, and until now a customer service colleague read every one of them.

1. Fixed: check the request against the order. Look up the order line, the delivery date and the amount. Inside 30 days and unopened, the flow accepts the return with no model involved at all. Above 250 euro, the flow routes to a person whatever the rest of the case says.

2. Slot: settle the late request. The model gets six fields: the article, the amount, the days since delivery, the customer's written reason, the number of returns by this customer in twelve months, and whether the article is on the excluded list. It returns accept, refuse or hand over, with one paragraph of reasoning, and it has no access to the ERP. A pair of shoes sent back on day 38 because the zipper broke, from a customer with no earlier returns, comes back as accept with that reason on the record.

3. Fixed: create the credit note. On accept, the flow posts a credit note against the original order line. A single item of 89 euro posts 89 euro, because the amount comes from the order and never from the model.

4. Fixed: answer the customer. The flow sends the decision and, on accept, books the return label.

The fallback matters more than the happy path. If the model returns something outside the three outcomes, times out, or runs past its call budget, the error boundary event on the slot moves the case into the same customer service queue it used to sit in, with the case data and the partial reasoning attached. Nothing is lost and nothing is accepted by accident. A slot that fails should cost you the automation, never the case.

What you can prove afterwards

A flow with a judgement slot versus an agent that owns the process

Both arrangements can produce a correct outcome. They differ on what you can show a month later, when finance asks how one particular case was handled.

• Which steps ran, and in what order. With a slot, the sequence is the same modelled path for every case. With an agent that owns the process, the path is chosen during the run and differs per case.

• Where the decision was made. With a slot it sits in one named step, with its input and its outcome beside it. With an agent it can sit anywhere in the run, mixed in with the tool calls.

• What ran before the money moved. With a slot that is a modelled control the process owner can point at. With an agent it is whatever the agent decided to check that time.

The first answer in each pair comes from a process model that existed before the case did. The second comes from a transcript that only exists afterwards, which is why anything touching money, a payment or a credit note, tends to stay on the deterministic side. An agent-owned process also has no defined step list to resume from after a crash, which is what durable execution fixes by journalling every completed step.

What has to be in the record

A judgement slot has to write down more than "approved". Per call, keep four things.

• Which model answered. The OpenTelemetry conventions for AI calls separate the model you asked for, gen_ai.request.model, from the model that answered, gen_ai.response.model, and the two are not always the same once a provider routes traffic or retires a version.

• What it was given and what it returned: the input fields, the outcome, the written reason, the tools it called, and gen_ai.response.finish_reasons, which says whether the model stopped on its own or was cut off.

• Which version of the slot itself was live: the prompt, the tool list and the list of allowed outcomes in force at the time. A change to any of those is a release, and the record has to say which release decided the case.

• Who was allowed to override the outcome, and whether anyone did.

Prompt content and tool arguments are not captured by default in the OpenTelemetry conventions, precisely because they can hold customer data, so recording them is a decision you take on purpose with a retention period attached.

Testing and monitoring when one step is not repeatable

A regression test asserts one right answer. That works for the fixed steps and falls apart at the slot, because a run tomorrow may reach a defensible outcome by a different route. What you assert instead is a property that has to hold whatever the model says.

Property-based testing has done exactly this for years outside AI. The documentation of Hypothesis, the Python library for it, gives the example every finance person recognises: a sequence of transactions in a financial system always balances, money never gets lost. You do not check that one transaction produced one particular row. You check the books.

For the return process, the invariants read like this.

• Every case reaches a terminal state, and none sits in the slot for longer than a day.

• The credit note total equals the accepted order line total. The model never moves an amount.

• No order line is credited twice, however often the slot ran on it.

• No case above 250 euro closes without a human task in its history.

• Every recorded outcome is one of the three allowed values.

Run those against replayed historical cases and then against live traffic. An invariant that breaks is a bug you can act on, whatever the model happened to be reasoning about.

The judgement itself needs a second mechanism, because no invariant tells you whether accept was the right call. Sample it. Take a fixed number of slot decisions a week, have the process owner mark each one right or wrong, and follow that rate over time. Next to it, watch the mix: the share of accept, refuse and hand over per week, and how often the fallback fired. When the mix moves and the process did not change, something else did. Usually that is a new model version on the provider's side, or a change in the way customers write to you.

Both numbers belong on the same page as throughput and cost per case. A slot that gets cheaper by deciding more cases wrongly is not an improvement, and only the sample will tell you which of the two you have.

What to watch out for with adaptive process orchestration

Your flow does not need replacing. The useful version of this for a smaller company is narrow. Find the one or two steps where a colleague currently reads something and decides, and put a slot there. The other twenty steps stay exactly as they are. The step worth converting is the one with the longest queue in front of it and a decision a colleague can explain in two sentences.

Do not let confidence decide who gets a human task. The amount, the customer and the legal exposure decide that, in the process model where the owner can see the thresholds and change them. A confident model on a 50,000 euro case is still a 50,000 euro case.

Keep the model out of the system of record. It reads, it decides, it writes down a reason. The flow does the posting. Once a model writes to the ERP itself, you lose the thing the whole arrangement was for: one fixed answer to the question of what happened to the money.