Variability matters more than the label
Tools should match variability. Reminders tied to confirmed dates need clear rules; free-text requests may need interpretation. Identify variable and fixed parts first. Flexibility can add unnecessary uncertainty, while rigid language handling becomes hard to maintain. Choose by task nature and consequences. Ask which errors would be acceptable to correct later and which decisions need a firm boundary before execution. The answer may lead to different approaches within the same journey. A flexible interpretation step can prepare information while a deterministic rule enforces an approved condition for the following action.
Combine interpretation with controlled execution
Interpret contact intent, then use a defined lookup or modification flow. Understanding is not authorization: recognizing rescheduling does not permit arbitrary slots or bypassed conditions. Check availability and rules. This separates review points and allows operational tests across varied wording.
Keep explicit boundaries
Flexible tasks still need available-tool, data-access and stop boundaries. Missing information may require questions or handoffs. Consequential actions can require approval within otherwise automated journeys. External document instructions should remain case information, not change designed permissions. Make stopping behavior as explicit as successful completion. A task that cannot be completed with the available information should produce a useful clarification or handoff, not invent another path solely to keep moving. Reviewers need to understand which constraints prevented progress and what evidence would allow the case to continue under the intended process.
Compare using the same criteria
Compare equivalent cases through correctness, intervention and maintenance. Simplicity may conceal manual exceptions; flexibility may obscure decisions. Test catalog changes, missing information and failure recovery beyond demonstrations. Choose architecture that sustains intended work with understandable controls. Include maintenance work in the comparison. When a catalog changes, identify who updates the relevant rules, examples or reference material and how the team checks that behavior remains correct. A design that is impressive once but difficult to adjust can become expensive to operate in staff time. Compare approaches using the same exceptions and recovery conditions, so the choice reflects repeatable work rather than the style of the demonstration.
Start with the most stable part
Map known steps and mark interpretation or decision points. Add flexibility there with tests and review, preserving reliable procedures while focusing evaluation on genuine variability.
Illustrative example: one change request, step by step
Picture, as a hypothetical case, a message that reads: “Can I move my Thursday appointment to Friday afternoon and add my son?” Three different jobs hide in that sentence. Recognizing a reschedule that also changes the headcount is interpretation work, because nobody phrases it the same way twice. Checking which Friday slots exist and whether they admit two people is a lookup with an exact answer. Moving the booking only when the change policy allows it is a rule.
A sensible design hands each job to the tool that fits it. Interpretation produces a structured proposal: intent, desired date, people. The lookup returns real options. The rule decides whether the change goes ahead or needs a person. If interpretation gets it wrong, the damage stays contained, because the rule and the scheduling system still have the final say.
Common mistakes when choosing between an agent and rules, and how to spot them
The first mistake is choosing by fashion: an agent for everything because it looks modern, or rules for everything because they feel controllable. The second is measuring only the happy path. The third is letting the flexible component execute actions with no verifiable condition. The signals show up in daily operations if you know where to look.
- A rule tree with dozens of branches to recognize free-form phrasing usually means interpretation is being solved by hand and gets harder to maintain every month.
- Different answers to equivalent questions about a price, a schedule or a policy suggest that something meant to be an exact lookup was left to interpretation.
- Exceptions piling up in a side spreadsheet point to rules that are too rigid for the real variation in the work.
- If nobody can explain why an action was executed, an explicit condition is missing between understanding and execution.
Checklist and channel design: WhatsApp versus voice
Before deciding, answer each checklist question in writing and share it with whoever runs the process. The channel changes the choice too. On WhatsApp a person may write a long paragraph, attach a photo and correct themselves later; interpretation adds more value there, but a short confirmation of what was understood should come before any action. On a voice call people dictate dates and names that can be transcribed badly, so validation rules and reading back key data weigh more. Check each messaging and voice provider’s current conditions, since they affect who can start contact and within what windows.
- Which parts of the journey always follow the same sequence, and which vary by customer?
- Which error can be corrected later without harm, and which needs a firm limit before execution?
- Is there a verifiable condition between understanding the request and acting on it?
- Who maintains the rules, and who reviews the cases interpretation could not resolve?
Take it to your team.
- Separate interpretation from authorization.
- Choose through variability, maintenance and consequences.
- Give each task its own tool: interpreting, looking up and deciding are separate jobs.
- The channel shifts the mix: more validation on voice, more short confirmations on messaging.



