Anthropic just released Claude Routines and people are asking whether this eats the visual orchestrators like n8n, Langflow, Make and 26 others. Routines is Anthropic’s response to OpenAI’s OpenClaw and NVIDIA’s NemoClaw, it is part of AI’s expansion beyond prompt-response, to proactive agentic actions. This threatens the visual agentic orchestrators, but does it Pac-Man up their entire market?
Just last year, there were six acquisitions of visual orchestrators, like Flowise, Langflow, DeepConverse, Qualified, Convergence.ai, Moveworks. Eight others were funded, some valued north of a billion dollars. Are all of those companies victims of the AI model companies that are today’s apex predators? Is this yet another phase of the SaaSpocalypse?
It depends on how these companies, models, and orchestrators position and execute going forward. The visual orchestrators are focused on deterministic solutions, the agents perform consistent, compliant actions with solid observability and governance. They achieve this by leveraging an assembly model, assembling curated and deterministic components. They have more limited scope of action or flexibility to do anything, but what they do is consistent, compliant and legally defensible.
The AI model companies take a probabilistic approach where the agents solve any problem, but sacrifice some level of consistency, observability and compliance. They are betting on evolving guardrail technologies to make their solutions more compliant and therefore enterprise-ready.
This reminds me of the two approaches used by software firewalls: the orchestrators are betting on the whitelist approach of only allowing good things (curated components), while the model companies are betting on the blacklist approach of preventing bad things (guardrails). Many enterprises use both approaches in their firewalls, and they will use both approaches in their AI deployment as well. In other words, they will both move toward a combination of the two approaches.
How will this happen? Models will embrace assembly of deterministic components, like orchestrators. And orchestrators will adopt AI to build and validate long-tail components to provide more flexibility. They will both converge around vibe assembly with very limited and constrained vibe coding.
As it stands now, enterprise companies have serious issues with vibe coding. It simply does not work for regulatory, certification, liability, licensing, software supply-chain, SecOps review, and maintenance reasons. Everyone is playing with vibe coding, but for serious deployment these issues must be addressed. The models are almost exclusively doing vibe coding now.
The orchestrators also have a problem. They may support hundreds, or in some cases thousands of components, but at some point, they hit a functionality limit where they cannot address unique or long-tail features. There are two ways of addressing this problem: (1) the “code node” you write code to do what you need; (2) the vibe coded component. Both approaches break their value proposition. The code node breaks their business user assembly model, it requires coding expertise. The vibe coded component breaks their “assembly of secure, vetted components” model and plays into the hands of the model companies.
So what is the solution that addresses all of the enterprise requirements above, while providing the flexibility to address long-tail features? It requires a shift from vibe coding to assembly in combination with a massive community-powered approach to building, hardening, and vetting components.
You need a community-powered catalog of potentially millions of vetted components, from which companies can assemble their own catalogs of pre-approved “whitelisted” components that their users can assemble using their tool of choice: visual orchestrator, model, or agent. It requires a tool for creating the components, yes using AI, but using guardrails to force compliance. That’s not enough. They are now stored and reusable, since they’re in the catalog. But they need to be reviewed, tested, vetted, and approved for use. The test, review and vetting processes require a community of users who have eyes on each component, they have used them and hardened them in the process. Now that you have battle-tested components, enterprise customers need a workflow for pre-approving components for use; creating their own whitelist of components.
Once you have millions of public and private components, you need a way for models, agents, and orchestrators to find and use them. Agent Computer Interface (ACI) provides the standard mechanisms for each of those tools to find and use components in a scalable and efficient manner.
So back to our question, do models kill visual orchestrators? It depends on who gets to the combination approach and builds a user base first. Solving enterprise needs and establishing your solution as the preferred platform is the goal. If visual orchestrators embrace the code node or vibe coding, they play into the hands of the model companies. Both orchestrators and models need to move to the combination approach of securing runtime (the firewall blacklist analog), and assembling pre-approved components (the firewall whitelist analog). I suspect we will see heterogenous environments where multiple approaches are used. In fact, I also believe that model companies will acquire and integrate orchestrators to provide comprehensive solutions. For now, it is a race to earn enterprise adoption.
Note: my company ComponentFactory.ai is the arms dealer in this battle between orchestrators and models, we provide the component factory for building deterministic components as well as the community-powered catalog.
Like what you see? Share it with your friends.
