Prompt-based or node-based voice agent: how to choose.

Who decides what happens next?

In a prompt-based agent, one set of instructions tells the model what to ask and do next. It can still call tools that your server checks. It gets fragile when business rules live only in prose the model has to remember every turn.

In a node-based agent, the call moves through a graph. Each node is one step with its own instructions, and each way out has a condition. It’s a state machine: an event moves the state, and a guard decides whether a transition is allowed.

Which one fits my call?

Situation	Start with	Why
Open questions about a product	One prompt, plus validated tools	The caller may take a useful route you didn’t plan
A short intake of a few facts	One prompt, with variables in and analysis out	You may not need a graph yet
Booking or changing something in another system	A workflow around the action	Availability, confirmation and retries need an owner
Several phases, each with its own rules	Nodes	Each step gets clear entry and exit conditions
Instructions that won’t fit in one prompt	Nodes	Only the current node’s instructions are in play
You need to know which step each call reached	Nodes	The outcome records the nodes visited

There’s no prompt length or node count at which everyone should switch. Add structure when you can name the failure it prevents.

How do node-based agents run on Frequency?

A flow is one field on the agent, on every plan, and it bills like any other call, from ₹1 a minute. The call opens with the start node’s greeting. The model follows the current node’s prompt, plus the global node’s if the node includes it. Each transition is a function the model calls when its condition is met, so no extra routing call is added. History carries across nodes. An end node gets one reply, then hangs up, and extraction runs in the background as the call leaves a node.

A graph has 2 to 20 nodes and up to 40 transitions, with up to 12,000 characters per node prompt. Agent Studio can draft one from a one-line brief or from recordings of real calls. Each save is a fixed revision; a running campaign keeps its own. After the call, data.call.flow in the call.processed webhook gives the final_node, nodes_visited, extracted variables and how the flow ended.

What does a real flow look like?

Take a made-up appointment assistant:

Collect preference → Look up availability → Offer a slot
       ↑                                      ↓
       └──────── Caller correction ──── Confirm selection
                                              ↓
                                      Create appointment
                                              ↓
                                        Report result

Make cancel and hand-off reachable from every step. Today hand-off means “the team will call you back”, because transfer to a person isn’t available yet. A correction after the availability lookup throws out the old result. A correction after booking needs a change or cancel path, so nobody is booked twice.

For each node, note what’s known, what’s missing, which tools it offers (up to 10 per node) and which conditions leave it. Put persona, language and reply length in the global node once.

Where do the rules belong?

In your code. Before create_appointment runs, your server should check that the slot came from a current availability result, and that the caller confirmed that exact slot. A confirmed: true from the model isn’t enough.

Store an idempotency key, and if the booking system times out, check its status before you retry. “Never book twice” in a prompt can’t dedupe a network retry. Nodes make these checks easier to find, but drawing boxes doesn’t enforce them.

How do I write transitions the model can choose between?

Give each node one job, and name the transition in its prompt: “If they confirm, call confirmed_identity.” Tell the model to move on without speaking, so the next node decides what’s said. Keep sibling conditions mutually exclusive, or the model has to guess.

Don’t make a node a rigid script. Callers answer two questions at once or interrupt to fix a date. Take everything they said and ask only for what’s missing.

How do I test it?

Test the repairs, as well as the happy path. Our workshop and evaluation cases hold 12 scenarios we wrote, from unclear consent to stale tool results and hand-off. They’re a starter set, not measured results.

Run them against both designs, and record task completion, wrong actions, repeated questions, recovery turns and latency. If the real problem is contradictory instructions, start with the prompt repair guide. To place test calls from code, see the Python phone-call guide.