Randy Kolenko, partner and senior architect at Nextide, recently joined the Drupal Orchestration Initiative with Jurgen Haas, Shibin Das and Dries Buytaert.  The Orchestration Initiative is still in its infancy, however, the discussions and (dis)agreements will continue until the vision of what Orchestration means to Drupal is sharpened.  

Orchestration is a very loaded term.  From Maestro’s perspective, our engine has always been called the orchestrator and hence the musical linkage with the name Maestro which conveys control, precision and guidance of work automation processes.  From other people’s perspectives, “orchestration” means properly handing off work from one mechanism to another.  

Automation and Orchestration are two different terms, yet they seem to constantly overlap in discussions.  Think about Automation as taking a unit of repetitive work and having a computer do that for you.  Think about Orchestration as many units of automation all having to work together, coming to bear at the right place and time, throwing the unpredictability of humans into the mix.

Drupal Orchestration

The Orchestration Initiative’s Design Specification (still in open research) is actively working towards shared primitives yet there is still one major unresolved keystone: a data-handoff contract between systems and tools.  What systems you ask? Drupal has a handful of orchestration and automation engines each owning their own segment of work.  

• ECA automating reactive workflows dealing with Drupal events.
• FlowDrop providing deterministic agentic data flows.
• Nextide’s Maestro providing the long term orchestration and automation with the ability for human in the loop workflows.

What Maestro has clear ownership of is the durable, stateful, and instance-aware segment.  Not all Maestro workflows have a Human-In-The-Loop (HITL), but the architecture of Maestro’s orchestrator is such that the execution of a workflow happens over time, lending itself to the timescales of humans.  Without Maestro, "State" is volatile. In long-running business processes, "State" must be durable surviving cache clears, server restarts and weeks of human silence. It’s safe to say that the reasonable duration of execution varies by engine:

• A Maestro process is measured in minutes, hours, days, weeks or more.
• An ECA model’s execution is measured in milliseconds.
• A FlowDrop workflow is measured in milliseconds to minutes.

Orchestration of Data

What if we want to accept input from an external system? For Maestro, traditionally we’d fire on a webform submission, an ECA action, a custom webhook or some combination therein.  Great!  But what’s the data contract between the external system and Maestro? What does Maestro accept? What does the system that Maestro is calling accept? Is the data typed? When is a “1” an integer value of 1 vs a binary TRUE value?

At this point, passing data within Drupal is an issue.  What does ECA expect as a data type to publish a node vs. what Maestro needs to perform the same action? What data is required to initiate a Maestro workflow? This is why a standardized data contract is required so that we can seamlessly talk to each other within Drupal.  

The N x N Issue

This type of data passing is an issue between 3rd party systems and Maestro and between internal systems like ECA and Maestro and where structured orchestration becomes crucial. Now consider that in order to interact with ECA, we had to create events and actions that plug into ECA.  If Maestro wants to interact with an external system, we write the adapters that connect seamlessly to those external systems. But what you should notice with this approach is that as soon as we wish to link with FlowDrop, we then need connectors on each end. What about a new tool that connects to ECA and Maestro and FlowDrop? Connectors between the new tool and all three engines. Another new tool? Connectors between the previous new tool, and all three engines. You can now see that we get an escalation of connectors, muddying the waters and making interoperability within Drupal exceedingly difficult to maintain over time.

This is where the Orchestration Initiative comes in and can try to progress towards a proper data contract.

Intent-based flows

As AI continues to become a major focus for organizations, having AI actually do useful work for you in your environment is becoming increasingly important. For example, an organization may have a newly defined request to handle “a grant application that requires dynamic approval from various executive levels and upon approval, route to finance for payment”.

The intent is a grant application process. The reality is that it’s not just a form. How would you implement that today? Do you know the ins-and-outs on how to configure a Maestro approval flow? Do you know how to create and wire a webform to a flow? What about approvals? What if you require a majority count to certify the approval? These become agonizing questions that can paralyze what otherwise seemed like a simple task.

Ok, so what? How does that help the Drupal community? As the Orchestration Initiative marches forward, Maestro provides the deterministic guardrails for non-deterministic AI. If an AI agent initiates a process, Maestro ensures it follows the legally required approval path, providing a durable audit trail that AI alone cannot guarantee. AI’s ability to understand language, pick the right tools and create deterministic workflows and scaffolding is incredibly powerful. With the Orchestration Initiative, the underlying data contracts and ability to communicate with any tool becomes straightforward. The intent for a grant application process becomes a set of orchestratable tools that can be reused in the future for other intent-based applications.

In an AI-driven future, we want to satisfy the traditional deterministic work automation and Intents. When an AI says 'Pay this grant,' the system doesn't just do it, it remembers who, when, and why, for as long as the business requires.