Appearance
Rigid vs LLM: where the boundary sits
A voice-agent prompt is doing two unrelated jobs at once. One is language: understanding a messy utterance, phrasing a natural reply. The other is control flow: ordering, guards, tool gating, output templates. Prose is good at the first and structurally bad at the second, and most large prompts are large because they're doing the second in prose.
This page is the platform-level argument. It was derived from the EAS prompt rework, and the EAS-specific decision trees that produced it are at How I built the EAS prompt → call flow. The conclusion isn't EAS-specific and isn't CRM-specific.
The measurement
Classify every decision and action node in a call's decision tree as one of:
- RIGID — deterministic. Fixed ordering, guard conditions, count branches, tool gating, output templates with slots. A state machine does this for free.
- LLM — perception or generation that needs the model. Free-speech understanding, slot extraction, naturalistic phrasing, ambiguous routing.
- HYBRID — the decision is rigid (a table lookup), the trigger is LLM (recognizing which row applies).
Done against the EAS prompt, the counts came out roughly:
| Class | Count | Where it lives |
|---|---|---|
| RIGID | ~20 | The entire booking spine, all guards, the gate, every output template |
| LLM | ~9 | Intent classification, identity-dependence judgments, slot extraction, response & objection classification |
| HYBRID | ~1 | Preference fallback |
Roughly two-thirds of the call is deterministic control flow. And it's the two-thirds the prompt is largest and most repetitive about: "never call availability until X," "do not collect Y before Z," "one save attempt," "one gate question," the verbatim confirmation scripts.
That's the finding: the prompt is a state machine implemented in English. Which is why edits ripple and rules silently contradict. Prose has no compiler to catch two rules disagreeing.
Where the LLM work actually is
The LLM nodes cluster in two places, and they're the genuinely irreducible ones:
- The opening — routing a messy utterance to the right branch. This is the hardest, least deterministic job in the call, and empirically where the costly misroutes happen (a bookable diagnostic sent to callback; a "talk to someone" that was really a booking).
- The turn boundary — understanding what the caller just said, phrasing the next line.
Everything between those is ordering and templates.
What this argues against
- Not squads. The control flow is one connected pipeline. Handing it between agents adds seams without removing the prose-as-state-machine problem.
- Not a full platform state-machine rewrite, at least not first. The LLM opening node is real: callers jump intents, and a rigid node graph at the call level gets brittle exactly where the failures already are.
What it argues for
A deterministic-play model, "LLM at the boundary, machine in the core":
- A harness owns the rigid spine. Ordering, guards, tool gating, and template selection move out of prose into structure the model can't violate. A tool can't fire early because the state won't allow it, not because a sentence said so. This is also where a pre-call prefetch lands cleanly: availability becomes state the harness holds, not a tool the model has to remember to call.
- The prompt shrinks to the LLM nodes. It stops being tens of kilobytes of order-enforcement and becomes focused instructions for the handful of judgments only the model can make. Smaller surface, fewer contradictions.
- Templates stay templates. Offer/confirmation/cancellation scripts are rigid leaves. They belong in the harness as parameterized strings, with the model filling slots rather than regenerating the line.
The honest caveats
- A harness this opinionated is real engineering in the Blueprint platform (and, post-migration, ElevenLabs), not a prompt edit.
- The LLM opening node still has to be excellent, or good routing into a rigid core just fails faster.
So the value of the measurement is that it lets you decide per-node which rigid nodes are worth lifting into structure first. Guards and tool-gating give the highest ripple-reduction per unit of work; the rest can stay templated-in-prose until they earn the move.
Related
- How I built the EAS prompt — the rework this came out of
- In-Call Sequence — the runtime loop the prompt executes inside
- Tool Calls — how tool gating actually works today