Every month, on the first working day, I orchestrate. I don't call it that. I call it billing.

Timesheets live in one system, so I export them. Invoices get created in a second system from those timesheets and exported as PDF. I merge each invoice with its timesheet, email the bundle to the client, file a copy in a folder, and upload another copy to the accountant's portal. Four systems, plus a PDF tool and a folder. Every step by hand.

I maintain a Drupal automation module used on tens of thousands of sites, and I do my own billing by hand. The irony is not lost on me. It's just not automated yet.

The other case is worse. One client, three agencies, twelve project people, a few hundred users. Half a dozen systems: issue tracker, project management software, file sharing, and three more I won't bore you with. Planning happens in Excel. Not because anyone loves Excel. Because it's the only place where everyone involved feels they can see the whole picture and stay in control. Keeping it current is impossible. Everyone knows that. It works anyway, the way a leaking roof works.

This post is part of the series ECA: The Next Chapter. Earlier posts: the journey, the Modeler API, in-context customization, the new Workflow Modeler, test, replay, debug, ECA, FlowDrop, and Maestro, and documentation that machines read.

The world's most popular orchestration tool

That spreadsheet is the whole point. Excel is the most widely used orchestration tool in the world, and nobody calls it that. It wins on one thing: everything in one place, under my control. It loses on everything else. Nothing runs by itself, nothing gets validated, nothing is auditable, and data gets copied instead of connected.

Dries Buytaert put a grid on this in June, in AI and the great CMS unbundling. Two axes: how many people, how many systems. My billing sits in his "Delegate" quadrant, one person and many systems. The project sits in "Orchestrate", many people and many systems. His observation covers both: "no single product sees the whole job." So people reach for the one product that shows whatever they paste into it.

Is the world ready?

People ask me whether the world is ready for orchestration. Whether anyone is actually asking for it.

Yes, everybody is. Individuals, organisations, companies, they all orchestrate every day. Most of them by hand, shuffling data between systems, one interactive step after the other, with every chance of getting it wrong. Dries wrote the same sentence last October in The Orchestration Shift: "most organizations are still doing orchestration by hand." Demand isn't the question.

The question is why they still do it by hand, and the answer is that digital orchestration is far too complicated. Not for lack of tools. There are plenty, and each one wants to be the place where you work.

What we can already build

Take my billing. Every step has a home in Drupal's orbit today.

ECA reacts to the month-end event and collects the timesheets. AI Integration - ECA, released as 1.0.0 in September, classifies unbilled entries and drafts the invoice text. Maestro parks the invoice and waits for a human to check it, for as long as that takes. Activepieces or n8n, through the Orchestration module, mails the PDF and uploads it to the accountant's portal. Tool API, at beta8 and a requirement for AI 2.0, gives each step typed inputs and outputs, so the pieces can hand data to each other.

Every piece exists. I could wire this together on a Friday afternoon. Technically, it's impressive, and I say that as someone who wrote a good part of it.

But the right person to build it isn't me. It's the person who does the billing. They know every step, every exception, every client who wants the PDF named differently. In my agency that happens to be me, and I know how the engines work. That's the exception. In most companies, the person doing the billing has never opened a modeler and never should have to. Post 3 made this argument for a single form: bring the automation to the person who has the problem, not the other way round. It holds for a whole workflow.

So hand it to them and watch. To build it, they would open at least five UIs: the ECA modeler, the Maestro template builder, the AI provider configuration, the Activepieces flow editor, the Orchestration module settings. Five vocabularies. Five ideas of what a "step" is. Five places where the same invoice number has a different name.

That's the smaller problem.

The decision nobody can make

The bigger problem comes before any UI opens. Somebody decided which step lives where.

Reacts inside the request: ECA. Waits for a human, possibly for days: Maestro. Typed, inspectable data flow with AI inside: FlowDrop. Talks to a SaaS product: Activepieces. In Post 6 I drew the axis that makes those choices explainable. Three maintainers and Dries needed a shared design document to agree on it.

The person doing the billing will never make that decision. They don't know the engines, and they shouldn't have to. It's like asking someone to pick the power plant before they switch on the light.

We built impressive machinery and put the hardest question at the front door. "Literally impossible" is the phrase I keep using for this. I stand by it.

One UI

The solution is not another tool. It's one UI.

All components from all participating systems, presented together. One place to pick a step by what it does: collect timesheets, wait for approval, upload to portal. Not by who runs it. Which engine executes a step is the platform's decision, derived from the step's properties. The user never learns which system did what, and has no reason to.

Dries again, from June, in Drupal's role in agentic workflows: work will move across systems and people, and the best end-to-end experience comes from "making the handoffs feel invisible." An invisible handoff is a UI property before it's an architecture property. If the user has to know where the handoff is, it isn't invisible.

The spreadsheet already told us what wins: everything in one place, under my control. One canvas showing every capability of every connected system beats the spreadsheet at its own game. Add test and replay from Post 5. Then it runs.

One objection arrives on schedule: an AI agent will do all this soon, no canvas needed. Dries answered that in December, in The Control Layers of AI. Salesforce's Agentforce was sending customer surveys for Vivint. Surveys randomly went missing for weeks. Root cause: the agents skipped steps. The fix was "more workflow, not more magic." A deterministic outer layer, AI for the judgment calls inside it, precise tools inside the AI. My billing has one judgment call, the invoice text. Everything else must happen every single time. The one canvas is where a human decides which steps are which. An agent deciding that for you is how surveys go missing.

Why the architecture is already there

This is the part where I get to be smug for one paragraph and honest for the rest of the post.

The Modeler API, Post 2, separates the model owner from the modeler. ECA is one owner, and nothing in the API says a canvas has only one. The Workflow Modeler, Post 4, renders whatever components an owner declares, with the same drag-and-drop, the same token handling, the same structured YAML editor. Tool API gives every step a typed contract, shared today by ECA, the AI Agents, the MCP client and server, and FlowDrop. Post 6 named the shared primitives: Trigger, Step, Condition, Workflow, Run. Post 7 made components discoverable to machines through MCP, and a single UI needs exactly that kind of discovery.

Add it up: an owner-agnostic modeler, a typed step contract, a shared vocabulary, machine-readable component catalogues. That's the architecture for one UI. I know of no other CMS with that stack.

Now the honesty.

What is missing

Nothing renders more than one model owner on one canvas today. I'm confident the current structure covers it. Confident is not shipped.

Maestro as a model owner: I've started a proof of concept, and it's doable. FlowDrop: similar experiments exist from before. Neither is in a release.

The Orchestration module ships Activepieces in 1.0.0. n8n integration is underway: a driver on the Drupal side, community nodes on the n8n side, both directions. Randy Kolenko shipped a Maestro task type for Activepieces that uses the Orchestration module for the return call. I suspect others have wired more together without telling us.

Still missing, and this is the real work: a composite model owner that exposes the union of all components on one canvas. A dispatcher that routes each step to its engine and hands results back. And the keystone from Post 6, still open: a data-handoff contract that works between engines and across Drupal's border.

The dispatcher is less mysterious than it sounds. The axis from Post 6 already encodes what it needs to know. Does the step wait for a human? Does it outlive the request? Does it talk to a system outside Drupal? Does it carry typed data an agent may touch? Today a human answers those questions by picking a tool. Tomorrow they're properties on the step definition. The axis stops being a map for experts and becomes metadata the platform reads.

The single UI does not exist. The architecture to build it does.

Build the last pieces

The last pieces are not a LakeDrops project. They belong to everyone with a component: ECA, Maestro, FlowDrop, Tool API, the AI module, Activepieces, n8n, and Drupal core. The orchestration design spec from Post 6 is where the arguments happen. Its glossary still marks "orchestration" as contested. Good. A single UI forces that argument to a conclusion, because a step on the canvas has to mean one thing.

A note on "in Drupal." Dries wrote that the CMS "is not necessarily the orchestrator of that ecosystem." I agree, and I still say "in Drupal", because those are two different claims. The engines can live anywhere: inside Drupal, outside it, or both. The place where a human sees the whole job and stays in control lives in Drupal, because that's where the Modeler API is.

"The world's best orchestration platform" is a big phrase, and I use it on purpose. The pieces exist. The missing ones have names. The people who can build them all know each other.

Infrastructure that removes decisions from users is expensive to build and invisible when it works. Nobody thanks the power grid. The next post is about how work like this gets paid for. Short version: not by itself.

Bring me your spreadsheet

Bring me the workflow you do by hand. The billing, the planning sheet, the Friday export. Post it in Drupal Slack #orchestration. Then tell me which of its steps you would want to assign to an engine yourself. I expect the answer is none. That answer is the specification.

If you maintain a component that could be a step, talk to us about the Modeler API or Tool API. If you've connected two of these tools and told nobody, tell us now.

I'll keep doing my billing by hand for a few more months. I'd like that to be embarrassing by next year.