A graph instead of a prompt: how the studio builds a voice agent from text

A voice agent is usually assembled from one long prompt. In a demo that works: the model sounds confident and stays on script. On the hundredth call it does not. Someone interrupts halfway through, someone answers "well, maybe", someone asks about delivery in the middle of booking an appointment. And a prompt cannot be opened to see where exactly the conversation went wrong: it has no structure, only text.

HANC Studio does it differently. From a description in ordinary language it assembles the conversation as a graph — and before handing it over, it proves the graph is correct.

A brief, not a prompt

The input is not an instruction for the model but a brief in your own words: who is calling, what has to happen, what must not, and how the conversation ends. Attach a document, a screenshot of an interface or a link to your website — the studio reads them and extracts the requirements: the role, the tone, the mandatory questions, where the hard cases go, which data to collect.

From there the description lives on not as text but as a specification the build is later checked against.

A graph, not a prompt

The conversation is assembled from nodes, and each does exactly one thing:

• start — where the call enters;
• say — a line the agent speaks;
• gather_input — a question whose answer is stored in a variable;
• condition — a branch on the value of a variable;
• update_state — writing or changing a variable mid-conversation;
• tool — an action: an API call, a knowledge base lookup, an SMS, an email, a transfer to a number;
• integration — a step into an external system: calendar, CRM, MCP server;
• subagent — a part of the conversation handed to a dedicated helper with its own task;
• end_call — the ending.

This can be read. It can be shown to a colleague. You can point at one node and say: here is where the agent says too much.

The model does not pick the route

The central rule: an edge of the graph is never decided by the model. An edge that says "let the AI choose" does not pass the build at all.

Intent is resolved by a silent sub-agent — it speaks no words and returns one strict value from a fixed list. The route is then chosen by ordinary condition edges on that value, plus one unconditional fallback for when nothing matched.

The difference shows up not in the demo but in the logs: the same answer from a caller takes the same branch every time.

The build has to prove itself correct

Before the agent appears in your account the graph goes through checks. Not advice — blocking checks:

• exactly one entry, and the call starts there;
• no unreachable node;
• no dead end: every node has a path to the end of the call;
• no endless loops — every strongly connected component is analysed, so a hidden cycle is caught as reliably as an obvious one;
• every branch has a fallback path;
• a branch already shadowed by an unconditional edge is dropped as dead rather than kept as decoration;
• every sub-agent has its own prompt and its own list of results instead of the parent’s settings;
• a call transfer has a number, and the number is validated against E.164.

If the requirements cannot be met, the studio says "build failed" and keeps the draft for repair. A stub is never passed off as a finished result — that is a rule of its own, not an accident.

Verified with a live call

The studio then calls the agent it built and works through the scenario like an ordinary caller, against a checklist: every item gets a PASS or a FAIL. Simulations come on top — a sweep of every branch for coverage, and deliberately broken answers for robustness.

What is left at the end is a report: what is connected, how it ends, where the loops are, which helpers take part. Publish or repair is your call, but you make it looking at facts.

Edits by meaning

A finished agent is edited in words, not identifiers: "change the first greeting", "add the Tesla branch", "drop the repetition at the end". The studio finds the node itself.

The edit lands as one atomic operation — the rest of the graph is not rebuilt and loses no manual changes. If you edited node texts directly in HANC, the studio pulls them in before changing anything. Any earlier version is restored on top of the current workflow, and the result is visible at once.

Knowledge, actions and data

Price lists, FAQs and documents connect as a source: the agent answers from them and names where the answer came from instead of inventing one.

Actions are nodes, not intentions: book in the calendar, create a deal in the CRM, send an SMS or an email, call your API, hand the caller to a human. Before the call ends a dedicated node writes everything collected — name, phone, what it was about, the outcome — into your database.

Publishing

The agent is created in your HANC account: a phone number, a widget on your site, WhatsApp. It lives there from then on, and the studio stays the place where it is built and changed.

Why any of this

A prompt can only be believed. A graph can be read, verified and repaired — and when it does break, you can see which node it broke in.