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 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.

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..

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/

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.

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.

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.

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.

IMO rigid workflows guarantee deterministic and auditable behaviour. It's extremely important when things go wrong.

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.