Shibin Das on Making Drupal Workflows Legible

Workflow logic often becomes the place where business rules, system architecture, human judgement, and runtime behaviour meet. For Shibin Das, founder of FlowDrop, that intersection has shaped a career that moved from embedded engineering and LabVIEW visual programming to Drupal contrib, Drupal PM, and AI-aware orchestration.

His argument is that workflow tooling should make execution legible, not merely automated. As Drupal teams add AI-assisted flows, external services, and long-running human approvals, Shibin frames FlowDrop as an editor and orchestration layer that keeps runtime ownership with the teams responsible for compliance, data, and governance.

The exchange, prepared by former TDT subeditor Alka Elizabeth, follows the technical line from Drupal PM maintenance lessons to ECA handoffs, AI nodes, contrib support pressure, and the principle Shibin calls legibility.

From embedded systems to visual logic

TDT [1]: Your career began with electronics engineering, embedded systems, LabVIEW, and Visual Basic before Drupal. How did that background shape the way you think about visual logic, workflows, and system behaviour?

Shibin Das: My first job out of college was at Audiolec Instruments in Pune, where I worked on circuit schematics that were handed off to automatic PCB design tools and then to a manufacturing team that was not always as technically trained as the engineers. That asymmetry shaped me early. Everything had to be planned upfront, and the downstream process would only honour what had already been made unambiguous. The same was true for the embedded software side.

Our instruments shipped from Pune to places like Delhi, nearly 1,500 kilometres away. A bug meant the device travelled back to the factory. So I learned to build systems that tolerated small issues without collapsing, and to think carefully about state, timing, and the messages moving between parts of a system. Some of that was bare-metal work, writing real-time logic with no operating system underneath, which trains a particular discipline around processes and how they coordinate.

Then there was LabVIEW. That was my first real encounter with visual programming, G programming, as they call it, where you drop virtual instruments onto a canvas and wire them together, and the wires themselves represent actual signals from industrial automation hardware. Combined with the CAD work I was already doing on schematics, I was living in a world where complex systems were drawn before they were written.

I did not imagine any of that would lead to Drupal, let alone to FlowDrop. But looking back, the through-line is obvious. Resilience, visual logic, and careful state management were not choices I made later. They were habits the work gave me, and they are probably also what drew me to tools like Langflow, Flowise, and n8n long before FlowDrop existed.

TDT [2]: Your Drupal.org account goes back more than 16 years. What did the Drupal community look like when you entered it, and what has changed most in how contributors build and maintain tools today?

Shibin Das: I came in just as Drupal 6 was released. The way I landed there was almost accidental. A colleague from another department at my company was running an e-learning project, a platform for selling courses, and one week before a critical demo, the contractors building it bailed. While the team was scrambling to find someone to take it over, I spent a few evenings trying things myself.

You May Like

Article

AI for Good Workshop to Discuss Open Source Generative AI Pilots

Article

AI for Good Workshop to Discuss Open Source Generative AI Pilots

WordPress on day one: reject. Joomla on day two: rejected. Drupal on day three: well, we are onto something here. Within 12 hours, I had a working concept for the e-learning platform, where folks in Drupal’s IRC channel literally hand-guided me from installing a WAMP server and installing Drupal and contrib projects to getting every last bit of Ubercart configuration working. As an embedded C developer who lived in machine language, getting that far on a PHP project that quickly felt unreal.

Later, that platform ended up being the longest-running thing I have built. It was used globally to train healthcare practitioners on how to operate a specific medical device. I stayed in electronics for some years after that, but Drupal had hooked me. I spent the next three years giving back the only way I knew how, sitting in the IRC channel, helping people through installation problems, debugging whatever they were stuck on, suggesting improvements where I could, or just being a rubber duck.

That was my real education. By the time I was ready to switch careers from embedded to Drupal full-time, IRC had already taught me the platform from the inside out. The biggest shift since then was the Drupal 7 to Drupal 8 upgrade. For module maintainers, that was a major overhaul.

Somewhere in that transition, I started noticing a different posture in how contrib was being built. The focus moved toward solutions that were more generic, more capable, and more architecturally elegant, but, in a way I am still trying to articulate, less complete. Ubercart vs Commerce. Opigno vs Drupal LMS. Organic Groups vs Group. In every case, the other option is a more flexible framework, but the older modules were closer to a finished product out of the box.

Whether that is the community changing or me changing, I honestly cannot say. And probably that is exactly why the pendulum has had to swing back. Drupal CMS is the community’s attempt to give users the more complete, ready-out-of-the-box experience they actually want. On the infrastructure side, the move to GitLab on Drupal.org has been a genuinely good thing too. That part of the ecosystem has matured well. But the warmth of IRC is gone. I miss Drupalicon, the little chatbot mascot that used to lurk in the channel with us.

TDT [3]: Among your early contributions were projects such as Storm and Drupal PM. What problems were you trying to solve with project management tools in Drupal, and what did that work teach you about Drupal’s strengths and limits as an application platform?

Shibin Das: I started contributing to Drupal PM because the company I was working at, around 50 people, was running its entire project management out of Excel files and OneNote. It was fragile. Things slipped, context got lost, and there was no real source of truth. I went looking for something that could give them structure without forcing them onto a heavy commercial tool.

Storm was a project management suite that already existed as a Drupal contrib module. I started using it for that internal project, and the way the community worked back then, the easiest path to getting it to do what I needed was to live in the issue queue: testing, replying, fixing things. Eventually, I became a maintainer, and the project was renamed Drupal PM.

It had a real run, and it spread further than I expected. Companies started using it as the base for their own internal PM solutions, building their own customisations on top of it. The module itself stayed almost dependency-free, but it had become infrastructure for other people’s stacks. When Drupal 8 arrived, those companies kept their PM systems running on Drupal 7 for as long as they could, because porting their bespoke layer was the real cost, not porting Drupal PM itself.

By the time Drupal 8, 9, and 10 had come and gone, the energy and interest needed to bring it forward simply were not there anymore. That is a lesson that has stayed with me about what success looks like for a contrib module, and what it costs. What that work taught me about Drupal as an application platform is something I still feel today.

The strength is hard to overstate. Drupal let me prototype an entire PM suite, model the domain, expose it through Views, and get a working tool in front of real users without writing much code at all. And when I did write code, the APIs were so well-integrated that a feature would just work with the permission system, with listings, and with the rest of the platform, because the framework had opinions about how integration should happen, even where there were technically many ways to do it. That meant I could concentrate on the solution and not on the plumbing.

I used to joke with colleagues building things in Java or vanilla PHP that the project I did in a month would have taken them two years. We take it for granted that Drupal ships with a permission system, user management, an entity model, and a query layer out of the box, but for application work, that is a serious head start. The limit Drupal PM exposed was not really technical. It was structural.

The deeper a contrib module embeds itself into the way real companies operate, the harder it becomes for the community to evolve it across major versions, because the cost of moving is not just the module. It is everyone’s customisations on top of it. That tension between building something useful enough to be depended on and keeping it light enough to evolve is something I have never really stopped thinking about. You can see its fingerprints in how I architect FlowDrop today.

Workflow ownership and reusable processors

TDT [4]: You have spent years building tools that help teams coordinate work. At what point did you begin to see workflow logic scattered across modules, hooks, configuration, and user interfaces as a structural problem rather than just a development inconvenience?

Shibin Das: The shift happened when I became Backend Professional Lead at Factorial. That is a mid-management role, and for the first time I had a real view across all the projects we were running, not just the one I was building. What I saw was that it was almost impossible to extract a useful feature from one project and reuse it in another.

The business logic was hardcoded into the modules. Either the code was tangled too deeply with the context it was written for, or refactoring it into something generic was a bigger investment than the next project’s budget could justify. So we would reinvent the same solution again, slightly differently, and then maintain three or four variants of it across different codebases. That is expensive in money, and it is expensive in attention.

When we looked closer at where the duplication actually lived, the pattern was consistent. It was almost always in the workflow layer. A workflow has business logic attached to it, often deeply, but the individual processing units inside that workflow, the steps themselves, are mostly agnostic. Send an email. Call an API. Transform a piece of data. Wait for a response. Those things do not care which project they are in. They became reusable the moment you separated them from the business logic that orchestrated them.

That diagnosis is what FlowDrop is built around. When you write a processor node for FlowDrop, you do not have to think about the business context it will be used in. The node is a clean unit. The business logic lives in the workflow that wires the nodes together, not inside the nodes themselves. That separation is the whole reason a node written for one project can be picked up and used in another without rewriting it, which is the exact problem we kept failing to solve when the workflow logic was scattered across modules, hooks, configuration, and UI layers.

TDT [5]: FlowDrop is described as intentionally “just” the editor, with no hosted control plane and no hidden backend. Why did you make that architectural choice, and what does runtime ownership give teams that a SaaS-first workflow tool may not?

Shibin Das: There is a backstory the marketing site does not tell. FlowDrop started as a Drupal contrib module. The original idea was to build a UI that would let people create and run AI agents on top of Drupal, and since the agent definitions and execution were going to live in a separate Drupal module, FlowDrop only needed to be the UI on top of that. That is the original meaning of “just the editor.” It was not yet a philosophical statement. It was a scope decision.

What changed as we built it was the realisation that the paradigm AI orchestration needs is fundamentally different from the one classical automation uses. Automation is predictive and deterministic: events trigger conditions, which trigger actions in a defined order. AI orchestration is goal-oriented. The system does not follow a predefined sequence. It figures out what to do next based on the data flowing through it and the goal it is working toward.

FlowDrop evolved to support that second paradigm. Once you accept that the workflow designer is really reasoning about what data flows through the system rather than what runs in what order, a lot of architectural choices become clearer. The early plan was to use an existing open source editor and build the application logic on top. But when we actually went looking, we discovered that the editors out there, Langflow, Flowise, and others, are tightly coupled with their own runtime. You cannot lift the drag-and-drop canvas out of Langflow’s JavaScript and reuse it on a different backend. The UI and the engine ship together.

So we built our own editor on top of SvelteFlow and ReactFlow. Credit to the creators of those libraries, because they gave us such a strong jump start that we could focus on the application layer instead of reinventing the canvas itself. That decision, keeping the editor cleanly decoupled from any specific backend, turned out to be the architectural choice that paid off the most. It is why FlowDrop today can run against any backend that implements an OpenAPI specification. The runtime does not have to be Drupal. It can be Laravel, Express, FastAPI, or anything else that speaks the spec.

What runtime ownership really gives teams is digital sovereignty. When the runtime is yours, the workflow executes on your infrastructure, the data passing through it stays on your infrastructure, the logs and audit trails are yours, and the decision about which AI provider to call, and whether to call one at all, is yours. A SaaS-first workflow tool cannot give you that, because the runtime is its product. Your data has to pass through it. Your AI calls go out from its network. Your compliance story has to include theirs.

For organisations that take sovereignty seriously, such as the public sector, healthcare, regulated industries, or anyone building under GDPR or the EU AI Act, that is not a feature comparison. It is a precondition. FlowDrop is built so that the question of where the work happens never has to leave the team using it.

TDT [6]: FlowDrop separates workflow editing from workflow execution. How do you decide which responsibilities belong to non-engineers configuring a flow and which responsibilities must remain with engineers who own the runtime?

Shibin Das: The question assumes two roles, non-engineers configuring flows and engineers owning the runtime, and that is a fair starting point. In practice, FlowDrop is built around three. There is the process plugin developer, who contributes new processors to FlowDrop, the units of work that nodes represent. There is the site builder, who composes those processors into actual workflows for automation or orchestration. And in between, there is a role we kept finding ourselves needing, which we call the site administrator.

That is usually IT, or whoever owns the platform inside the organisation. Their job is to decide which processors are exposed to site builders, and on what terms. That middle layer is what makes the system safe to use. A process plugin developer who exposes, say, a generic entity save processor does not and should not have to think about every site’s access logic or content policies. They write a clean, general-purpose unit.

The site administrator then takes that generic processor and constrains it for their specific environment. They might expose entity save only for one bundle, only allow the title and description fields to be updated, or only permit publishing of a particular article type. That same generic node can then be used by a site builder to automatically generate teaser titles or descriptions, without the site builder ever needing to understand the underlying entity API or the permissions model.

So the answer to where the line falls is less about engineers vs non-engineers and more about who carries which kind of responsibility. Process plugin developers carry the responsibility of writing processors that do not presume their context. Site administrators carry the responsibility of shaping which capabilities exist in their environment and under what constraints. Site builders carry the responsibility of composing those constrained capabilities into workflows that solve real business problems. Each persona only thinks about what they actually own.

This separation was not designed in a vacuum. It grew organically because the situations we were using FlowDrop in already had these three roles, just usually without a clean place for them to sit. FlowDrop ended up giving them one.

ECA, handoffs, and the async threshold

TDT [7]: In Drupal, ECA already provides event-condition-action automation through Drupal events, plugins, models, and configuration. Where do you see the boundary between a Drupal-native automation system such as ECA and a backend-agnostic workflow editor such as FlowDrop?

Shibin Das: I worked through this publicly in a session at Drupal Dev Days in Athens, and the way I framed it there is still how I see it. ECA is the workhorse of automation in Drupal. It is also the natural touchpoint, the place where signals enter the system. An incoming email, a user logging in, a node being saved, or a comment being updated: ECA picks up that signal and reacts. For the enormous range of automation needs Drupal sites actually have, ECA is the right tool, and it should be the first tool a team reaches for.

Where FlowDrop comes in is when the flow that ECA started needs to do something more advanced than react. The clearest signal that you have crossed that boundary is time. ECA is fundamentally synchronous and reactive. FlowDrop is built for flows that have to wait, whether for a response from a user, for an external API to call back, or for a human to approve something.

That wait might be seconds, minutes, or days. The flow might be handed off to a different user. The execution might need to pause, persist its state, and resume cleanly when the world is ready for it. That is not what ECA is shaped to do, and it should not have to be. ECA delegates that kind of flow to FlowDrop, FlowDrop runs it, and the two systems coordinate.

So in practice, the boundary is not a wall. It is a handoff. ECA owns the reactive layer and the entry points. FlowDrop owns the advanced, async, long-running, human-in-the-loop layer. Together, they cover a much wider surface than either could alone, and they let teams pick the right layer for the right problem instead of forcing one tool to do everything.

The longer-term answer to where this boundary lives is something we are actively working on as a community. Jürgen, Randy, and I have started building a shared language between ECA, Maestro, and FlowDrop, so that systems like these can talk to each other cleanly. The goal is that a process plugin developer should not have to decide which ecosystem they are writing for. The same plugin should be usable across these tools. And a team choosing a solution should not have to commit to one engine to get the capabilities of another. Drupal already has the pieces for orchestration. The work ahead is to connect them.

TDT [8]: For a Drupal architect already using ECA successfully, what kind of project would make FlowDrop worth considering? Is it multi-platform orchestration, AI-assisted flows, external service coordination, developer experience, or something else?

Shibin Das: If you are already using ECA successfully, you do not need FlowDrop. That is the most honest place to start. ECA is the right tool for the overwhelming majority of automation needs on a Drupal site, and the worst reason to bring in FlowDrop would be because it is the newer, shinier thing.

The question lists four candidates for when FlowDrop becomes worth considering, and I would answer them in order of how clearly they apply. AI-assisted flows is the clearest case. The moment a workflow involves an LLM making a decision, calling a tool, waiting for a response, and then deciding what to do next based on what came back, you have left the event-condition-action paradigm entirely. You are no longer reacting to a signal. You are orchestrating around a goal. That is what FlowDrop is built for.

External service coordination is the second clearest case, and it is really the same test as the previous question: anything that has to wait. If your flow calls an external API and that API answers asynchronously, if it pauses for a human approval that might take three days, or if it needs to hand a process off to a different user mid-flow, those are flows that need pausing, persistence, and clean resume. ECA is not shaped to carry them.

Multi-platform orchestration is a real benefit, but I would treat it as a side effect rather than a reason to switch. Because FlowDrop is backend-agnostic, the same editor and the same flow definitions can run against a Drupal backend today and a Laravel or FastAPI backend tomorrow. That matters a lot if your organisation runs more than one platform, but if you are a Drupal-only shop, it is a nice-to-have rather than a decision driver.

Developer experience is a framing I would push back on. FlowDrop is not trying to replace ECA on developer ergonomics, because ECA is excellent at what it does. FlowDrop has its own DX strengths, especially the visual canvas and the data-flow-first way of reasoning about a workflow, but choosing FlowDrop because you prefer its UX would be choosing the right tool for the wrong reason.

So the practical advice for a Drupal architect already happy with ECA is to stay with ECA. Reach for FlowDrop when an AI agent enters the picture, or when a flow has to live longer than a single request, the kind of flow that crosses async boundaries, involves external services answering on their own schedule, or pauses on a human in the loop. That is the threshold where FlowDrop starts earning its place in the stack.

Low-code debt, contrib maintenance, and LLM costs

TDT [9]: Low-code and visual workflow tools are often criticised for creating hidden technical debt. How does FlowDrop make flows inspectable, maintainable, testable, and version-controllable over time?

Shibin Das: I would push back on the premise. Drupal has been a low-code platform for a very long time, and we do not routinely accuse it of accumulating hidden technical debt. So why should a tool built as a Drupal contrib module be any different? I think the criticism is not really about low-code. It is about a particular shape of low-code that has become dominant in the SaaS era: vendor-locked platforms where the team using the tool has no ability to inspect, modify, or fix the underlying system. They follow the vendor’s roadmap, and they accept whatever opacity comes with that. Technical debt in those systems is real, but it is a consequence of the lock-in, not the visual paradigm.

FlowDrop is a Drupal contrib module, and now also a backend-agnostic editor, but the relationship to the codebase is the same as any other contrib module in the ecosystem. If you find a bug, you can open a merge request and fix it. If you need a behaviour the maintainers do not prioritise, you can pay someone to build it, or build it yourself. The roadmap is public, the code is public, the architecture is public. That alone removes the largest source of technical debt people associate with low-code tools.

The practical answers to the four properties the question asks about follow from the same principle. Flows in FlowDrop are stored as Drupal config entities, which means they are exported via drush config:export and live in Git alongside the rest of your site configuration. That gives you proper version control, diffs in code review, deployment through your existing CI pipeline, and rollback through your existing tooling, with nothing new to learn. Inspectability comes from a full execution log per flow run: every node that ran, every input it received, every output it produced.

When something goes wrong in production, a developer can open the flow run and see exactly what happened at each step, which is something most low-code tools do not give you. On testing, process plugins, the underlying units, are unit-tested the way you would test any other Drupal plugin, and flows themselves are covered through integration tests. Maintainability comes for free as a consequence of the other three: code in Git, executions you can inspect, and units you can test. That is how you keep a flow healthy over years.

None of this makes technical debt impossible. A team can still build a tangled, undocumented flow in FlowDrop the same way it can build a tangled, undocumented Drupal site. The tool does not enforce discipline. But it gives a team that wants to be disciplined the materials to do so, and it does not put a vendor between them and their own system.

TDT [10]: You built a working chat-based visual workflow builder for Drupal but hesitated to release it on Drupal.org because of the maintenance burden around LLM-driven contrib. What does that hesitation reveal about the current contrib model and AI-powered modules?

Shibin Das: The hesitation reads differently in the original post than the way the question summarises it. My default when I am thinking about releasing something is to test the waters first, to ask whether there is a real need for it, whether anyone would actually use it, and what shape it ought to take in the ecosystem before I commit to maintaining it. The LinkedIn post to which the question refers was that kind of conversation. It was not a verdict on LLM-driven contrib. It was me asking the community three concrete questions before deciding.

Since then, I have released it as part of FlowDrop itself, rather than as a standalone module. That placement was one of the questions I asked the community, and the answer that emerged from those conversations was that it belongs alongside the workflow editor it is designed to drive. The decision to ship came down to a straightforward weighing: the concerns I raised in the post are real, but the value of putting this in front of people who can actually use it outweighs them. That is not a triumphant answer. It is an honest one. You do not resolve those concerns by waiting longer. You resolve them by shipping and learning what the real maintenance burden looks like in practice.

The concerns themselves are still worth naming because they reveal something about where the contrib model is feeling strain. The volunteer maintenance model was designed in an era where bugs were reproducible, dependencies were stable, and a module’s scope was something you could draw a box around. LLM-driven modules break those assumptions in specific ways. Prompts regress silently when providers update their models. Your module has not changed, but its behaviour has. Token costs shift under you, sometimes in ways that change what is economically viable for users.

Safety work is never done, because every new way a user might phrase a request is a new edge case. And the support surface includes the entire space of natural language input, which means an issue queue ticket can be genuinely unreproducible. None of that makes LLM-driven modules impossible to maintain in contrib. But it does mean a maintainer takes on a qualitatively different commitment than they would for a deterministic module.

The traditional contrib model, find a bug, file an issue with reproduction steps, get it fixed in a release, assumes a stability that LLM-driven tools genuinely do not have. That is not a criticism of contrib. It is an honest acknowledgement that the model needs to evolve to accommodate a new category of module, and we as a community have not fully worked out what that looks like yet. I shipped because I would rather work that out alongside the people using the tool than guess at it from the outside.

TDT [11]: You have argued that one large AI skill can be slower than many small ones, partly because of context-window growth. How does that principle influence the way FlowDrop structures AI-assisted workflows?

Shibin Das: Let me come at this from a different angle. There is a Hindi term that captures what I was actually chasing when I ran that experiment: paisa vasool (पैसा वसूल). It roughly translates to “getting your money’s worth.” It is the feeling that every rupee, every cent, every token spent is delivering real value in return. In the LLM economy, you could call it Token Vasool, the satisfaction that every token in your context window is earning its place. When you are paying per LLM call and watching your inference bill, that is the instinct that drives you to optimise. And the move that feels like Token Vasool is one big prompt, one call, less friction. Surely fewer round-trips means better value.

So I tried it. I had a five-step AI workflow that ran in ten to 15 minutes as a chain of small focused skills. I combined them into one master skill, with the same model, same tools, same logic, and just one prompt instead of five. It took up to an hour. Four to six times slower, for the same work. The Token Vasool I was chasing was hiding in the opposite direction.

The reason matters more than the number. When you hand a multi-step job to a single LLM context, that context becomes both the planner and the executor. By the time the model reaches step four, it is wading through the outputs of steps one, two, and three before it can even start. Modern infrastructure, KV caching, FlashAttention, and batching, softens what would otherwise be an O(n²) penalty toward something closer to linear, but the cost does not disappear.

A four-to-six-times slowdown on a five-step workflow is not a rounding error. It is the difference between a tool you reach for and a process you have to schedule. And that is before you account for the fact that LLMs are genuinely poor at long-horizon state management and recovery from partial failure. They are excellent at focused reasoning in a bounded scope. Orchestrating a multi-step workflow is not that.

That observation is exactly what FlowDrop is built around. In FlowDrop, the workflow decides what runs next. The LLM only executes the step it is handed. Each node in the graph receives only the context it needs, produces a defined output, and the engine moves the state forward. That has three concrete consequences. Each step runs with a bounded, predictable context, with no accumulating pollution. A failure in one step is isolated and restartable, because the engine knows which node failed and what state it had. And the workflow itself becomes inspectable and auditable as a graph, rather than living inside an opaque prompt.

There is a quieter benefit too. When you have to define what goes into a node and what comes out, you are forced to think clearly about the handover boundaries: what does this step need, what should it produce, and who decides whether it succeeded? Those boundaries are where a lot of hidden value lives. Collapse them into a single prompt and the LLM starts improvising the handover logic, which is where you get inconsistent, sprawling runs. Make them explicit in a workflow graph and the system stays sharp.

So the influence on FlowDrop is direct: the editor exists because keeping orchestration logic outside the model is the right structural choice, and a visual graph is the most honest way to express that structure. The real Token Vasool of working with LLMs is not fewer calls. It is smaller, sharper calls composed by a system that knows what it is doing. Small and sharp beats big and blunt. Every time.

Agents, governance, and legibility

TDT [12]: What is the practical difference between a workflow and an AI agent in the FlowDrop ecosystem? Where should teams draw the line between deterministic workflow execution and agentic decision-making?

Shibin Das: Honestly, that is the million-dollar question everybody is trying to answer right now, and I do not think anyone, including me, has a definitive answer yet. The pace of change is part of the reason. A book on this topic would be out of date before it reached print. Frontier capabilities that exist today might be priced out of reach tomorrow when a subsidy gets pulled or a provider changes its terms. The model you architect around in March is not the model you would architect around in October. So a tidy taxonomy of workflow on this side of the line, agent on that side, would be the wrong kind of answer to give. It would be obsolete by the time you read it.

What I can say is what teams should actually optimise for, which is the ability to keep shifting the boundary as the world moves. In FlowDrop, the practical difference between a workflow and an agent is not philosophical. It is a question of how much decision-making you let the LLM hold inside one node. A deterministic workflow is a graph where every transition is decided by the engine. An agentic node is a node where the LLM is allowed to decide what happens next from a set of available options, within bounds the system defines. You can have both in the same flow. You can move logic from one side of the boundary to the other as you learn what works.

That flexibility is the actual answer to the question. Today, you might trust an agent to pick which of three downstream tools to call. Tomorrow, you might pull that decision back into the deterministic graph because the cost of getting it wrong went up, or because a cheaper non-frontier model cannot be trusted with that decision anymore. Or the reverse: a step that used to need explicit branching becomes something an agent handles cleanly because the models got better. The boundary moves. The system has to let you move with it.

So the line between workflow and agent in FlowDrop is intentionally something a team can adjust, not something the tool dictates. The teams that will do well with AI orchestration over the next few years are the ones who can experiment, observe what happened, and shift the boundary based on evidence. The teams that will struggle are the ones who committed to a fixed taxonomy and built around it. I would rather hand people a system that admits the question is open than one that pretends it has been settled.

Keep tuning. Keep observing. Be ready for the ground to move.

TDT [13]: FlowDrop AI and FlowDrop Agents suggest a broader direction for the project. What are you building toward, and how do you prevent AI orchestration from becoming opaque or difficult to govern?

Shibin Das: Honestly, FlowDrop AI and FlowDrop Agents are projects being developed and maintained by my colleague David Galeano at Factorial. My focus is on the orchestration and the editor side. David’s focus is on the AI and agents side. We work on the same product but on different layers, and the beauty of FlowDrop being decoupled is that he can repurpose the orchestration foundation for very specific AI use cases without me being in his way.

If you want to know what is coming next on that side, the honest answer is that you should ask David. I have my own picture of where it might go, but he has surprised me too many times with what he can come up with for me to feel comfortable speculating on his behalf. What I can answer is the second half of the question, which is the one I think about a lot: how do you prevent AI orchestration from becoming opaque or difficult to govern? Because that is a property of the orchestration layer, not the AI layer, and that part is mine.

The short answer is that the orchestration layer is where governance lives, not the model. Every decision a flow makes, every transition, every branching choice, every handover from one node to the next, happens inside the engine, not inside an LLM context. That means every decision is something you can log, inspect, replay, and audit. When an AI node is part of a flow, the model decides what it should output. The orchestration layer decides what happens with that output, where it goes next, and under what conditions. That separation is the whole reason an AI-assisted flow in FlowDrop is something you can govern at all. Collapse the two, let the model decide and execute and route, and you lose the only place where governance can attach.

Beyond that structural choice, three things keep AI orchestration from becoming opaque in practice. The flows themselves are version-controlled as Drupal config, so you can see exactly what changed and when. Every flow run produces a full execution log, showing which nodes ran, what they received, and what they returned, so there is no hidden state. And the AI nodes inside a flow are still nodes, which means they are constrained by the same input and output contracts as any other node. The model cannot quietly take over a workflow because the workflow is the graph, and the graph is what the engine reads.

The longer answer is that governance of AI systems is not a problem that gets solved once. It is a problem that gets re-solved as the systems change. What FlowDrop tries to do is keep the orchestration layer transparent enough, and the AI layer bounded enough, that teams have somewhere honest to attach their governance practices, whatever those practices need to be tomorrow.

TDT [14]: Looking back from embedded engineering to Drupal PM and FlowDrop, there seems to be a recurring concern with giving teams more control over complex systems. Is control the central philosophy, or is there a more precise principle behind your work?

Shibin Das: You are onto something real. There is a thread of control running through everything I have built, from the embedded systems I designed to operate without breaking when they were hundreds of kilometres from anyone who could fix them, to Drupal PM, to FlowDrop. Giving teams more control over complex systems has clearly been part of it. But if I sit with the question honestly, I think there is a more specific principle underneath the control instinct, and naming it more precisely might be more useful than agreeing with the general framing.

What I keep coming back to is this: business logic and the code that implements business logic live in two different worlds, and the gap between them is where most of the dysfunction shows up. Business people genuinely do care about the flow. They care about what happens when a customer signs up, what happens when an invoice goes overdue, and what happens when a piece of content needs approval. What they do not care about, and should not have to care about, is learning a programming language, firing up Xdebug, and stepping through code to figure out what is actually happening inside one of those flows. That is not their job. But because of how most systems are built, that is the only way to get an accurate answer to what is fundamentally a business question.

My experience has consistently been that the more contextual information business owners have about the systems running their operations, the better the decisions they make. Not because they are going to become engineers. Because they are going to make better choices about what to build next, what to invest in, what to retire, and where the actual constraints are. The opacity is not protecting anyone. It is just keeping the people who own the outcome away from the information they need to own it well.

FlowDrop is one attempt to close that gap. A flow as a visual graph is something a business owner can read. An execution log showing which node ran with which inputs is something a business owner can investigate. A version-controlled change to a flow is something a business owner can review and ask questions about. None of that requires custom-built dashboards or bespoke admin tooling. It comes from the architecture itself. The system is honest about what it is doing, and that honesty is available to anyone who needs it, not just to the engineers who built it.

So if I had to name the principle more precisely, it is something closer to legibility. Make complex systems legible to the people who depend on them, so they can make informed decisions about them. Control follows naturally from that. When you can read a system, you can shape it. But the foundation is whether the system is willing to be understood in the first place.