Drupal Orchestration Spec Maps ECA, FlowDrop and Maestro

Shared orchestration work across Drupal is drawing ECA, FlowDrop, Maestro and Drupal core into one architecture discussion. In a 25 June 2026 post for LakeDrops, Jürgen Haas describes a draft design effort that maps common workflow concepts across the three contributed projects. Posts dated 23 June 2026 by Dries Buytaert and 16 June 2026 by Shibin Das on the FlowDrop blog connect the same discussion to agentic workflows and controlled AI execution.

The development builds on earlier TDT coverage of a planning-stage discussion around a shared backend layer for Drupal automation tools. That 16 June 2026 story reported that maintainers were exploring common graph models, data contracts and reusable processor patterns across ECA, FlowDrop and Maestro, while keeping each project’s interface and execution model separate. The newer posts move that discussion from shared-layer planning into a more defined vocabulary of triggers, steps, conditions, workflows and runs.

Jürgen’s article places the tools on an axis defined by how much state a run carries. ECA is described as reactive and stateless, using Drupal events and ending within a request. Maestro is positioned as durable and stateful, with process variables and human approval steps that can persist over time. FlowDrop is described as spanning the axis through synchronous, queued or stateful graph execution.

The shared design work identifies candidate primitives for a common vocabulary. One proposed term is trigger, which would cover the different ways work begins in each system: ECA events, Maestro start tasks, FlowDrop triggers and Drupal core event or cron entry points. Step, condition, workflow and run are also named as possible shared terms. Drupal core is described as lacking a standard run instance, resume point and step-to-step data-passing model.

The unresolved piece is data handoff. ECA uses tokens, Maestro uses process variables, FlowDrop uses typed ports and edges, and Drupal core commonly uses context arrays. Jürgen frames this as the contract needed for data to move between steps, between tools and across Drupal’s boundary to agents or external systems. That is a design question, not a shipped capability.

Dries’ article extends the same architecture question beyond Drupal’s interface. He argues that external agentic platforms may coordinate work across tools, while Drupal should assemble, validate, govern and publish structured content. In that model, ECA, FlowDrop and Maestro become Drupal-native workflow layers that outside systems can call instead of manipulating Drupal field by field.

The keynote demo linked from Dries’ post gives that argument a practical example. In the segment, he shows Activepieces pulling RSS content from WordPress, connecting to Drupal through Basic Auth and JSON:API, discovering Drupal field definitions, and mapping the feed output into a Drupal content type. The demo then adds an AI step to assess relevance, logs review decisions in Google Sheets, and shows an ECA model inside Drupal exposed back to Activepieces. The example supports the larger point: external orchestration can coordinate work across systems while Drupal remains the governed place where content state, workflow and publishing rules are enforced.

The FlowDrop post adds a governance layer to that picture by separating model choice from tool execution. The language model states which tool it wants and why, while FlowDrop applies checks before and after the call. The post presents human approval, guardrails, tool limits and audit records as controls around agent actions. Practical guidance still separates the projects by execution model: ECA for immediate Drupal event reactions, Maestro for durable processes with human approval, and FlowDrop for typed, inspectable AI-oriented flows. Jürgen cites the existing maestro_eca_task bridge from Maestro to ECA, but states that a full ECA-to-FlowDrop-to-Maestro chain does not yet exist.