The Bidirectional Loop: Runtime Informs Tasks — Tasks Inform Runtime
Each task’s decision becomes part of the next task’s context. No flow arrow required.
Camunda 8.9 MCP Gateway
runtime introspection • cluster variables • audit log
Task N (now)
e.g. Replenishment Decision
1. Reads instance history 2. Reads peer-task state 3. Reads goal context 4. Reasons over input + aspects 5. Decides + writes rationale
Task N+1 (next)
e.g. Funding Disbursement
1. Reads instance history → sees Task N’s rationale 2. Reads lineage of decision 3. Reasons with richer context 4. Acts — and is itself recorded
Live Cross-Cutting Context
Process variables • Goal Registry • Preference Weights
Peer-instance state • Policy / Ontology version
Persistent Decision Lineage
Instance history • Audit log • Semantic lineage records
written by every task that completes
read aspects
write decision + rationale
audit + lineage
live state
read aspects (now richer)
write decision + rationale
Time → Task N completes, lineage is recorded, Task N+1 sees it. No message flow modeled in BPMN.
Collaboration falls out of the architecture. Tasks coordinate by reading and writing through the weaver — not by point-to-point wiring.
The audit trail is not an afterthought. It is the substrate the next decision is built on.