Rendered at 07:47:00 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
fsuts 21 minutes ago [-]
>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.
vaishnavsm 12 minutes ago [-]
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.
ashu1461 6 hours ago [-]
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.
juancn 6 hours ago [-]
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).
ashu1461 5 hours ago [-]
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.
itake 4 hours ago [-]
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.
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.
taoh 4 hours ago [-]
"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.
whycombinetor 5 hours ago [-]
"Visual graph editor for AI workflows" seems like an extremely saturated market (Langflow, n8n). Consolidation seems natural as the agent engineering industry matures.
cebert 5 hours ago [-]
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.
eric_khun 3 hours ago [-]
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.
maxdo 5 hours ago [-]
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.
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.
ProAm 4 hours ago [-]
One AI company down, 999 to go.
system2 3 hours ago [-]
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.
llmgraph 8 hours ago [-]
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.
hgomersall 1 hours ago [-]
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.
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 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.
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.
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).
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.
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.
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/
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.
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.
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.