BPMN/DMN Deterministic Shell Around Agent
also known as BPMN-Spine LLM-Leaf, Workflow-Engine-Grounded Agent
BPMN processes and DMN decision tables form the deterministic spine; LLM-driven agents are invoked only at explicit 'unstructured problem' nodes inside the process.
Context
An enterprise has existing BPMN workflows and DMN decision tables. Adding agents directly replaces some workflow steps, breaking the existing observability and governance built around workflow engines.
Problem
Pure-agent replacement of workflow steps loses BPMN observability (which step is running, how long did it take), DMN auditability (which decision rule fired), and existing operator tooling. Hybrid solutions where the agent runs *outside* the workflow lose the integration. Differs from existing hybrid-symbolic-neural-routing by being specifically workflow-engine-grounded — BPMN/DMN as the surrounding shell.
Forces
- BPMN/DMN engines are mature; adding agent invocations is integration work.
- Some steps are genuinely unstructured and benefit from agent flexibility.
- Workflow engines vary in their support for asynchronous and long-running steps.
Example
A claim-processing BPMN: 'receive claim' → 'classify (DMN rule)' → 'extract fields (agent service task)' → 'verify (DMN rule)' → 'approve (DMN rule)' → 'notify'. The 'extract fields' node is an agent because claim documents are unstructured. Everything else is deterministic BPMN/DMN. Auditors see the full process in the existing BPMN dashboard; the agent invocation is one labeled service task.
Diagram
Solution
Therefore:
Model the end-to-end process as BPMN. Decision points use DMN rules where possible. At nodes that need LLM-driven flexibility (free-form input handling, summarization, classification with judgement), invoke an agent as a BPMN service task; the agent runs, returns structured output to the workflow engine, BPMN flow continues. Pair with deterministic-control-flow-not-prompt, hybrid-symbolic-neural-routing, plan-and-execute.
What this pattern forbids. The BPMN engine is the orchestrator; agents are invoked as service tasks at explicitly-labeled unstructured-problem nodes; orchestration logic does not live in agent prompts.
And the patterns that stand alongside it, or against it —
- complementsHybrid Symbolic-Neural Routing★— Per query, route between a symbolic path (rule engine, knowledge graph) and a neural path (LLM), using the LLM for interpretation and the symbolic layer for exact constraints.
- complementsDeterministic Control Flow, Not Prompt★— Branching decisions live in deterministic application code while the LLM is invoked at strategic points to produce structured signals that the code branches on.
- alternative-toPlan-and-Execute★★— Plan all the steps once with a strong model, then execute each step with a cheaper model under the plan.
- complementsAgent-as-Tool Embedding★— Wrap a sub-agent (with its own loop, prompt, and tool palette) behind a single function-shaped tool signature, so the parent agent calls it like any other tool and never sees the sub-agent's internal turns.
- complementsPolicy-Gated Agent Action (KRITIS)★— Each agent action passes through a policy gate (NIS2, EU the agent Act, BSI rules) and is tagged with Run ID + Model Digest + Policy Hash for WORM-audit reconstruction.
Neighbourhood
Click any neighbour to follow the language. Scroll to zoom, drag to pan.