Blog · arXiv Analysis · Last reviewed June 25, 2026

The Process Harness Becomes the Workflow Boundary

Fabiana Fournier and Lior Limonad's June 2026 arXiv paper proposes a process harness for Agentic BPM: a policy-governed layer that lets agents reason at designated workflow control points while a deterministic engine keeps the process graph.

From Workflow to Harness

The paper, arXiv:2606.27188 [cs.AI], is titled A Process Harness for Uplifting Legacy Workflows to Agentic BPM: Design and Realization in CUGA FLO. arXiv lists Fabiana Fournier and Lior Limonad as the authors, records version 1 on June 25, 2026, and describes the submission as a 24-page paper with five figures.

This is a fresh companion to the agent-trace essay, the delegation-trace essay, and the runtime-governance essay. Those pages ask how agent work becomes visible after delegation. This paper asks where agent autonomy should enter a business process at all.

The authors' answer is not to replace a workflow engine with an open-ended planner. They introduce a process harness, an overlay that wraps a deterministic workflow engine and invokes policy-governed LLM agents only at designated control points. The engine still owns the process graph. The harness contributes reasoning, routing, and adaptation where the process configuration permits it.

What Gets Delegated

The formal model is Task-Decision-Flow, or TDF. It decomposes agentic reasoning into three roles. A TaskAgent handles knowledge-intensive work inside a task. A DecisionAgent handles per-case routing at a gateway. A FlowAgent handles runtime flow adaptation through hook points on sequence flows.

That separation is the practical governance move. In the loan example, the credit-checking agent may compute a normalized credit score, but it is not supposed to approve or reject the application. The gateway policy owns routing, and a hook policy may later override a path for another reason. Each role is attached to the process FRAME, the policy set governing LLM calls.

The implementation detail matters because policy is not left as a slogan. CUGA FLO applications are organized around configuration files and markdown policy documents. The code repository's README describes FlowAgent, DecisionAgent, and TaskAgent components mediated through an MCPFlowBridge while the WorkflowEngine drives execution.

Why the Engine Stays

The old engine is not just technical debt. In regulated work, a deterministic workflow engine remembers institutional commitments: which steps must happen, which branches are valid, and which trace can be audited later. Replacing it with a conversational planner moves compliance into a less inspectable runtime.

Fournier and Limonad frame the harness as a way to reconcile imperative and normative requirements. The imperative layer is the executable process model enforced by the workflow engine. The normative layer is the human-readable FRAME that tells each agent what it may produce. The result is not agent freedom in the abstract. It is bounded intervention inside a process topology that remains explicit.

That matters for labor too. When organizations insert agents where human workers once resolved exceptions, the better test is whether the exception has a named control point, policy, action permission, and record.

The Loan Example

The case study is a small illustrative loan approval workflow. It has credit assessment, approval routing, outcome handling, and merge stages. The example includes three task-agent tasks, one decision-agent gateway, and one hook on the approval path. The hook demonstrates a regulatory override: applicant ID 4321 is routed away from approval even though the credit-score decision would otherwise pass.

The interesting part is the separation of reasons. The DecisionAgent can route on credit score. The FlowAgent can intercept the approved path under a regulatory policy. The rejection handler can then produce a regulatory rejection path without pretending the credit score failed. A less disciplined agentic workflow might collapse those steps into one plausible narrative.

The action-permission layer is also important. In the loan configuration, the paper says some hook actions are permitted, including continue, skip_to, and terminate, while swap_nodes and skip_node are prohibited. That means the system can record not only what an agent recommended, but whether the surrounding harness was authorized to emit that kind of structural instruction to the engine.

Limits That Matter

The paper is a framework and implementation realization, not proof that every wrapped workflow is safe. Its limitations section names several hard problems. Intermediate events are not yet a first-class hook construct. Runtime topology modification is restricted to nodes that have not yet executed. Hooks can add latency. FRAME authoring can produce conflicting policies unless consistency checking improves.

The deepest limit is behavioral diligence. The harness can give an agent the process state and the relevant policy, and it can restrict which structural actions the engine will accept. It cannot by itself prove that the model's internal inference actually followed the assigned policy under ambiguity. That is not a small caveat. It is the difference between a governance interface and a guarantee.

So the process harness should be read as an accountability architecture, not a magic seal. It makes the control points inspectable. It attaches policies to reasoning calls. It keeps the workflow engine in charge of execution. It gives auditors a place to look when the agent recommends a route, task result, or hook intervention. The evidence still has to be tested, logged, versioned, and challenged.

Governance Standard

Any process harness used in consequential work should publish a process record: workflow engine and version, process model, control points, agent type at each point, FRAME policy version, action permissions, model and tool rights, state variables exposed to each agent, hook semantics, fallback path, human review points, logs, test cases, failure modes, and rollback rules.

The standard should separate recommendation from execution. The agent may propose a task output, branch, or intervention. The harness checks the policy and permission envelope. The engine executes valid instructions. When the process harness becomes the workflow boundary, the question is whether the institution can still show who was allowed to act, under which policy, at which control point, with what evidence, and what happened when the agent was wrong.

Sources

Return to Blog