Three Players, One Direction: ECA, FlowDrop, and Maestro

At every conference, someone corners me at the coffee table. They ask it carefully, the way you ask about a friend's divorce. "So... ECA, FlowDrop, Maestro. Aren't you three competing? Splitting the community?"

Fair question. Three modules. All draw boxes and connect them with arrows. From a distance, three teams building the same thing three times.

Not quite. Best proof is not me saying so. It is a repository where Dries Buytaert, Randy Kolenko, Shibin Das, and I write how orchestration should work in Drupal. We disagree in there. In writing. On purpose. You do not start a shared design document with people you are trying to beat.

The gap none of us invented

Uncomfortable fact first. Drupal core has no first-class sequencing. No run instance. No persisted resume point. No standard way to pass data from one step to the next.

Surprising hole for a platform that powers governments and banks. Every non-trivial site needs it. "When this happens, do that, then wait for a human, then continue."

Contrib filled the gap. Three times, three directions. Not duplication. Three people saw the same missing floor and built different staircases.

The interesting part: the staircases land in different places. Once you see the axis, confusion disappears.

One axis explains everything

Single line that orders all three: how much state does a run carry?

One end: a run carries nothing. Reacts, does its work in a single request, forgets. Other end: a run is long-lived. Memory, queue, can wait for days.

State and time travel together. ECA and FlowDrop expect execution within a session - near-real-time or reasonably bounded. Maestro explicitly extends beyond that. A run can take days. You are not running a nuclear submarine with it.

• ECA sits at the stateless-reactive end. Listens to Drupal events. When one fires, runs a fresh traversal and is done. No running instance. State lives in Drupal, in entities and tokens, not in ECA.
• Maestro sits at the instance-stateful end. A process is a living thing. Holds a persisted queue and process variables. Survives a server restart. Can wait days for a human to click "approve" or for external input, sub-flows, or other automation steps.
• FlowDrop spans the axis. Engine is a strategy you pick: run synchronously, through a queue, or as a stateful graph with checkpoints and resume. One definition, three execution modes. Worth noting: ECA has AI integration and Maestro ships an AI task - FlowDrop's difference is not AI itself, but the typed, inspectable dataflow approach to it.

The whole map. Three coherent choices on one line, not three attempts at the same point.

Each tool in one breath

ECA reaches everywhere Drupal does. Access checks, form alter, render arrays, endpoints, language, views, the whole request lifecycle. More than 650 actions, 120 conditions, 250 events, and almost 100 modules extending it. If the job is "react to this Drupal thing happening, right now," reach is the differentiator. Strains the moment you need a run that outlives the request or waits for human approval. No instance to hang those on.

Maestro, maintained by Randy Kolenko, is built for the opposite case. Business processes with human steps and duration. Approvals, assignments, escalations, multi-day flows where someone must act and state survives in between. Resumability is not a bolt-on. It is the data model. Strains for fast, fully automated reactions, exactly where ECA shines.

FlowDrop, maintained by Shibin Das, is the newest and moving fastest. Its move: make the graph itself truth. Nodes are typed. Data is visible on the wires. Same picture is specification, engine, and audit trail. Think n8n breadth with Langflow-style AI building, but Drupal-native and stored as version-controlled config instead of rows in an external database. Strongest use case today: building complex AI agents behind a chat assistant that wire many steps together.

Nothing here is set in stone

The truest thing in this post: none of these positions are frozen. We are figuring them out in the open. They shift as we go.

FlowDrop is the clearest example. Shibin is refining its positioning toward a strict idea: data flowing between steps should be serializable. Clean, typed, inspectable, the kind an AI agent can reason about safely. A flow can still load an entity and act on it, but that happens inside a single step rather than as hidden state passed along the wires. For his client work this is not a restriction. It is the point. FlowDrop is new. No backwards compatibility to protect. He can take a sharp stance older modules cannot.

That stance has a cost. Shibin is upfront about it. FlowDrop deliberately stays out of some classic Drupal moves. Interfering in a pre-save hook to throw a validation error, for example. Altering state from the outside. For that you reach for ECA, Maestro, or Rules. A sharper tool that does fewer things, on purpose.

ECA's framing is unsettled too. We argue in the shared spec whether ECA is "automation" or "per-request behaviour customization." Both have evidence. We have not decided. We are comfortable leaving it open until the argument resolves itself.

Even "orchestration" is unresolved. First entry in the spec's glossary, marked as actively contested, with competing definitions signed by different authors. We decided pinning it down is one of the first jobs, not an assumption to start from. That is what work in progress actually looks like.

Composition beats merger

Obvious question. If they are complementary, why not merge into one tool?

Because they already work together without merging. That is stronger.

Not a thought experiment. Maestro ships a task called maestro_eca_task. Lets a durable, human-stepped process hand off at a single step to ECA, which touches the wider Drupal surface. Each tool does what it is best at. Bridge exists today.

The shape we are working toward is bigger. Not finished. Picture content moderation. ECA reacts to a content change, calls an AI step. That step runs a FlowDrop flow that does the actual agent wiring. Maestro takes the result through human approval, state safely parked until someone signs off.

Precise here: that full chain does not exist yet. Right now nothing outside a FlowDrop AI chat triggers a FlowDrop flow except custom code. Shibin is exploring how to expose flows so other systems can call them. We see the picture. Building toward it together. Not claiming it ships today.

The difference between composition and a feature checklist: Maestro owns duration and human steps. ECA owns breadth and event-driven reactions. FlowDrop owns typed, AI-native data flow. Each stays itself, calls the others at its edges.

Bridges are the start. Not the finish line.

The shared floor we have not built yet

Point-to-point bridges do not scale. maestro_eca_task works because two maintainers sat down and agreed on a handoff contract. Add a third bridge. Then a fourth. Then cross-product. You get tangled fast.

The real prize is not more bridges. It is a shared foundation. Common primitives, shared APIs and services, so none of the three reinvents wheels. Ideally some land in Drupal core. The rest in contrib, stable and documented enough that a tool can draw on them without forking or wrapping.

We circled this in the spec without naming it at first. Then we lined up the equivalent concepts across ECA, Maestro, FlowDrop, and Drupal core in one table. Same ideas, different names. Embarrassing how similar they are.

The thing that starts work: ECA Event, Maestro Start task, FlowDrop Trigger, core Event-Hook-Cron. Candidate canonical term: Trigger.

A unit of work: ECA Action, Maestro Task, FlowDrop Node, core Action plugin. Call it Step.

A guard or precondition: ECA Condition, Maestro If-task, FlowDrop Gateway. Condition.

A reusable definition: ECA Model, Maestro Template, FlowDrop Workflow, core Recipe. Workflow.

A running instance: ECA has none (stateless). Maestro has a Process. FlowDrop has an Execution Session. Core has nothing standard. Call it Run.

And the one with no shared standard at all, the most important: data passed between steps. ECA Tokens. Maestro Process Variables. FlowDrop typed Port and Edge. Core context arrays. No convergence yet.

That last one is the keystone. A defined contract for handing data from one step to the next, and from one tool to another. Not just inside Drupal. The spec's vision explicitly says the same primitives a human uses should be callable by an AI agent. Safely. That means a contract that does not stop at Drupal's border. Works for external systems, non-Drupal frameworks, agents acting on your site.

The spec has open questions on exactly this. "What are the atomic primitives, step, action, recipe, intent?" "Where does it run, core, contrib, or a service?" "What ships in Drupal core?" Unresolved, on purpose. We are exploring, not announcing.

This convergence is the goal. Not done. Building common abstractions may require rewrites or migrations down the road. Too early to design those. For now we want the shared floor identified and agreed. Then we can start pouring concrete.

Honest framing: this is harder than bridges. Bridges are bilateral. A shared foundation needs all three tools, core, and maybe a service layer outside Drupal entirely. That is the conversation the spec exists to have.

What the collaboration actually looks like

Healthy open source is not three maintainers politely ignoring each other. Three maintainers plus Dries in one repository, writing competing proposals, arguing them to a conclusion.

The orchestration design spec works like a small research group. Vision page for the three-year North Star. Problem statement grounded in real pain, not imagined. Glossary where we lock down contested terms. Scenarios that act as a shared test suite, when someone proposes an approach, we walk it through the same stories and see where it bends. Proposals are allowed to disagree. Decisions are append-only, recording not just what we chose but what we rejected and why.

None of us is easy on the others. That is what makes it work. Shibin pushed the dataflow-versus-process-flow distinction that sharpened how we all think about visibility. Randy keeps pulling us back to the human-in-the-loop cases ECA users quietly struggle with. Dries keeps asking the question underneath the question. I bring ECA's breadth and, occasionally, stubbornness.

You do not get this from a merger. A merger forces one mental model onto three problems. Produces one tool mediocre at all of them.

Why three is the right number

Specialization makes each tool better than any compromise could.

A single unified module would have to be reactive and stateful, instant and durable, hook-deep and AI-clean, all at once. Those pull in opposite directions. Honest engineering answer: you cannot be excellent at the stateless-reactive end and the instance-stateful end with the same architecture. Each tool's purpose dictates a fundamentally different engine - Maestro's tracks loop-backs, reassignments, and ancestor history a reactive ECA traversal would never need. The axis is real. Pick a point, or span it deliberately like FlowDrop does. Do not pretend the tension is not there.

Three tools also means resilience. Three actively maintained projects serving different needs are safer for your site than one tool trying to do everything and burning out its maintainer. Yes, all three of us face the same sustainability question every contrib maintainer faces. Topic for a later post. Worth naming here: specialization is also how small teams stay sane.

Practical guidance is simple. React to a Drupal event, right now? ECA. Model a business process with human approvals over days? Maestro. Build a typed, inspectable flow, especially an AI agent? FlowDrop. Need two at once? Compose them. The bridges are growing.

Where this goes

We are early. The spec is a draft. FlowDrop's repositioning is in motion. The full ECA-to-FlowDrop-to-Maestro chain is a picture, not a release. The shared foundation and the data-handoff contract that works beyond Drupal's border, that is the real direction, and it is open questions more than finished design.

But the direction is shared. That is the headline. Three maintainers and Dries, writing one design document, building bridges between three tools instead of walls, and circling the harder question of what common ground we have not built yet. Not fragmentation. An ecosystem growing up.

If you have been confused about which tool to use, the axis helps. If you are using two together in a way we have not thought of, tell us. If you see a primitive all three are reinventing, name it. The positioning is not finished. Your use cases shape it next.

Join Drupal Slack #eca-next-gen. Share what you are building. Tell us where the tools should meet. We are writing this map together. Would rather write it with you than for you.