Skip to content
Kiberon LabsAgentic Engineering

Workflow Engine

6 min read

In the robotics analogy, the workflow engine is the autonomous business unit’s executive control layer. It sits between estimated state, deliberative planning, and the capabilities that act on the world. It decides which execution mode applies, sequences work, monitors outcomes, and preserves control when execution fails, waits, or changes direction.

Hybrid robot architectures use a similar separation. The LAAIR architecture can directly sequence known skills while invoking deliberative planning when a task cannot be statically decomposed. Its executive monitors execution and can redirect or preempt work. For a business unit, deterministic software supplies known behavior, agents supply deliberation, and the workflow engine coordinates both.

From estimated state to action

Section titled “From estimated state to action”
flowchart LR
    estimate["Estimated business state"] --> trigger["Trigger and policy evaluation"]
    trigger --> executive["Durable workflow engine"]
    executive -->|Known response| deterministic["Deterministic activity"]
    executive -->|Judgment required| agent["Agent run"]
    executive -->|Authority required| approval["Human or external approval"]
    executive -->|No action| retain["Record or update knowledge"]
    deterministic --> outcome["Verified artifact and measured outcome"]
    agent --> outcome
    approval --> outcome
    outcome --> signals["New world signals"]

The workflow begins from a governed state transition, not directly from untrusted input. Before dispatch, it resolves the current goals, axioms, policy, authority, and evidence required for the proposed action.

Choosing the execution mode

Section titled “Choosing the execution mode”

The executive should choose the least open-ended mode that can safely produce the outcome:

  • Deterministic execution for known rules, stable transformations, bounded integrations, and protective reflexes.
  • Agent execution for ambiguous interpretation, unfamiliar planning, synthesis, or adaptation.
  • Human or independent judgment when evidence, authority, legality, or policy is insufficient.
  • Hybrid execution when deterministic activities prepare and validate context, an agent proposes a plan, approval gates consequential steps, and deterministic activities apply the decision.
  • No execution when the condition is irrelevant, stale, duplicate, unauthorised, or already resolved.

Agent execution is not the default response to every state change. Deliberation should be invoked only when its flexibility is needed.

Why the capability is required

Section titled “Why the capability is required”

A webhook handler can receive an event. A queue can transport it. A harness can run an agent. None of these alone maintains the durable relationship between a state change, the decision it caused, the work that followed, and the eventual business outcome.

An autonomous business unit therefore requires a durable workflow capability. This is an architectural responsibility, not a requirement to use a particular workflow-engine product. The implementation must be able to:

  • persist workflow state after the process or agent run ends
  • start, suspend, resume, preempt, and time out work in response to authorised events
  • deduplicate triggers and make consequential side effects retry-safe
  • preserve ordering or reject stale transitions when events race
  • apply current goals, policy, identity, and authority before dispatch and resumption
  • route work to deterministic activities, agent harnesses, or approval paths
  • retry transient failures without silently repeating completed effects
  • retain timers, deadlines, approvals, and external-job waits without keeping a model alive
  • correlate state, decisions, activities, artifacts, and outcomes in the execution ledger
  • recover incomplete work after worker, model, tool, or infrastructure failure

Without this layer, the unit has disconnected reactions. A process can crash after accepting a trigger. The same state change can start duplicate work. An agent can finish while an external operation remains pending. An approval can arrive after the proposal has changed. These transitions cannot safely exist only in process memory.

Executive control is not the agent harness

Section titled “Executive control is not the agent harness”

The harness manages reasoning and tool use inside an agent invocation. The workflow engine manages causality, state transitions, waits, retries, authority, and recovery across agent invocations, deterministic activities, and people.

The engine also does not decide business strategy. Goals and axioms define which outcomes and paths are legitimate. Business State Estimation determines what is currently believed. The executive applies those inputs to the lifecycle of accountable work.

Reflexes, runtime assurance, and fallback

Section titled “Reflexes, runtime assurance, and fallback”

Rodney Brooks’ layered control architecture showed how reactive behavior can remain available beneath higher-level intelligence. The business equivalent is that urgent, well-understood protections should not wait for an agent.

A confirmed credential compromise can revoke access immediately. A hard capital limit can reject a transfer. Loss of a critical dependency can activate a tested failover. An agent may investigate and plan recovery afterward, but the protective reflex should be deterministic and independently enforceable.

Runtime-assurance architectures provide a related pattern: monitor an advanced controller that is difficult to verify and transfer control to a trusted fallback when a safety property is threatened. NASA’s formal runtime-assurance framework describes this Simplex pattern for autonomous systems.

For a business unit, an agent can act as the advanced controller while structural policy enforcement monitors the proposed action. If a governing property would be violated, the workflow moves to a restricted deterministic path. The fallback may freeze spending, revoke a credential, preserve records, continue essential operations, and escalate to an external authority.

Execution-policy representations

Section titled “Execution-policy representations”

Finite-state machines, directed workflow graphs, policy tables, and behavior trees can all represent parts of executive control. Robotics behavior trees are useful for modular task switching, preemption, and standard running, success, and failure outcomes. See Behavior Trees for Robust Task Level Control in Robotic Applications.

These representations do not create durability by themselves. The runtime must still persist state across process failure, manage long waits, re-check current authorization, make effects retry-safe, and retain an auditable history.

Minimum closed loop

Section titled “Minimum closed loop”

At the business-unit boundary, the smallest useful loop is:

  1. Receive and validate a world signal.
  2. Update the governed estimate of relevant business state.
  3. Detect a decision-relevant state transition.
  4. Record the trigger decision and select an execution mode.
  5. Act through deterministic software, an agent, an approval path, or a composition of them.
  6. Verify the artifact and measure the external outcome.
  7. Emit the outcome as a new world signal.

The software dark factory and this executive loop solve different halves of autonomy. The factory gives the unit a way to effect governed change within its software estate. The signal, state, and workflow layers let it notice when change may be required and coordinate the response. An autonomous business unit needs both.

Section titled “Related concepts”