From Black-Box Task to Aspect-Woven Task
What MCP changes about how a BPMN task makes its decision
Classical BPMN Task
All context must arrive in the input map
Input Variables
sku storeId onHandUnits forecastDailyDemand (everything else: invisible)
Service Task
Replenishment Decision
f(input) → output
Output Variables
decision, rationale
Available in the engine — invisible to this task
✕ What previous decisions did this instance make? ✕ What goal is this task ultimately serving? ✕ What did the prior reviewer flag in their notes? ✕ Are peer tasks already escalating this case? ✕ What does the audit log say about similar cases? ✕ What semantic lineage produced this demand forecast? ✕ What organizational preferences should weight this call? ✕ Has the policy that informed this process changed? All hand-wired into the BPMN diagram, or not seen at all.
Aspect-Woven Task (Camunda 8.9 + MCP)
Cross-cutting concerns are consulted at execution time
Input Variables
sku storeId
AI Service Task
Replenishment Decision
reasons over input + aspects
MCP Gateway
the aspect weaver
Aspects discovered through MCP at execution time
✓ Process Variables (live)
✓ Instance History
✓ Audit Log API
✓ Semantic Lineage
✓ Peer-Task / Peer-Instance State
✓ Goal Registry
✓ Preference Weights
✓ Policy / Ontology Version
Concerns are not wired into the BPMN diagram.
They are advised in at execution time, governed by MCP authorization.
Output: decision + rationale + lineage of which aspects influenced it