Why Our Agent Builder Isn't a Flowchart

Nearly every tool for building conversational agents gives you a canvas of nodes and edges. Drag a block, connect it to another block, define what happens on each branch. It is the dominant interface in the category and has been for a decade.

Ours is a conversation. You describe the agent you want and it writes the configuration beside you.

That is a real trade, not a free upgrade, and it is worth setting out both sides.

What the flowchart is genuinely good at

A node graph makes the shape of a conversation visible. You can see every branch at once, point at the path a customer took, and tell at a glance that one route dead-ends without an exit.

It is auditable in a way prose is not. A compliance reviewer can trace the graph. It is diffable. Two people can look at the same canvas and disagree about a specific edge, which is a much better argument than disagreeing about a paragraph.

None of that is nothing. If you need to guarantee that a conversation can never reach a particular state, a graph is the honest way to express it, and we would not pretend otherwise.

What it costs

The problem is that the graph is a model of the conversation, and the model is always wrong in the same direction.

Real conversations do not branch cleanly. A customer answers a question you did not ask yet. They ask two things in one sentence. They change their mind halfway and refer to something from four turns ago with a pronoun. Every one of those is a defect in a node graph and none of them is unusual.

So the graph grows. The clean five-node diagram from the demo becomes forty nodes, most of them handling the ways people fail to behave like the diagram. The thing that was supposed to make the conversation visible now makes it visible the way a wiring diagram makes a building visible: completely, and uselessly.

There is also a quieter cost. Building the graph is a modelling exercise, so you spend your time thinking about the graph rather than about what the agent should say. The interface pulls your attention toward its own abstraction. People end up debugging topology when the actual defect is a sentence.

Why the conversation is the builder

What an agent needs to know is mostly not structural. It is identity, tone, what it may and may not commit to, where its knowledge lives, which systems it may touch, and when to hand over to a person.

Almost all of that is naturally expressed in prose, because it is prose. Turning "if someone is angry about a delayed order, apologise, look up the order, and offer the two things we can actually do" into a subgraph is a translation step that costs effort and loses nuance in both directions.

So the builder takes the description and writes the configuration. The configuration is real and visible; it is not hidden behind the chat. You watch it being written and you can edit it directly.

The reason we think this is the right default is narrower than "AI is better": the person who knows what the agent should do is usually not the person who enjoys building graphs. They run the support team. Describing the agent is the format they already think in, and every translation layer between them and the config is a place their intent degrades.

What we gave up, plainly

Branch visibility. There is no canvas showing every path at once. If your requirement is to prove a conversation cannot reach a state, we do not currently give you the picture a graph gives you, and if that is your constraint you should take it seriously in the evaluation.

Diff legibility. Prose diffs are worse than graph diffs. A changed sentence is harder to review than a changed edge.

Determinism at the seams. A graph guarantees that from node A, input X always goes to node B. We do not offer that guarantee at the language layer, and we would rather say so than imply the flexibility is free.

Where determinism genuinely matters, it belongs in tools rather than in dialogue. A payment either succeeded or it did not, and that lives in an API call with a defined result, not in a branch of a conversation graph.

Pick the other thing if

Your conversations are genuinely a decision tree, and a short one. Some are. An IVR that routes six ways to six departments is a graph, and modelling it as a graph is correct.

You have a regulatory requirement to demonstrate the complete state space of a conversation.

You already have a team fluent in a node canvas who like working that way and are fast in it. Interface preference is a real reason and there is no need to dress it up.

The bet

Underneath, the choice is about where the difficulty should sit.

The graph puts the difficulty at build time. You describe every path in advance, which is hard and thorough, and then it runs. The conversational builder puts it at run time: the agent reasons about what it is being asked, which is easier to set up and requires you to trust something you did not fully enumerate.

Ten years ago the second was clearly the wrong bet, because the reasoning was not good enough and enumerating was the only way to be safe. What changed is not the interface. It is that the run-time reasoning got good enough to be worth the trade.

That is the argument, and it is falsifiable. If the reasoning is not good enough for your case, the graph is still right, and you should use one.