4 minute read · Practical field guide
Split one workflow into smaller decisions
An appointment assistant receives “Can we do later?” The application already knows whether an appointment exists and which time slots are available. The customer’s wording still needs interpretation: later today, later in the week or a longer visit? These are different problems. Assigning the entire exchange to either a rigid sequence or an unrestricted model makes the design harder to reason about.
List each decision in order: identify the current record, understand the request, find missing information, validate a proposed change and record the result. Mark which decisions have explicit inputs and rules. Then identify where a short clarification or language interpretation would actually help. This is an application design exercise, not a claim about the performance of a particular model.
Give rules the decisions with explicit conditions
Rules are useful for checks such as whether a record is cancelled, a required field is present or a message event has already been handled. Keep the condition and result visible enough that an operator can explain them. A rule should refer to the current business state rather than a stale copy embedded in a conversation summary.
When a rule lacks the information it needs, define an unresolved outcome. A missing appointment identifier should lead to a lookup or clarification, not an arbitrary default. This keeps the rule understandable as the number of customer situations grows.
| Decision | Useful rule-based part | Useful language-assistance part |
|---|---|---|
| Find the current task | Look up authorized candidate records | Interpret the task the customer describes |
| Check availability | Read current permitted slots | Ask which workable option they prefer |
| Prevent repeated action | Use durable operation and event identifiers | Explain the existing result clearly |
| Handle uncertainty | Block actions missing required facts | Ask a focused clarification question |
Give language assistance a bounded job
An assistant can help turn varied wording into a structured proposal or draft a question that resolves missing context. Define the output you need, such as a candidate appointment reference, requested date and unresolved fields. Keep the original customer message available for review so a colleague can inspect the interpretation.
Let the assistant say that it cannot choose confidently between two plausible tasks. A useful response may be “Do you mean the delivery or the installation?” rather than a completed change. The application should determine what operations are permitted and what evidence they require. Customer text is input to the workflow; it does not rewrite the business rules or grant new permissions.
Validate the proposal against live records
Before applying a change, check the target, required fields, current record version and permitted operation. A slot discussed earlier may no longer be available. A colleague may have already resolved the request by phone. Keep the proposed action separate from the execution result so the assistant can accurately describe what happened.
Use explicit failure states for an unsuccessful business-system update. If the calendar rejects the change, preserve the request and route it for recovery. The next outgoing message should reflect that result rather than an optimistic draft written before execution. This separation makes it easier to test the system and prevents fluent language from concealing unfinished work.
Test the boundaries between the two approaches
Build cases where the rules can decide immediately, where the assistant should clarify and where a human must take over. Include a clear confirmation, an ambiguous relative date, a cancelled record and a duplicate inbound event. Write the expected action before running the case. The resulting evidence should show both the language interpretation and the application decision.
Inspect situations where the two disagree. The assistant may propose a reasonable-sounding action that fails a current-state check. Preserve the reason and produce a useful next step for the customer. The rules may also expose a missing product decision, such as who can authorize a change. Resolve that policy deliberately instead of adding a prompt that asks the model to improvise it.
Expand the assistant’s role from observed needs
Start with a narrow operation and a visible human path. Review unclear requests, rejected proposals and recovery work with the team that owns the underlying service. Add language assistance where it reduces a specific burden, and retain straightforward rules where the inputs already determine the answer. Keep examples of both successful and correctly deferred actions.
Messaging-provider documentation explains transport events and testing facilities. It does not establish the quality of the assistant’s business decisions. Maintain separate evidence for channel behavior, interpretation and execution. A dependable design can explain which component made each decision and why the customer received the resulting reply.