TL;DR: Use a single prompt for an agent with one job and no real branching. Use a conversation flow the moment the call has state, an outcome the business cares about, or anything you would be embarrassed to get wrong. Then keep the flow small by pulling repeated stretches (verification, booking, human handoff) into reusable components, and turn on flex mode only where real callers refuse to answer in the order you designed. That combination is what has kept my production agents at Tested Media and Fortell AI from collapsing in week two.
Every voice agent I have shipped started as a single prompt, because a single prompt demos beautifully. You write a paragraph describing a receptionist, you call the number, and it sounds uncannily good. Then you put it in front of a hundred real callers and the same agent forgets to collect a phone number, books a Tuesday that does not exist, and cheerfully invents a service the business does not offer.
That gap between the demo and week two is almost entirely a structure problem, not a model problem. Here is how I decide what structure an agent gets, and how I use Retell's flow primitives to keep that structure from turning into a wall of spaghetti.
Single prompt vs conversation flow: the actual decision
Retell lets you build an agent as one prompt, or as a conversation flow made of nodes with explicit transitions between them. The marketing framing is "simple versus advanced." That is not how I choose.
I choose based on one question: does this call have state that the business depends on?
A single prompt is fine when the agent's whole job is to talk. FAQ answering, hours and directions, qualifying chatter before a human picks up, an outbound call whose only real outcome is "did they say yes." There is nothing to track across turns beyond the conversation itself, so letting the model manage the whole thing is cheap and flexible.
A conversation flow is the right call the moment there is a sequence that must complete: collect a name, then a phone number, then a service, then check availability, then confirm a specific slot. That is state. If the caller hangs up halfway, the business needs to know exactly how far you got. If the model skips step three, the booking is garbage. A flow makes each of those steps a place the agent can actually be, which means you can see where calls die instead of guessing.
The honest version of the tradeoff:
- Single prompt gives you flexibility and gives up guarantees. It will handle weird conversations gracefully and occasionally skip something important.
- Conversation flow gives you guarantees and costs you design time. It will collect what you told it to collect, and it will feel rigid anywhere you designed the path badly.
Most real businesses need guarantees, so most of my production agents are flows. I covered the surrounding stack in how I build production voice agents on Retell, and the platform comparison in Retell vs Vapi vs Bland. This article is about what happens inside the agent itself.
Nodes are jobs, not sentences
The first mistake I made building flows was making nodes too small. One node per line of dialogue produces a diagram that looks impressive and is impossible to change. The second mistake is the opposite: three enormous nodes each carrying a paragraph of instructions, which is a single prompt wearing a flowchart costume.
The rule I settled on is that a node is one job to be done, sized so a human could name it in three words. Greet and identify intent. Qualify the caller. Check availability. Confirm and close. Escalate to a human.
That sizing matters because each node's prompt should be short enough to read in one breath and testable on its own. When a node does one thing, a bad call transcript points at exactly one node, and the fix is a two-line edit. When a node does four things, every fix is a rewrite and every rewrite risks the three behaviors you were not trying to change.
Write the exit condition before the prompt
For every node I write the transition logic first: what has to be true for this node to be finished, and where does the call go in each case. If I cannot state the exit condition in a sentence, the node is doing too much. This is the single highest-leverage habit I have in flow design, because most agents that "loop weirdly" or "get stuck asking the same question" are not failing at language, they are failing at an exit condition nobody wrote down.
Components: stop building the same booking flow five times
Once you have built a few agents, you notice the same stretches of conversation appearing in all of them. Caller identification. Collecting and reading back a phone number. Checking a calendar and offering slots. Confirming an appointment. Handing off to a human. Taking a message when nobody is available.
Components are how you stop copy-pasting those. A component is a reusable group of nodes you build once and drop into any flow, and the value is not the typing you save. The value is that a bug gets fixed in one place.
At Tested Media I built agents for CallSetter AI with components exactly this way, and the difference shows up in maintenance rather than in the first build. When you discover that your phone-number capture mishears sevens, you want to fix that once, not in nine flows across four clients. When a client's booking policy changes, you want one component to update.
What I pull into a component:
- Anything with a compliance or correctness rule attached. Verification, consent language, disclaimers. These are the parts you least want drifting between agents.
- Anything involving an external system. Calendar checks, CRM writes, message-taking. The conversational half lives in the component, the actual work lives in n8n behind a webhook.
- The human handoff. Every agent needs an escape hatch, and it should behave identically everywhere. The caller who asks for a person should get the same clean, fast experience whether they are calling a clinic or a garage.
What I deliberately do not componentize: the greeting and the business-specific qualifying questions. Those are where the agent should sound like this particular business, and forcing them into a shared block makes every client sound like the same robot.
Flex mode: for callers who will not follow your diagram
A strict flow assumes the caller answers the question you just asked. Real callers do not. They open with "hi, I need to move my Thursday appointment and also do you take walk-ins," which answers a question three nodes ahead and one you never planned to ask.
Flex mode is the release valve for that. It lets the agent handle the conversation with more freedom within a stage instead of marching strictly along the edges you drew, so a caller who volunteers information early or doubles back does not fight the structure. The exact naming and controls shift as the platform evolves, but the concept is stable and it is the thing that makes flows survive contact with real humans.
My rule is to be deliberate about where it goes:
Turn flexibility up in gathering and discussion stages. Intent detection, qualification, answering questions about services, anything where the caller legitimately controls the order. Rigidity here is what makes an agent feel like a phone tree, which is the exact experience the business is paying to escape.
Turn flexibility down anywhere an outcome is being committed. Confirming a specific appointment slot, reading back contact details, closing the call. When the agent is about to write to a calendar or a CRM, I want the boring deterministic path. Creativity at the moment of commitment is how you get a confidently confirmed appointment that exists nowhere.
That split maps to a principle I use everywhere: let the model be flexible about how the conversation goes, and rigid about what must be true before an action fires.
The parts that stop calls from going sideways
Structure buys you a lot, but three habits do the rest of the work.
A global escape hatch. "Let me talk to a human" has to work from anywhere in the flow, at any point. No exceptions, no qualifying questions first. In regulated verticals this is not a nicety. When I build for clinics, the boundary between what the agent owns and what it must never touch is the most important design decision in the project, and the handoff is how that boundary gets enforced in practice.
A stated fallback in every node. What does the agent say when it does not understand, twice in a row? If you have not written that, the model will improvise, and improvisation at the edges of a call is where agents invent policies.
Testing the structure, not just the script. A flow gives you something a single prompt does not: named places where calls end. I keep a fixed set of scenarios that run against every change, including the interrupter, the caller who answers a question with a question, the wrong number, and the silent line. At Fortell AI I built a pipeline to create and test agents in minutes using Claude Code plus browser automation precisely because manual testing is where voice projects quietly die.
How I would start today
If you are building your first serious agent, the order that works is small and unglamorous:
- Write the happy path as a phone call on paper and read it aloud.
- Build it as a flow with four or five nodes, each one job, each with a written exit condition.
- Wire exactly one real action end to end, usually booking, before adding a second.
- Pull the pieces you know you will reuse into components once you have them working, not before.
- Loosen the gathering stages with flex mode after listening to real transcripts, and keep the committing stages tight.
- Read ten real calls after every deploy.
The structure is not the impressive part of a voice agent. Nobody on a call notices good node boundaries. They notice that the agent got their number right, booked the slot that actually exists, and put them through to a person the second they asked. That is what structure buys, and it is the difference between an agent that demos well and one a business can leave answering the phone.
I build production voice and chat agents on Retell, wired into n8n, GoHighLevel and Twilio, for teams that need the phone answered properly. If that is you, my inbox is open: more about my background here, or book a call.