Coze's Sunset: Workflows Weren't a Mistake, Just a Stopgap

Coze is actually going offline.

On November 2nd, a person working on Coze at ByteDance posted an update saying his profile still lists 'Coze Workflow Engine Developer', and that by next year, if he still has it, nobody will know what Coze is. He followed with three points, sharing what outsiders can’t see. The second was most piercing: the drag-and-drop nodes he’d worked so hard on were essentially paying for the model’s lack of intelligence, tracing back to a transitional mode from low-code, an intermediate product.

After reading, I didn't have time for sentiment; I started to have doubts. In the past two years of building AI software, you can't avoid a choice: draw a workflow, or hand the decisions to the model. Now even the engine makers call their own work an 'intermediate product'. Did we who chose workflows take the wrong side from the start?

When the engine makers say it themselves, it carries a different weight, so it's no wonder I feel unsettled after reading. Outsiders analyze why workflows are falling away, mostly reasoning backward from architecture; he looked from the inside out, seeing what he had been filling in those years.

What he was filling in was planning. When models couldn't yet break tasks into steps and decide the next move, someone had to draw the order, conditions, retries, and loop limits. In a DAG, the edges are what matter; nodes can be drawn in any product. Whether it's DeepSeek's recent super-agent or the various agents popular this year, the direction is clear: hand over more autonomous decisions. Once models learn to plan, the scheduling control is handed over. For sufficiently capable models, that canvas probably feels too restrictive.

Following this logic, the answer seems already written: don't choose workflows.

But reasoning alone isn't enough; I have a more personal example. Recently I switched to Claude Opus 5.5, and a set of upper-level skills I'd spent effort optimizing stopped working well. These are the skills that manage other skills, orchestrating lower-level capabilities. They ran smoothly on the old model. I asked Claude what was going on, and it told me these skills were holding it back; it had better solutions than skills.

This is the same thing as the Coze story, just at a different scale. When models lack capability, we bolt on many tools around them; when capability rises, those bolted-on tools become constraints. At this point, the phrase 'did we choose the wrong side' almost seems confirmed.

But when I took the question back and thought it over, I found it was asked in the wrong place. In the question 'is choosing workflow right' hides an unspoken premise: one path is superior, and the new is always better than the old. What self-planning agents offer and what workflows guarantee aren't even on the same scale.

In scenarios requiring more reliability, accuracy, and reproducibility, workflows may be the optimal solution. These three aren't the same: reliability means not giving up halfway, accuracy means results don't drift, reproducibility means the same input yields the same output every time. For video production right now, workflows are more reliable; agents with a bunch of skills are too random. Storyboards, durations, transitions, framing of every frame; when delivering, if the previous version changed something, this version should change only that. If every run gives new surprises, nobody on site can tolerate that.

I'd rather see it as two domains: one is SOP Agent, the other is Autonomous Agent. Self-planning applies where the path can't be predetermined: coding, debugging, open research, where the next step depends on what the previous step produced; workflows apply where the process already has a standard answer.

The two sides optimize along different axes; I think there's really no basis for comparison. So the question 'did we choose the wrong side' is somewhat unfair: choosing workflow isn't right or wrong; it depends on whether you want the same result every time, or the ability to traverse unseen paths. Once that's decided, the choice becomes easy.

There's another layer easily overlooked: who it's for, and how much it costs to get started. Coze going offline doesn't mean that way of thinking becomes obsolete.

For beginners, it's actually a good way to start. Learning LangChain or workflow Agent right away can be abstract; without a visual map to drag around, nodes, edges, and conditional branches are just concepts stacked on concepts. Coze has a low barrier; drag, drop, configure, and a Workflow Agent runs. For most small businesses, it's enough and cost-effective; the time saved is tangible. The product may be taken away, but the sense of breaking work into steps stays.

That sense of unease isn't entirely from Coze. Models keep improving; what you choose today may become a constraint tomorrow. Whether the bolted-on tools become handcuffs as models get stronger; when choosing tools, it's worth asking: a good tool might be one that spans this curve, doesn't constrain the new model, and still boosts the old one. The Opus 5.5 incident is a reminder: the same skills turned from a help to a hindrance when the model changed. The water level of large models is rising gradually; whether you stand on the bottom, on a reef, or on a mountain, you'll have to choose eventually.