There's this magnetic appeal to use a visual graph editor as the UI paradigm for your app.. it seems to fit so many problems well.
Yet if you complicate the problem just a notch, the graph becomes big fast and that renders like complex spaghetti you're afraid to touch in the UI.
The other problem is that the UI paradigm becomes the driver - you try to think of the problem in terms of fitting it into the UI graph editor, which is often not a natural way of thinking about said problem.
All of this to say is that I've always thought that graph/flow editors looked cool, except I've never found good use for them in practice except for very simple and predictable graphs.
Just writing the flow as a data structure in text is often a lot simpler and practical..
Deterministic workflows still have plenty of use cases. AI agents can help build them, but can’t replace them when predictable and auditable execution matters, because agents are inherently nondeterministic.
That said, Relay.app announced its shutdown a few weeks ago, and now Flowise is winding down too. I wonder whether coding agents are really the cause, or whether these products simply struggled to find a sustainable market.
Disclosure: I’m building Aqua Blue (aquablue.app) around a related idea: AI builds the workflow, but fixed rules run it.
Full disclosure I'm a founder of cbk.ai and chatbotkit.com, where we've built reusable agent components. I have never really saw flowise, n8n the now defunct OpenAI agent builder and other similar products as competitors and I wanted to describe why.
I think workflow builders are mostly the wrong mental model for AI. A graph of predefined nodes and edges is useful when you already know the exact sequence of work.... but the point of an AI agent is that it can decide what to do next from the current context.
IMHO reusable building blocks still matter enormously. You should not have to recreate an integration, a capability, or a piece of reliable deterministic logic every time. It is wasteful and you cannot oneshot it. Even with coding agents which we use all the time system to system connectivity is more complex than writing the code. But those should be available to the agent as tools, mechanics, and features that are not wired together as a visual workflow of sorts.
A product can look graph-like at a glance though, while avoiding making a workflow builder. I think this still matters in order to put a mental model around it. But the mechanism should not be graph / workflow like in practice.
I think you tend to need both. There's certain deterministic data and steps that surround the agent as well as certain agentic steps where the LLM is controlling the execution flow.
n8n had an LLM step, not sure if they had an "agent" step. For instance, your workflow could pull down Google Docs using their connectors and deterministic steps then run something agentic with the contents, then upload the contents to Google Drive or send an email.
There is something about agent workflow builders not gaining as much traction as they could have. Open AI also launched something in house and they are also shutting it down
OpenAI is deprecating Agent Builder. Existing users can continue using it during the transition window, and the product is scheduled to shut down on November 30, 2026. ChatKit remains available. See the deprecations page for the current timeline.
Correct and I think for non technical folks just creating pure ai agents is much easier than creating these workflows which can be harder to test as well.
This will come with higher risks, no transparency, and higher costs, of course. That seems like a recipe for even higher frustration than normal software incurs.
There does seem to be a need for a semi-deterministic workflow where nodes in the workflow are agentic, i.e., powered by LLMs, but the workflow itself remains deterministic. Lets say my daily workflow is to download a PDF from some website, extract some information from it, and email that information. I cannot just ask an agent to script this workflow, because the website will keep changing, the PDF layout will keep changing, etc. I need a "download agent", an "extract info" agent, and so on which will examine the website, PDF, etc. and generate any one-off scripts everytime the workflow is run.
My solution for that is to use skills and add a omnibus shell script in each particular skill folder that does all the deterministic steps and then write the skill markdown to only use the script, usually passing a command line step parameter to the script. I also usually add a note in the skill markdown that it should monitor how it calls the script and suggest any improvements when the skill is used.
As an example I have a `today` skill that has a today.sh script that can check my email, bug tracker, calendars, custom timesheet system and other systems via the script and then the skill assembles a nice summary of what is happening today along with a suggested schedule.
I‘m wondering what that means for products like retool. I used it a lot in the past for internal tooling but it’s now a a segment where coding agents are likely to be a better fit, and the AI integration within retool is messy compared to just letting Claude create the web app
The problem that workflow engines solve (configurable code) is just better solve with agents just maintaining the code.
2 years ago (during the agentic workflow boom) prompting was annoying and tedious. Context was small, harnesses were weak. You needed to string along multiple complex prompts to get anything done.
Now, you can give an agent 50+ tasks and it will churn through them.
>Over the last few months, we've noticed a significant shift in how people build. As AI models become more capable at reasoning, we've noticed that developers are increasingly relying on new coding agents such as Claude Code/OpenClaw to handle complex tasks. The typical rigid workflow low code approach quickly hits the limit when it comes to complexity.
Their front page says ‘design agents visually’ so their target market was less skilled devs/non devs.
So not sure why they are giving the reason if closer as cli related when low code and cli are different markets.
I feel like there's a fundamental shift in the user interface that's causing this. People are starting to expect an "agentic interface" - that they are able to give kinda vague inputs and nudge things to work in a way they like, over the traditional experience of having increased clarity at the cost of increased setup (drag and drop, many UI first interfaces, etc).
I was editing a google doc yesterday and found it annoying that i had to find the "link" option from the context menu instead of just saying "turn links into links" and moving on.
This imo impacts everyone, regardless of how developer-ey you are. Perhaps non-devs expect a "friendlier"/more "agentic" interface now? Don't have the right vocabulary to explain.
I remember Flowise app being well-intended but bad. I evaluated the self-hosted version to be used as a component in an internal tool so non-technical people can tweak their prompt chains without writing code. As far as I remember:
1. it became increasingly slow as I added flows (felt like a O(n^2) ish bottleneck)
2. There were many bugs and bad UX
3. the flow variable system was underbaked and underdocumented
4. feature gaps
I decided I was probably not the target audience for their app and moved on.
Flowise was acquired by workday, so I'd take this with a grain of salt.
However, I agree with the reasoning. I don't see a future for visual workflow builders. They are used to define plumbings that can be defined by a 50 line python script.
A non-technical user does not need to draw this workflow. They can just ask an agent to write that code for them, to debug it, to visualize it. All workflow builders now have an AI chat where you ask the agent to build the flow for you. Why not skip the flow part?
I'm pretty biased though since that's the thesis behind what I am building.
I would counter and say it’s understanding that makes the difference.
Having an AI generate 50 lines of code that you assume will do the job is a little different to creating a flow that you understand and maintain.
AI is really good at making everything seem so simple and easy, until it breaks. But then again, just use another AI to fix it.
So then there is an agent orchestration layer for coordinating multiple agents with multiple personalities, role playing multiple parts in a comedy called software development.
We still don’t know what they are really doing but does that matter? Does knowledge, experience, learning and failing even matter if AI is doing it for us?
"Over the last few months, we've noticed a significant shift in how people build. As AI models become more capable at reasoning, we've noticed that developers are increasingly relying on new coding agents such as Claude Code/OpenClaw to handle complex tasks." is true when your primary users are developers. But no-code workflow is still valuable at scenarios where determinism is required.
I'm building an agentic compliance platform where every procedure needs to follow company policies and operated on the rigid plan, but the procedure itself is different for every customer. Coding agents could in principle generate the necessary workflow for each company, but they need to integrate with millions of other applications in the company, easy to review and modify.
We built our own workflow builder because every other existing solution is too complicated and doesn't meet compliance requirements. The workflow builder itself was coded by Claude, and it's working wonderfully.
So flowise's shutdown is because their business is targeting a specific sector which doesn't need it anymore, not because workflow builder itself is not useful.
Whilst the UI provides visibility and guardrails, it also reduces flexibility. But now with LLM coding agents, it often gets in the way. Working with text/code is easier.
"Visual graph editor for AI workflows" seems like an extremely saturated market (Langflow, n8n). Consolidation seems natural as the agent engineering industry matures.
With the speed everything is going now, nobody has time to learn nice visual tools. They set their AI agents an objective and leave them to iterate until the objective is reached.
as a person who spent years building flow.ai before flowise.ai, i'd say drag n drop ui was dead on arrival it works for a set of very hand picked cusomers , the rest were in a weird spot between people who can code( and think accordingly ) and don't.
You hit the nail on the head. A couple years ago I started prototyping a similar node based AI workflow builder which worked well but everyone I showed it to was either; confused at how to use it (even for super basic stuff), or liked it but poked holes by asking "can it do x, can it do y" which it couldn't. There is such a small niche of people technical enough to use something like this that wouldn't just opt in for coding it themselves (especially with AI assisted coding nowadays)
I do still use a part of it on one of my projects for building multi-step image processing pipelines for AI property photo editing (ffocal.io for the curious) that are configurable in the admin panel and it works super well and is useful for modifying and testing pipelines. So there are use cases, they're just very narrow
Trying to make an harness and not falling behind with how fast those frontier model evolve is hard. We've built our own harness to make games, but it became obsolete as soon as a new model dropped. Gave up and now just letting user use whatever harness they want on their side.
It lacked so many features that n8n and Langflow offered, so I'm not sad about it, but it was the first visual agentic workflow builder that I tried and I wish they could make it somehow.
Disclosure up front: I build LLMGraph (llmgraph.ai), a hosted product in the same category, so I have a horse in this race.
The interesting part of the announcement is the stated reason: "developers are increasingly relying on new coding agents" and "rigid workflow low code approach quickly hits the limit when it comes to complexity." I think that's half right. Coding agents are clearly eating the developer end of this market. But a lot of Flowise usage was never developers; it was teams who wanted to design an LLM pipeline visually, hand it to a non-engineer to tweak prompts, and deploy it without owning infrastructure. That need didn't go away this week, and telling those users to fork and maintain a large TypeScript codebase themselves is not a real answer for them.
For anyone running Flowise in production, the practical decision is fork-and-maintain versus migrating somewhere maintained. Forking is a bigger commitment than it sounds: you own dependency updates, security patches, and model API churn indefinitely, and the contributor community that used to absorb that work is dispersing. Worth being honest with yourself about whether your team will actually do that maintenance before the first CVE forces the question.
I had built https://codeflow.co long ago - a workflow style integration platform (pre-AI). I could see less interest while showing the product to users in recent years as AI was catching up.
The sales demo that excited users - hey you can drag and drop and build stuff - which was pretty exciting few years ago - was seen as a burden by user (especially if they had to pay/license it) - they started asking why can't AI do it for me?
However n8n and other platforms embraced AI and AI automation was a thing for a while until the coding agents caught up. Now I believe drag and drop builders are not a buzz anymore where Claude has become a verb.
Being a visual person I do see value of debugging code "flowing" visually but not many are/were in the same boat. Since then I have pivoted to https://nexaflow.com - which is more like just tune the prompt and get your AI going instead of wrestling with the flow yourself - but I do feel a gap somewhere between the two spectrums - enterprises who would need high level of customization but wont believe in vibe code may be - but that could be a very tiny niche..
I've been pondering this recently. There have been loads of trivial automation targets throughout the economy for years but they haven't really been fixed, despite being a small Python script (things like converting one csv file to another). Why do we suppose LLMs are suddenly going to fix them? I guess the overhead is possibly lower now, but I suspect there are other barriers to automation that most techies can't comprehend.
There's this magnetic appeal to use a visual graph editor as the UI paradigm for your app.. it seems to fit so many problems well.
Yet if you complicate the problem just a notch, the graph becomes big fast and that renders like complex spaghetti you're afraid to touch in the UI.
The other problem is that the UI paradigm becomes the driver - you try to think of the problem in terms of fitting it into the UI graph editor, which is often not a natural way of thinking about said problem.
All of this to say is that I've always thought that graph/flow editors looked cool, except I've never found good use for them in practice except for very simple and predictable graphs.
Just writing the flow as a data structure in text is often a lot simpler and practical..
Deterministic workflows still have plenty of use cases. AI agents can help build them, but can’t replace them when predictable and auditable execution matters, because agents are inherently nondeterministic.
That said, Relay.app announced its shutdown a few weeks ago, and now Flowise is winding down too. I wonder whether coding agents are really the cause, or whether these products simply struggled to find a sustainable market.
Disclosure: I’m building Aqua Blue (aquablue.app) around a related idea: AI builds the workflow, but fixed rules run it.
Full disclosure I'm a founder of cbk.ai and chatbotkit.com, where we've built reusable agent components. I have never really saw flowise, n8n the now defunct OpenAI agent builder and other similar products as competitors and I wanted to describe why.
I think workflow builders are mostly the wrong mental model for AI. A graph of predefined nodes and edges is useful when you already know the exact sequence of work.... but the point of an AI agent is that it can decide what to do next from the current context.
IMHO reusable building blocks still matter enormously. You should not have to recreate an integration, a capability, or a piece of reliable deterministic logic every time. It is wasteful and you cannot oneshot it. Even with coding agents which we use all the time system to system connectivity is more complex than writing the code. But those should be available to the agent as tools, mechanics, and features that are not wired together as a visual workflow of sorts.
A product can look graph-like at a glance though, while avoiding making a workflow builder. I think this still matters in order to put a mental model around it. But the mechanism should not be graph / workflow like in practice.
I think you tend to need both. There's certain deterministic data and steps that surround the agent as well as certain agentic steps where the LLM is controlling the execution flow.
n8n had an LLM step, not sure if they had an "agent" step. For instance, your workflow could pull down Google Docs using their connectors and deterministic steps then run something agentic with the contents, then upload the contents to Google Drive or send an email.
There is something about agent workflow builders not gaining as much traction as they could have. Open AI also launched something in house and they are also shutting it down
https://developers.openai.com/api/docs/guides/agent-builder
OpenAI is deprecating Agent Builder. Existing users can continue using it during the transition window, and the product is scheduled to shut down on November 30, 2026. ChatKit remains available. See the deprecations page for the current timeline.
I think it's the cost (both tokens and initial setup and debugging the workflow).
It's really easy to spend a gazillion tokens by mistake and the resulting workflows are still probabilistic and open for abuse or failure.
Maybe it's too soon, we need more time to figure out what works and what doesn't.
We're still looking for the right balance for when a probabilistic solution (i.e AI) works and when we need a deterministic one (classic software).
Correct and I think for non technical folks just creating pure ai agents is much easier than creating these workflows which can be harder to test as well.
This will come with higher risks, no transparency, and higher costs, of course. That seems like a recipe for even higher frustration than normal software incurs.
There does seem to be a need for a semi-deterministic workflow where nodes in the workflow are agentic, i.e., powered by LLMs, but the workflow itself remains deterministic. Lets say my daily workflow is to download a PDF from some website, extract some information from it, and email that information. I cannot just ask an agent to script this workflow, because the website will keep changing, the PDF layout will keep changing, etc. I need a "download agent", an "extract info" agent, and so on which will examine the website, PDF, etc. and generate any one-off scripts everytime the workflow is run.
This is exactly what I’ve been building with ctx.traits :)
https://ctx.company/traits/docs/
My solution for that is to use skills and add a omnibus shell script in each particular skill folder that does all the deterministic steps and then write the skill markdown to only use the script, usually passing a command line step parameter to the script. I also usually add a note in the skill markdown that it should monitor how it calls the script and suggest any improvements when the skill is used.
As an example I have a `today` skill that has a today.sh script that can check my email, bug tracker, calendars, custom timesheet system and other systems via the script and then the skill assembles a nice summary of what is happening today along with a suggested schedule.
And without an LLM you wouldn't even try?
I don't mind semi-deterministic for plenty of things. But these agents like hermes, can codify a skill to be deterministic.
n8n will do that
Because it is a workflow builder. It is the wrong mental model. Agents and workflows are completely different things.
I‘m wondering what that means for products like retool. I used it a lot in the past for internal tooling but it’s now a a segment where coding agents are likely to be a better fit, and the AI integration within retool is messy compared to just letting Claude create the web app
The problem that workflow engines solve (configurable code) is just better solve with agents just maintaining the code.
2 years ago (during the agentic workflow boom) prompting was annoying and tedious. Context was small, harnesses were weak. You needed to string along multiple complex prompts to get anything done.
Now, you can give an agent 50+ tasks and it will churn through them.
Flowise was cool. I used to to help build an enterprise employee search tool with it a few years back. https://medium.com/better-programming/employee-search-with-o...
The fact is, there's not as much need for drag-n-drop low code tools anymore. At least I don't have much need.
Flowise was acquired by Workday in August 2025 [1].
At the time, they posted "Flowise isn’t going anywhere, we’re doubling down. In fact, we’re only just getting started!" [2]
I wonder if "keep the platform running for >= 1 year post-acquisition" was part of the terms! Ah well, another one for Our Incredible Journey [3]...
[1] https://newsroom.workday.com/2025-08-14-Workday-Acquires-Flo...
[2] https://www.linkedin.com/posts/flowiseai_were-thrilled-to-sh...
[3] https://ourincrediblejourney.tumblr.com/
>Over the last few months, we've noticed a significant shift in how people build. As AI models become more capable at reasoning, we've noticed that developers are increasingly relying on new coding agents such as Claude Code/OpenClaw to handle complex tasks. The typical rigid workflow low code approach quickly hits the limit when it comes to complexity.
Their front page says ‘design agents visually’ so their target market was less skilled devs/non devs.
So not sure why they are giving the reason if closer as cli related when low code and cli are different markets.
I feel like there's a fundamental shift in the user interface that's causing this. People are starting to expect an "agentic interface" - that they are able to give kinda vague inputs and nudge things to work in a way they like, over the traditional experience of having increased clarity at the cost of increased setup (drag and drop, many UI first interfaces, etc).
I was editing a google doc yesterday and found it annoying that i had to find the "link" option from the context menu instead of just saying "turn links into links" and moving on.
This imo impacts everyone, regardless of how developer-ey you are. Perhaps non-devs expect a "friendlier"/more "agentic" interface now? Don't have the right vocabulary to explain.
Claude Code isn't necessarily command-line, the desktop app supports it.
For all intents and purposes they're the exact same interface
I remember Flowise app being well-intended but bad. I evaluated the self-hosted version to be used as a component in an internal tool so non-technical people can tweak their prompt chains without writing code. As far as I remember:
1. it became increasingly slow as I added flows (felt like a O(n^2) ish bottleneck)
2. There were many bugs and bad UX
3. the flow variable system was underbaked and underdocumented
4. feature gaps
I decided I was probably not the target audience for their app and moved on.
Flowise was acquired by workday, so I'd take this with a grain of salt.
However, I agree with the reasoning. I don't see a future for visual workflow builders. They are used to define plumbings that can be defined by a 50 line python script.
A non-technical user does not need to draw this workflow. They can just ask an agent to write that code for them, to debug it, to visualize it. All workflow builders now have an AI chat where you ask the agent to build the flow for you. Why not skip the flow part?
I'm pretty biased though since that's the thesis behind what I am building.
I would counter and say it’s understanding that makes the difference.
Having an AI generate 50 lines of code that you assume will do the job is a little different to creating a flow that you understand and maintain.
AI is really good at making everything seem so simple and easy, until it breaks. But then again, just use another AI to fix it.
So then there is an agent orchestration layer for coordinating multiple agents with multiple personalities, role playing multiple parts in a comedy called software development.
We still don’t know what they are really doing but does that matter? Does knowledge, experience, learning and failing even matter if AI is doing it for us?
"Over the last few months, we've noticed a significant shift in how people build. As AI models become more capable at reasoning, we've noticed that developers are increasingly relying on new coding agents such as Claude Code/OpenClaw to handle complex tasks." is true when your primary users are developers. But no-code workflow is still valuable at scenarios where determinism is required.
I'm building an agentic compliance platform where every procedure needs to follow company policies and operated on the rigid plan, but the procedure itself is different for every customer. Coding agents could in principle generate the necessary workflow for each company, but they need to integrate with millions of other applications in the company, easy to review and modify.
We built our own workflow builder because every other existing solution is too complicated and doesn't meet compliance requirements. The workflow builder itself was coded by Claude, and it's working wonderfully.
So flowise's shutdown is because their business is targeting a specific sector which doesn't need it anymore, not because workflow builder itself is not useful.
Whilst the UI provides visibility and guardrails, it also reduces flexibility. But now with LLM coding agents, it often gets in the way. Working with text/code is easier.
"Visual graph editor for AI workflows" seems like an extremely saturated market (Langflow, n8n). Consolidation seems natural as the agent engineering industry matures.
I’ve never heard of this product before today, but their website made it look like a nice visual tool. It’s too bad they didn’t make it.
With the speed everything is going now, nobody has time to learn nice visual tools. They set their AI agents an objective and leave them to iterate until the objective is reached.
as a person who spent years building flow.ai before flowise.ai, i'd say drag n drop ui was dead on arrival it works for a set of very hand picked cusomers , the rest were in a weird spot between people who can code( and think accordingly ) and don't.
You hit the nail on the head. A couple years ago I started prototyping a similar node based AI workflow builder which worked well but everyone I showed it to was either; confused at how to use it (even for super basic stuff), or liked it but poked holes by asking "can it do x, can it do y" which it couldn't. There is such a small niche of people technical enough to use something like this that wouldn't just opt in for coding it themselves (especially with AI assisted coding nowadays)
I do still use a part of it on one of my projects for building multi-step image processing pipelines for AI property photo editing (ffocal.io for the curious) that are configurable in the admin panel and it works super well and is useful for modifying and testing pipelines. So there are use cases, they're just very narrow
Trying to make an harness and not falling behind with how fast those frontier model evolve is hard. We've built our own harness to make games, but it became obsolete as soon as a new model dropped. Gave up and now just letting user use whatever harness they want on their side.
> The typical rigid workflow low code approach quickly hits the limit when it comes to complexity.
IMO rigid workflows guarantee deterministic and auditable behaviour. It's extremely important when things go wrong.
https://github.com/flowiseai/flowise
It lacked so many features that n8n and Langflow offered, so I'm not sad about it, but it was the first visual agentic workflow builder that I tried and I wish they could make it somehow.
One AI company down, 999 to go.
Hey, look on the bright side. You were able to ride the ai hype and made some money. We all knew these tools wouldn't last.
Disclosure up front: I build LLMGraph (llmgraph.ai), a hosted product in the same category, so I have a horse in this race.
The interesting part of the announcement is the stated reason: "developers are increasingly relying on new coding agents" and "rigid workflow low code approach quickly hits the limit when it comes to complexity." I think that's half right. Coding agents are clearly eating the developer end of this market. But a lot of Flowise usage was never developers; it was teams who wanted to design an LLM pipeline visually, hand it to a non-engineer to tweak prompts, and deploy it without owning infrastructure. That need didn't go away this week, and telling those users to fork and maintain a large TypeScript codebase themselves is not a real answer for them.
For anyone running Flowise in production, the practical decision is fork-and-maintain versus migrating somewhere maintained. Forking is a bigger commitment than it sounds: you own dependency updates, security patches, and model API churn indefinitely, and the contributor community that used to absorb that work is dispersing. Worth being honest with yourself about whether your team will actually do that maintenance before the first CVE forces the question.
I had built https://codeflow.co long ago - a workflow style integration platform (pre-AI). I could see less interest while showing the product to users in recent years as AI was catching up.
The sales demo that excited users - hey you can drag and drop and build stuff - which was pretty exciting few years ago - was seen as a burden by user (especially if they had to pay/license it) - they started asking why can't AI do it for me?
However n8n and other platforms embraced AI and AI automation was a thing for a while until the coding agents caught up. Now I believe drag and drop builders are not a buzz anymore where Claude has become a verb.
Being a visual person I do see value of debugging code "flowing" visually but not many are/were in the same boat. Since then I have pivoted to https://nexaflow.com - which is more like just tune the prompt and get your AI going instead of wrestling with the flow yourself - but I do feel a gap somewhere between the two spectrums - enterprises who would need high level of customization but wont believe in vibe code may be - but that could be a very tiny niche..
I've been pondering this recently. There have been loads of trivial automation targets throughout the economy for years but they haven't really been fixed, despite being a small Python script (things like converting one csv file to another). Why do we suppose LLMs are suddenly going to fix them? I guess the overhead is possibly lower now, but I suspect there are other barriers to automation that most techies can't comprehend.
[dead]
[flagged]
[dead]
Rest well...