An AI Agent Can Run the Workflow. It Should Not Own the Control Model.

Introduction

Camunda 8.9 now states the split plainly. In its agentic-orchestration architecture, the LLM decides which tool to call, in what order and with which parameters, while Camunda executes the selected BPMN elements, stores process state, applies retries and incident handling, and coordinates user tasks and deterministic workflow logic.

Microsoft’s Agent Framework has moved in the same direction. Its workflow guidance, updated August 25, 2026, describes workflows as explicit, inspectable execution paths for coordinating agents, code, state, events and human input. UiPath is making the boundary configurable at an even finer level: its August 2026 Maestro release lets individual MCP tool arguments be chosen by the agent at runtime, bound to an agent variable or fixed in configuration.

The products differ substantially, but the architectural direction is useful. Agents can gain more freedom to select tools, revisit earlier work and decide what information they need next while the durable business process remains explicit outside the model’s reasoning loop.

For an AI agent workflow control model, the relevant boundary is not simply agent versus workflow. It lies between runtime judgment and the process contract that still has to make sense when the model changes, a run is retried, a human intervenes or the agent stops making progress.

At a glance

• Current agentic-orchestration platforms increasingly separate model-selected actions from durable workflow state and execution control.
• An agent can choose among allowed next actions without becoming the only place where process transitions, waits and terminal states are defined.
• A control model should remain inspectable without reconstructing the agent’s conversation or chain of tool calls.
• Dynamic routing can operate inside bounded regions while timers, human tasks, retries and lifecycle state remain external.
• The design test is whether the process can still explain where it is, what may happen next and how it recovers if the agent is replaced or fails.

Tool choice can be dynamic while process state stays durable

Camunda’s current architecture is unusually explicit about this division. Its AI-agent execution model lets the model choose BPMN elements as tools, call them in different orders, repeat them or skip them. Camunda retains execution of those elements, process variables, retries, incidents, events and human tasks.

An agent can therefore decide that it needs a carrier quote before checking warehouse capacity without forcing its internal plan to become the workflow’s durable state. The surrounding runtime still knows which case is active, which variables have been persisted and how a failed activity is represented.

Microsoft exposes a similar distinction from a software-development angle. Agent Framework workflows connect typed executors through explicit edges and conditions, while workflow capabilities include state, checkpoints, human interaction and agents participating as executors. Reasoning-heavy steps can remain agentic without requiring the same model loop to carry the lifecycle rules of the process containing them.

A shipment-recovery agent can improvise without defining the whole process

Consider an enterprise shipment-recovery process triggered when a carrier reports that a high-priority order will miss its delivery window.

An agent can investigate dynamically: it might query alternate carriers, check transfer options between distribution centres, compare revised arrival times, request more detail from the current carrier and ask a specialist agent to assess customer impact. The order of those investigations does not have to be fixed in advance.

The surrounding workflow still needs durable meaning for states such as disruption detected, recovery in progress, customer response pending, booking confirmation pending, resolved and escalated. Timers, retry behaviour and the event that moves the case out of recovery also need somewhere explicit to live.

Suppose the agent identifies a replacement carrier and submits a booking request. If the carrier never confirms, the business process cannot remain dependent on whether the agent remembers to ask again. A timer can wake the workflow, record the failed booking and re-enter the agent with updated facts or move the case to another defined step.

That arrangement preserves improvisation inside the recovery work while keeping the lifecycle of the shipment case independent of the model’s memory of what it intended to do next.

The process contract has to outlast the agent’s changing plan

Agent plans are useful precisely because they can change. A model can revise a sequence after a tool result, abandon an unproductive route, call a specialist or stop early when it has enough evidence.

Treating that mutable plan as the workflow control model creates a different problem: the business process becomes whatever the model currently believes should happen.

The process contract has a narrower job. It defines durable states, permitted transitions, waiting conditions, completion conditions and the points at which control leaves an agentic region. It can also define what happens when that region times out or terminates without a usable result, allowing the agent to adapt inside a boundary visible to the rest of the system.

UiPath’s current Maestro direction shows how far dynamic coordination can extend without eliminating explicit process structure. In Maestro Case, a Case Manager agent can participate in deciding which work should become active, while the case model still retains explicit stage entry, completion, exit and re-entry rules, together with required-stage and required-task conditions. UiPath’s July 17, 2026 release also added Case Manager decision traceability, including cycle indexes and ordered events leading to a decision.

The agent can therefore influence the route through the case without making its current plan the only surviving definition of that case.

Human review has to exist as durable workflow state

Agentic systems sometimes add human approval by telling the model when it should ask a person for help. The process is more durable when the wait for that person exists outside the model conversation.

Camunda user tasks pause a process instance until the human work is completed. Microsoft’s human-in-the-loop workflow mechanism allows executors to issue requests and wait for responses, with pending requests preserved through checkpoints. UiPath’s Human node similarly pauses a process, assigns a review, approval or input task, and resumes once the person completes it.

In the shipment-recovery case, the agent might conclude that an unusual recovery option requires human review. Once the workflow reaches that state, the wait can survive a model restart, an application deployment or a long delay in the approver’s response. Completion of the review remains part of the process rather than something that has to be inferred later from conversation history.

This article is not about the policy that determines whether an action is authorised; that belongs to runtime governance and policy enforcement. The control-model issue is more basic: if the process is waiting, resumed, cancelled or completed, those lifecycle facts need to remain durable outside the agent’s current context.

Agent loops need an exit that does not depend on better prompting

More autonomy creates another control problem because an agent can continue working without making progress. A loop may repeat the same tool, oscillate between alternatives, accumulate context without resolving the task or keep consuming model calls until a configured boundary is reached.

Prompt changes may reduce that behaviour, but they do not provide the runtime response when it occurs.

Camunda’s current AI Agent Task connector includes a configurable maximum number of model calls; the safeguard defaults to 10 when no value is supplied. Reaching the configured limit produces a specific `MAXIMUM_NUMBER_OF_MODEL_CALLS_REACHED` error, which the surrounding BPMN process can handle through modeled error behaviour.

Another runtime may represent the same boundary with a timeout or an explicit terminal condition. In each case, the surrounding process retains an externally visible way to determine that agentic work ended, stalled or failed to produce a usable result.

The detailed design of exception paths belongs to a separate problem. For this control-model question, the important point is that loop termination cannot depend exclusively on the model privately deciding that it has finished.

The control model has to survive replacement of the agent

Production agents will change as models are upgraded, prompts are revised, tool descriptions improve and one framework gives way to another.

A task that initially uses one agent may later become a multi-agent subsystem. Microsoft now exposes agents as participants inside explicit workflows and provides multiple orchestration patterns, while Camunda places LLM-driven agents inside BPMN-based process execution.

For the shipment-recovery process, a later implementation might split carrier research and customer-impact analysis between specialist agents. If the surrounding control model remains stable, the case can still pass through the same durable business states.

That gives the architecture a practical test: can the model, prompt, agent framework or internal agent topology change without forcing the enterprise to reconstruct the business lifecycle?

If the answer is yes, the enterprise is replacing a worker inside the process rather than rediscovering the process from the worker’s internal behaviour.

Testing should prove the process still works when the agent behaves differently

An agentic workflow is not fully tested by confirming that the agent usually finds a sensible route.

More useful control-model tests deliberately vary behaviour: tools may be called in an unexpected but permitted order; the agent may return early with insufficient evidence; request human review; encounter a tool failure after several successful steps; or reach its model-call limit. A new model version may also choose a materially different sequence from the one seen during acceptance testing.

UiPath’s Maestro testing guidance distinguishes component testing of RPA, agents and human work from end-to-end testing of whether the steps connect, data moves correctly and the business outcome is right. Camunda’s current AI-agent testing guidance likewise treats agent paths as nondeterministic, with tests reacting to whichever tasks the agent activates rather than assuming one hard-coded tool order.

The control model does not need every run to take the same route. It does need the process to remain in a valid, inspectable state when that route changes.

FAQs: AI agent workflow control models

What is an AI agent workflow control model?

It is the explicit process logic governing durable workflow state around one or more AI agents: which states exist, how work can progress, where the process waits, what counts as completion and what happens when agentic work does not finish normally.

The agent can still make dynamic decisions inside the regions assigned to it.

Can an AI agent orchestrate other agents?

Yes. Current orchestration frameworks support multi-agent patterns, agent delegation and agents participating inside broader workflows. Microsoft Agent Framework, for example, exposes sequential, concurrent, handoff, group-chat and Magentic orchestration patterns.

The architectural question for this article is whether that activity sits inside an explicit process boundary or becomes the only place where the business process is defined.

Should workflow routing ever be dynamic?

Yes. Dynamic routing is one of the reasons to use agents.

A control model can expose a bounded set of tools, tasks or subflows and let the agent choose among them while lifecycle state, waits and terminal conditions remain durable outside the model loop.

What belongs outside the AI agent?

At minimum, durable process state, long waits, lifecycle transitions and terminal conditions need an existence outside the agent’s transient reasoning context.

Authorization, identity and policy enforcement are related control concerns, but they are separate topics from the workflow-control boundary examined here.

Autonomy is easier to change when the process contract stays explicit

The 2026 orchestration stack is making room for agents that can plan, call tools, coordinate other agents and alter the order of work. As those capabilities expand, separating local agent autonomy from the durable lifecycle of the business process becomes more useful, not less.

Keeping states, waits, transitions and recovery conditions explicit does not remove agentic flexibility. It lets teams inspect the process without reading a model transcript, change the agent implementation without rebuilding the business lifecycle, and recover when the model takes a valid but unexpected route.

The agent can decide how to make progress inside the territory it has been given. The workflow control model should still tell the enterprise what process is running, where it stands and what can happen after the agent stops.