We spent billions making software easier for humans to use. Agents don’t need any of it, and the interface is now the bottleneck.
I felt this the hard way last month. I was building an agentic call flow on Amazon Connect. Roughly sixty tickets, backend and linking layers generated as CDK, the whole thing moving through an agentic workflow. In about forty six hours I closed out phases one, two, three, four and half of five. By myself. Then the work hit the part where I had to open the Connect flow designer and start dragging boxes around, and my throughput fell off a cliff.
Same engineer. Same project. Same day. The only thing that changed was code versus canvas.
They had twenty years to know better
Drag-and-drop flow tools are not new. Some of the first were Eclipse plugins, more than twenty years ago. Audium, which became Cisco’s Call Studio. Avaya Dialog Designer. Genesys Composer. Same canvas, same boxes, same arrows. The problems we hit then are the problems we hit now.
The cloud platforms are the recent part. Amazon Connect went public in 2017. Genesys Cloud landed in roughly the same window. So these are not twenty year old tools. They are tools built less than a decade ago, by teams who had two full decades of prior art telling them how this canvas behaves at scale. They rebuilt it anyway.
What changed is not the tools. What changed is that everything around them got fast, and the canvas did not.
The canvas was always a bad place to author
If you write code, you write a switch statement and move on. Five cases, five lines, read top to bottom in three seconds. In the GUI you add a branch, name the condition, add a branch, name the condition, five times over. Then you drag five arrows to five destinations and arrange them so they do not cross. Same logic. One is read in seconds. The other is assembled in minutes and maintained as a diagram forever.
Then there are the error paths. When you prototype, you do not always know where a branch should go yet. In code you stub it. You leave a TODO and the compiler does not care. The canvas will not let you. Every branch has to terminate at a real block before the flow is valid, so you point a dozen branches at a disconnect just to make the tool happy. The canvas conflates valid with complete, which is why a half-built prototype looks like finished spaghetti.
That leads to a trap worth showing rather than describing.
Software engineering says do not repeat yourself. There should be one disconnect on the entire flow and everything links to it. Do that, and the canvas becomes an unreadable starburst because every branch is now an edge converging on one node.
So you scatter a dozen disconnect blocks instead. The local arrows stay short and legible, and now you have copy-pasted a terminal a dozen times. The readable picture is built on duplicated logic.
Clean logic gives you an unreadable diagram. A readable diagram forces dirty logic. You cannot have both. In code these are not even in tension. One exit, every path returns to it, nothing crosses anything because there is no canvas to cross on. The duplication and the readability problem are both artifacts of forcing logic onto a flat surface. There has never been a tool that lays this out well, and there will not be one, because minimizing edge crossings in a layered graph is genuinely hard.
Someone always says you just do not know the tool well enough. Grant it. Mastery helps. But mastery of what? Not the domain. I already know IVR. The thing you are mastering is where this vendor hid this capability in this release of this console, on the configuration tab or the settings tab, two dialogs deep. That knowledge is worth nothing the moment they ship a redesign. Code knowledge compounds. A switch statement I understood twenty years ago is a switch statement today. The rebuttal proves the point.
The root cause is one decision
These tools do have APIs. You can export the flow JSON, parameterize it, push it back. That is not API-first. That is forging the GUI’s save file and hoping the GUI accepts the forgery. The canvas writes that file and the canvas reads it, and it was designed for exactly one producer and one consumer. There is no way to sit down and author a flow, with all the hooks, from code.
API-first would have meant the construction primitives came first and the canvas was one client on top. Build a flow, attach a Lambda, wire an error branch, set an attribute, all as first-class operations with a stable contract. Then the drag-and-drop console is just a renderer over those primitives. Get that ordering right and diff, merge, migrate, test, reuse and review all fall out for free. You do not solve them one at a time. They are side effects of the source of truth being something code can author.
They cannot retrofit this now. The flow JSON already carries twenty years of GUI-shaped assumptions. Layout coordinates, internal node IDs, dialog cruft. A clean API would have to honor all of it or break every existing flow. We have seen this movie. Microsoft got beaten up over lock-in, opened the Word format, and OOXML is the result. Open in name, and still something almost nobody can implement well, because it encodes decades of one program’s internal assumptions. Opening a save file gives you OOXML. It does not give you an API.
We already had the better version
The vendor lock-in is real. I cannot take what I built in Connect to Genesys, and Genesys exports to nothing useful anyway. But lock-in is a symptom, not the disease, and we should remember that the industry once solved the underlying problem.
VoiceXML standardized the runtime. The voice browser was the contract. Nuance and the other platforms competed on how you authored, then everyone emitted VXML, and any compliant browser could run it. The portable artifact was the dialog the caller actually traversed. The cloud platforms did not just lose that. They collapsed the runtime and the authoring layer into one bound thing and locked it. There is no runtime contract underneath Connect or Genesys for a third party to target, and no portable artifact on top. That is arguably worse than 1999, because in 1999 the layer that mattered to the caller was at least standardized.
This is not the natural state of the world. It is a regression.
Why it matters now
The drag-and-drop console was a fine answer to a real question. How does a non-engineer ship a flow without hiring an engineer. That person builds one flow occasionally and the canvas serves them well. The mistake was answering only that question and abandoning the people who build flows for a living.
That tradeoff was tolerable when all of software was slow. It is not tolerable now. The moment most of the build is agentic, the one stage that is not code becomes the bottleneck by definition. It cannot be reviewed in a diff. It cannot run in CI. It cannot be handed to an agent. And here is the part people skip past. An LLM is a pattern engine trained on what humans wrote down, which is text and code. It is fluent in markdown, JSON and source files because those are what the corpus is made of. It has never meaningfully seen a canvas, because a canvas is not text. The save file is illegible to the very thing doing the other eighty percent of the work.
Yes, a multimodal model could squint at a screenshot of the flow. The fact that we are debating whether an AI can interpret a picture of logic, instead of just reading the logic, is the whole problem in one sentence.
Follow the invoice
There is an economic version of this, and it is the part a buyer feels before an engineer does.
Take a flow with twenty widgets on it. Size the work however you like. The logic in it is trivial. What costs money is the ceremony. The clicking, the hunting through submenus, the dragging of arrows, the arranging of boxes so they do not cross. You are not paying for the decisions. You are paying for the assembly.
In code, talent compresses that cost. A strong engineer writes the branch in seconds and an agent writes it for almost nothing, so skill and automation both pull the price down. On the canvas that lever disappears. The expert and the junior perform the same steps in the same order and the work takes the same time. It cannot be compressed by skill, and it cannot be handed to code. So it commoditizes, and the only axis left to compete on is wage.
That is the artificial economy. Put that flow out to bid and the work flows to the lowest-cost vendor, not because the buyer is foolish and not because that vendor is doing anything wrong. They are answering a market rationally. The point is that the tool created the market. It stripped the work of everything that would justify paying for talent and left behind a pile of identical labor priced by the hour.
When all of software moved at human speed, this was invisible. Every line item was human hours and you could not tell which hours were ceremony. The agentic shift removes the cover. The code work deflates toward zero, and the canvas is the one line on the invoice that refuses to fall, because it is the one stage neither skill nor automation can touch. The bottleneck is not just a delay. It is the last cost center that will not deflate, sitting in plain view.
So pick the right primitive for each layer. Intent and specification in markdown, where a human and a model both think clearly. The graph itself in structured text with a real schema, because a flow is branches and shared exits and loops, and markdown will fight that the way it fights a complex document. All of it diffable. All of it legible to both the person and the agent. None of it trapped inside a renderer’s memory of a screen.
That is the only authoring layer that survives. A canvas can never be it.
We spent billions making software easier for humans to use. Agents don’t need any of it, and the interface is now the bottleneck.