Guillaume Lebedel · · 6 min 
AI Agent Builder Sunset: What IT Teams Must Rebuild
Table of Contents
Flowise, the AI agent builder Workday acquired in August 2025, published its wind-down notice on 29 July 2026, less than twelve months later. Code freeze was immediate, the repository goes to public archive on 10 August, and end of life is 31 August.
About eight weeks before that, OpenAI posted a deprecation notice for Agent Builder, its visual canvas for composing agent workflows. That product shuts down on 30 November 2026, per OpenAI’s deprecations page.
Both were real products with production users. Flowise’s open-source repository has more than 55,000 stars, and its notice does not cite a lack of adoption anywhere. That makes the two shutdowns a useful signal for any team choosing an AI agent builder this quarter: the canvas is the layer of the agent stack most likely to change hands, and it is the worst place to store integrations.
What survives an agent builder sunset, and what does not
When a visual builder closes, the workflow itself is the recoverable part. Node configuration, prompts, branching logic and retry settings are either exportable as JSON or re-expressible in code by the team that wrote them. Flowise is a good case: the source stays on GitHub under Apache 2.0, and the founders explicitly encourage teams to fork it and maintain internal updates.
The parts that do not travel are the ones IT owns.
Every app connection was authorised against the old platform’s OAuth client and redirect URI. A new platform means a new client, a new consent screen, and in most enterprises a new security review per app. The decision that an agent may read compensation data but not write it lives inside the old platform’s permission model, not in a portable file. The log of which agent called which action, the one security signed off on, stays with the vendor that is closing.
None of that is difficult work, but it is slow: a ticket per app and a fresh approval for every scope. A team can port a workflow graph in an afternoon and still wait six weeks for the grants behind it.
Why the agent builder layer keeps churning
Flowise’s founders gave a specific reason for stopping. Developers increasingly rely on coding agents to handle complex tasks, and the rigid low-code workflow approach quickly reaches its limit on complexity. OpenAI retired its own canvas in the same window.
Agree with that reasoning or not, it is not a one-off market event. The pressure that closed both products is still increasing, so the visual layer is likely to keep turning over. Meanwhile the systems those agents write to (Workday, Salesforce, ServiceNow, NetSuite) are among the slowest-moving software in the company. Pinning an integration layer to the fastest-churning part of the stack is the design mistake, and it repeats every time a builder changes hands.
This is the same structural point as why a coordination standard is not an execution guarantee and why the MCP spec deliberately leaves authorization to the deployer. Protocols and canvases describe how a call is shaped, while whether the call is allowed and whether anyone can prove it happened are decided by the layer holding the credential.
Only 12% of IT teams have centralised platform management
OutSystems surveyed 1,900 global IT leaders and published the results on 7 April 2026. Three figures from it matter for a builder sunset:
- 96% of organisations already use AI agents in some capacity
- 94% are concerned that AI sprawl is increasing complexity, technical debt and security risk
- 12% have implemented centralised platform management
For the 88% without a central platform, a builder shutdown becomes one migration per team that wired something up, with no central inventory of what those teams connected. The finance analyst who built an approvals agent on a low-code canvas is not going to file the OAuth re-consent ticket. IT will, once the agent stops working, and usually without documentation of which scopes were granted in the first place.
That asymmetry is where the cost sits. The teams that create connections are rarely the teams that re-establish them, so the work reaches IT as an unplanned interrupt rather than a scheduled migration with a budget line.
Keep integrations below the canvas
StackOne is designed on the assumption that the orchestrator is temporary and the connections are not. The connector, the scope on each individual action, and the audit log sit below whichever canvas, framework or model a customer picks: 450+ pre-built connectors and 28,000+ actions, reachable over MCP, A2A or an SDK. Move a team from one builder to another and the agent identity, the granted scopes and the log history stay exactly where they are. The migration becomes a change of caller.
That does not make a migration free. The graph, the prompts and the evaluation suites all have to be re-expressed in the new tool, and that part is real work. What it removes is the work that depends on other people’s calendars: security review, app owner approval, and re-consent across every system of record.
It also changes what a permission means. When scopes are attached to actions in a layer the agent calls into, rather than configured inside the builder, the boundary survives a platform change. We have written before about why permission scope is the boundary that actually stops an agent rather than a stronger prompt or a review gate. Configure that same boundary inside a builder’s UI and it has to be re-agreed with the data owner the moment the builder is switched off.
Four questions to ask before you pick an agent builder
Worth answering before the contract is signed:
- Where do the OAuth grants live? If they are held by the builder’s client ID, they leave with the builder.
- Can you enumerate, today, every action an agent is permitted to call, and export that list? If the answer is “it’s in the platform,” there is no inventory.
- Is the audit log queryable outside the builder’s own interface, and does it survive the account closing? Compliance evidence that lives in a deprecated SaaS tenant is not evidence.
- If the canvas were replaced tomorrow, which of the above would need re-issuing? Whatever is on that list is the real switching cost, and it is almost never the workflow.
A team that can answer those four is free to pick the best builder available this year and change its mind next year. A team that cannot is buying a workflow tool and a re-authorisation project at the same time, and only the first one is on the invoice.
If you are working through that list for an agent rollout, our integration experts run the same exercise with IT teams most weeks: which grants exist, which scopes are live, and what would need re-issuing on day one of a migration. Book time with one of them and bring your current estate.