Six months ago, we deleted our visual workflow builder.
I don’t mean we hid it behind a feature flag or stopped talking about it. We removed it from the product, ripped out the code paths, and stopped designing around it. It wasn’t a rage decision. It was the end of a slow, unmistakable realization: the builder was training us to solve the wrong problem.
When we first shipped it, it felt like progress. Engineers could point to a canvas and say, “This is what happens.” Boxes, arrows, a clean sequence from input to output. It made the system easy to grasp, especially for people seeing it for the first time. But easy to grasp isn’t the same as correct.
Not all “agents” are the same
At some point we had to admit we were mixing up different categories of “agentic” products. From a distance, it can look like everything is an “agent” now. But under the hood, it’s really a few distinct paradigms wearing the same label.
The first is the classic visual workflow builder. But it’s not really an agent. It’s a workflow: a structured, predefined sequence where the user specifies the path up front - usually with drag-and-drop blocks. It’s great when the operation is repeatable and the world stays stable. But it doesn’t reason. It doesn’t adapt. It mostly just advances.
The second is what I’d call the framework-first approach - the ecosystems where you wire up tool calls, loops, and multi-step behaviors with prompts and orchestration code. Those tools made “agent development” accessible. But they also push the hard problems into the least reliable place: the model’s behavior. The more you rely on prompt compliance for governance, the more your security and policy guarantees become aspirations instead of structure.
The third is the power-tool category: things like coding agents and lightweight task runners. They can be shockingly capable in a constrained environment. But they usually don’t give you the things organizations need when the work matters: centralized policy enforcement, reproducibility, consistent audit logs, and a way to explain why it made the decisions it did.
We realized what we were building is closer to a fourth category: an enterprise-aware agent system. The experience should feel as immediate as the best power-tools - type a goal, give it tools, watch it work - but with the operational guarantees that make it deployable in the real world: enforceable boundaries, evidence and lineage, and auditability.
The First Shift: From Steps to Outcomes
Back to our visual builder. The first cracks didn’t show up in the demo environment. They showed up in the unglamorous places: the runs where the data didn’t match the happy path, where a tool returned something plausible but incomplete, where a downstream system changed a response shape without telling anyone. The builder did what it was built to do: it moved forward. It advanced to the next box.
And that’s exactly when we started losing the plot.
Because the system we were trying to build wasn’t supposed to “advance.” It was supposed to reach a goal reliably, even when the path wasn’t the one we expected.
That was the first shift: we stopped thinking in steps and started thinking in outcomes. In a builder, the path is the artifact. In an agentic system, the path is disposable, a means to an end.
Once you see that difference, you can’t unsee it.
We tried to reconcile the two worlds for a while. We added more structure. More branches. Retries. Validation blocks. Error handlers. We made the canvas smarter the way everyone makes canvases smarter: more boxes. The diagrams got impressive—dense, “enterprise,” serious.
They also got fragile.
Every new block was a commitment to predict the future: which failure modes matter, which recoveries are safe, which validations are sufficient, which conditions are worth branching on. And as soon as production taught us a new lesson, we encoded it as another node. That created a familiar pattern: the canvas wasn’t representing reality; it was chasing it.
Here’s the distinction we couldn’t escape: workflow graphs are execution plans. You pre-author a path. Agentic systems are control policies—they observe, decide, act, and verify against the goal. Adding boxes just hard-codes yesterday’s lessons; it doesn’t buy you adaptation.
The Second Shift: From Calls to Actors
The second shift made the decision inevitable: we stopped treating the model like a single call and started treating it like an actor in a system.
The best runs shared a simple shape:
give the model a goal
give it tools and skills
constrain it with guardrails
let it cook
The surprise was how often the right path differed. The model changed tool order based on what it found, recovered from failures, asked clarifying questions when needed, and validated intermediates because the goal demanded it.
A concrete example made this obvious.
Take onboarding. Not “fill in a form” onboarding, real onboarding where inputs arrive as emails, PDFs, spreadsheets, and half-structured notes. One run is clean; the next has mismatched identifiers, missing evidence, or a policy threshold that changes what checks are required. The system has to ask a question, route to a reviewer, pull a source of truth, re-check assumptions, and then prove the outcome is supported.
In a canvas world, that’s not one workflow. It becomes a library of workflows: branches for every policy fork, variants for every product line, region, customer type, evidence format, and exception path. Over time it turns into hundreds of slight variations, most of them identical except for one step, one validation, one integration edge case.
An agentic system treats those variations differently. The goal is stable. The constraints are explicit. The tools are bounded. The agent decides the path at runtime based on what it sees, and it can explain why it took the route it did.
That’s what “agentic” meant in practice. It is not a buzzword, but a behavior: understanding the environment, adapting to change and error, and staying oriented to the goal.
And that’s where the canvas became more than inconvenient. It became actively counterproductive.
A visual workflow builder rewards certainty. It rewards pre-definition. It encourages you to treat the journey as sacred: draw it carefully, lock it in, and the system will follow it faithfully.
But effective automation isn’t faithfulness to a plan. It’s faithfulness to an outcome.
The builder was making the journey more important than the destination.
We felt this most sharply in debugging. With a canvas, a run “fails” when a node errors. But many of the worst failures in automation don’t throw errors, they produce outputs that look reasonable. A workflow graph can happily deliver something that passes through every box and still be wrong, because the world changed and the flow didn’t notice. The diagram stays clean. The result quietly degrades.
To solve that, you don’t add more arrows. You add a control plane: explicit checks, verifiable tool boundaries, consistency tests, and guardrails that stop the system from “hallucinating to completion.” You make the system able to say: I can’t support this conclusion with evidence. Or: I need clarification. Or: This output fails validation; I’m taking a different approach.
Those are not canvas nodes. They’re governance primitives.
The Third Shift: Operations Change Everything
The third shift was operational: supporting deployments over time means living in continuous change. Data formats drift. Vendors update. Policies and thresholds move. Exceptions emerge. Tools develop new failure modes. Teams change how approvals and escalations work.
Once you account for that, the math is brutal: every diagram is an artifact you now have to keep in sync with a moving world. It starts as “a few workflows,” becomes a library, then a forest of near-duplicates.
Onboarding makes the cost obvious. If step X exists in 500 variants, a small upstream change isn’t one fix, it’s 500 edits, 500 tests, and 500 chances to miss a corner.
In an agentic system, the unit of change is smaller and more powerful. You improve a tool. You refine a prompt. You add memory. You tighten a guardrail. One change, applied everywhere. The system adapts at runtime instead of demanding that engineers pre-adapt it in diagrams.
The Decision to Delete
Once we accepted that, keeping a workflow builder around wasn’t harmless. It was pulling the product toward a worldview we no longer believed: that the primary job of automation is to predefine the path.
So we deleted it.
Not as a rejection of visual builders in general, just an acknowledgment of what we were actually building. In an agentic-native system, the interface isn’t a canvas. The interface is principles, intent, constraints, tools, and a trace of decisions that you can inspect, audit, and replay.
The goal stays fixed. The route is allowed to change because the world does.
And after we committed to that, a workflow builder wasn’t a feature anymore. It was a contradiction.
