Call Flow + Rigid/LLM Split

A decision-tree view of an EAS call as the current prompt intends it, built to answer one question: how much of this is deterministic routing a harness could own, vs genuine language judgment only the model can do?

Every node is classed:

• 🟥 LLM — perception or generation that needs the model. Free-speech understanding, slot extraction, naturalistic phrasing, ambiguous routing.
• 🟦 RIGID — deterministic. Fixed ordering, guard conditions, count branches, tool gating, output templates with slots. A state machine does this for free.
• 🟨 HYBRID — the decision is rigid (a table lookup), the trigger is LLM (recognizing which row applies).
• ⬜ I/O — terminal or mechanical.

Chart 1: Top-level router

Note the top of the call is almost all red. Routing a messy opening utterance to the right branch is the prompt's hardest, least-deterministic job, and it's exactly where the daily reports show the costly misroutes (a bookable diagnostic sent to callback; the "talk to someone" that was really a booking).

Chart 2: Booking subflow (the dominant, most-structured path)

The spine here is almost all blue. Lookup → count branch → guards → availability → offer → response → confirm is a fixed pipeline. The red is confined to four turn-boundary jobs: reading a yes/no confirmation, extracting vehicle/service from speech, classifying the response, classifying an objection. Everything between those is ordering and templates.

Chart 2-ALT: availability-first (maxims target)

Chart 2 above is the current prompt's order: identify the caller, then work toward a time. The rework inverts this for new bookings, following the maxims: address the concern first (M1), look the caller up only when their identity changes the answer (M2), and get to real availability before collecting information (M3). The structural move is that the lookup slides from the front of the new-appointment path to just after the caller accepts a time — because for a brand-new booking, who the caller is doesn't change which slots exist; it only matters at commit, to attach the booking to the right record and reuse the vehicle on file.

The exception is the set of intents where the caller's existing record is the subject: reschedule, cancel, "do I already have an appointment," service history. There, lookup genuinely must come first, because availability and every other answer depends on the record. So the path forks at the top on a single judgment: does resolving this need the caller's record first, or just a time?

What changes, and what doesn't:

• The fork at the top is one new red node. Distinguishing "needs my record first" (reschedule/cancel/already-have) from "just get me in" is language judgment, and it's the single decision the whole reorder hinges on. Get it wrong and a reschedule tries to book a fresh slot, or a new booking burns a lookup turn it didn't need.
• The rigid/LLM ratio barely moves. Still a blue spine with red only at the boundary. The reorder is about sequence, not about shifting work between the harness and the model. So the architectural read from Chart 2 stands.
• It removes the front-loaded lookup turn that the daily reports show losing ready-to-book callers (the first-time caller who asked "any availability tomorrow?" and was refused until he gave year/make/model, then hung up). Availability-first answers that question the moment it's asked.
• Nothing is needed before availability except the service. The current prompt gates availability on year/make/model, but AutoOps doesn't: availability is calendar/slot-driven, not vehicle-specific. Dropping that false gate is what lets availability go first, and lets it be prefetched at call pickup with nothing but the shop (and at most a default service type). The vehicle is required only on the booking itself, so it's collected at the Commit node, after the caller has accepted a time, never as an entry toll. For a known caller, identity is already in hand (caller ID / prefetch), so the new-appointment path collapses to offer → accept → confirm.

Chart 3: Transfer-or-message gate

Once routing has decided "this escalates," the gate is fully deterministic. Zero LLM. The prompt spends a lot of prose on it anyway, and still produces the "let me connect you" / "actually, a message" flip-flops seen in the reports, which is a symptom of prose enforcing what should be a hard state transition.

What the split says

Counting decision/action nodes across the three charts:

Class	Count	Where it lives
🟦 RIGID	~20	The entire booking spine, all guards, the gate, every output template
🟥 LLM	~9	Intent classification, the three "is it really bookable / identity-dependent" 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. The prompt is a state machine implemented in English, which is why edits ripple and rules silently contradict.

The red nodes cluster in two places: the opening (route a messy utterance) and the turn boundary (understand what the caller just said, phrase the next line). That's the genuinely irreducible LLM work.

The general argument lives upstream

What that ratio implies for platform architecture — harness owns the rigid spine, prompt shrinks to the LLM nodes, templates stay templates — isn't EAS-specific and isn't AutoOps-specific. It's written up as Rigid vs LLM: where the boundary sits. This page stays the EAS evidence for it.

How this connects to the rework

• The maxims spec already encodes several of these blue transitions as explicit rules. One of them reorders this chart: availability is checked before information collection, and covers both appointment types at once so the drop-off/waiter trade-off can be presented with its consequences. That is why the availability node is annotated "both types."
• The tabletop sample exercises the red nodes specifically. Every place the maxims are currently silent (for example, what to say when a tool result contradicts the caller's own evidence, or how to handle a quote request for work the shop already inspected) is a red node with no defined behavior yet, and a candidate for the next maxim.