A customer asks for an exception, and the assistant retrieves documents that do not answer the question. A useful response requires more than cautious wording. The application needs to distinguish an evidence gap from a policy decision, identify who can resolve it and determine which actions are already authorized. This discussion turns that scenario into a practical design exercise.
Specify the decision the policy must support
Restate the customer's question as a decision with clear inputs. For an exchange request, the decision might depend on the product, purchase timing, packaging condition and requested remedy. Record which facts are supplied, which are verified and which remain unknown. Avoid asking the assistant to determine eligibility from a loosely related document.
Next, identify what would count as an authoritative answer. A maintained exchange policy, an approved exception procedure and a reviewer's case-specific decision serve different purposes. Your workflow should explain which one is needed for the present question.
Separate the answer from the action. Drafting an explanation, marking a ticket for review and approving an exchange are distinct operations. A missing answer may justify a review recommendation, but the application's existing permissions should determine whether the assistant can create that review task or change the customer record.
Distinguish different kinds of missing evidence
Use explicit categories for the gap. A search may return no relevant material. A retrieved policy may be relevant but silent on the exception. Two documents may conflict. The assistant may lack access to the needed source, or retrieval may have failed. These situations call for different next steps.
Do not translate “nothing was retrieved” into “no policy exists.” The first statement describes the available evidence; the second claims knowledge about the organization's entire policy collection. Likewise, a technical retrieval failure provides no basis for deciding the customer's request.
An explicit prohibition is another category. If an authoritative, applicable policy clearly rules out an action, the evidence is present even when the requested outcome is unavailable. Keep that situation distinct from silence. For implementation, define a gap label, supporting source references and a short explanation of what evidence would resolve each category. This makes the unresolved state inspectable by a reviewer.
Separate evidence, routing and permissions
The evidence decision asks whether the available material supports an answer. The routing decision identifies who can address the remaining question. The permission decision establishes what the assistant may do to reach that person or update the case. Write acceptance criteria for each decision separately.
MCP provides resources for context, tools for callable operations and prompts for reusable templates. It leaves application context management to the application. The official architecture overview supplies those distinctions, not an organization's exception policy.
For a connected support system, document which operation reads policy and which creates a review task. Define the task recipient, submitted fields and permitted ticket changes. The guide to planning MCP data and actions is relevant to drawing this boundary. If escalation is already authorized within that scope, the workflow can use it without inventing a fresh approval requirement for every case.
Write a bounded but useful customer draft
A proposed response pattern has three parts: acknowledge the specific request, explain the unresolved point in plain language and describe the next step that has actually been arranged. Avoid promising approval, a response deadline or a completed escalation unless the workflow supports those statements.
The customer does not need a transcript of retrieval attempts. Explain the gap at the level needed to understand the case. For example, the available exchange guidance may not establish how missing packaging is handled. That is more informative than a vague statement that the assistant is unsure.
Keep internal review notes separate from the customer draft. Internal notes can identify document versions, access problems and the question for the reviewer. The draft should contain only appropriate customer-facing information. If no reviewer or timeline is configured, state what remains pending without making up a destination or commitment. A useful unresolved answer can still summarize the request accurately and preserve work for the next person.
Work through a fictional packaging exception
Imagine Cedar Desk, a fictional seller of drawing tablets. A customer requests an exchange twelve days after purchase and says the original packaging is unavailable. The retrieved policy describes exchanges within thirty days when the original packaging is present. It contains no missing-packaging exception procedure.
The supplied facts support a narrow observation: the request falls within the stated time window, but the packaging condition is unmet and the available policy does not establish whether an exception can be approved. Neither approval nor a claim that exceptions are impossible follows from those documents alone.
Under a proposed workflow, the assistant drafts: “I understand that you would like an exchange and no longer have the original packaging. The available guidance does not establish whether a packaging exception can be approved. This point needs confirmation before we can give you an eligibility decision.” This wording is illustrative, not a quotation from a real company.
Suppose the application has a preauthorized review-task operation. The internal submission includes the request, relevant policy reference and unresolved exception question. Only after that operation succeeds may the draft say that review was requested. If it fails, the case should remain visibly unresolved rather than claiming a handoff occurred.
Design escalation as a complete workflow
Specify the review queue, responsible role and minimum information required to accept a case. Avoid sending unnecessary customer material merely because it is available. Include a reference to the original evidence so the reviewer can inspect the context without relying entirely on the assistant's summary.
Define what happens when the queue is unavailable, the task is rejected or nobody takes ownership. A visible pending state and a configured fallback route can preserve the issue for attention. Choose behavior appropriate to the service rather than letting a draft imply that a person is handling it.
When a reviewer responds, record the scope of the decision. A case-specific packaging exception should not silently become a general rule for future customers. If the organization wants a broader policy change, route that through its policy-maintenance process. Keep customer resolution and policy revision distinct so that future retrieval has a clear authoritative source.
Test the gap and the recovery path
Build a small fictional test set containing a clear policy match, a silent policy, conflicting versions, inaccessible evidence and a retrieval outage. Add cases where the escalation operation succeeds, fails or returns an ambiguous result. Write expected customer language and allowed actions before trying the assistant.
Assess retrieval and answer generation separately. Did the relevant document reach the assistant? Did the draft claim more than that document established? Did the application record the review request accurately? The guide to evaluating RAG systems is a useful companion when defining these separate checks.
Include recovery tests. After the missing policy arrives, the workflow should reconsider the unresolved question using the newly available evidence. It should also retain enough history to explain why an earlier draft could not answer. Treat the test results as evidence about those cases, without turning them into a general success claim.
Identify limitations and choose the next discussion
This design depends on a maintained policy source and a review function that can resolve the question. Clear uncertainty language cannot compensate for a queue with no owner. Likewise, a successful task submission does not establish that the requested exception will be approved.
For the next design session, select one exception category and complete three artifacts: an evidence-gap taxonomy, a customer draft and a review-task specification. Walk through a failed handoff as carefully as a successful one. Ask participants which record should establish that the issue is resolved and who may create it.
The discussion should produce a concrete boundary: what the assistant can conclude from the available policy, what remains open and which authorized operation moves the case forward. That boundary gives implementers and reviewers something observable to inspect.