
Define what it needs to know before answering
An instruction such as “do not invent information” becomes useful when you explain what the decision requires. Identify mandatory fields, valid sources and conditions that prevent a conclusion. The assistant should be able to identify the specific gap, rather than express a vague doubt that does nothing to move the conversation forward.
I start with the preparation the business needs to do. The team must define what it sells, to whom, under which conditions and with which responsibilities. Asking AI to fill those decisions with plausible text creates context that can look complete without representing the company.
Imagine a hypothetical assistant that helps prepare training proposals for teams. To suggest a format, it needs to know the objective, the audience and the delivery conditions. It can explain general options without those details, but it should not present a specific proposal as though the brief were complete.
Missing information does not prevent every kind of answer. If the user asks which details to gather, the assistant can help with a short list. If the user wants confirmation of availability or a commercial commitment, different information and authority are required. Write these distinctions into the task instructions.
This develops the work of giving AI context without collecting information indiscriminately. Useful context includes facts and rules for interpreting them. It should also specify which decisions remain with the team, even when the assistant has enough information to suggest an approach.
To prepare your next step, explore Artificial intelligence in customer service.
Distinguish missing data, ambiguity and contradiction
The assistant should treat an empty field, an ambiguous expression and two incompatible statements differently. In the first case, it asks for the missing detail; in the second, it clarifies the meaning; in the third, it identifies the conflict. This distinction prevents repeated questions and stops it choosing whichever version happens to seem convenient.
In the training example, “we want to improve productivity” may be too broad an objective to select a programme. The assistant can ask which tasks the team wants to improve. If the objective is already defined and only the number of participants is missing, the question should concern that number.
A contradiction needs different treatment. Imagine one document specifies an in-person session and the latest message mentions remote participation, without clarifying whether it replaces the first instruction. The assistant should explain the difference and request confirmation, rather than combine both conditions into an apparently settled proposal.
Also specify how to handle older materials. A document date helps establish context, but does not prove by itself that a rule has expired. If a source has been formally designated as current, use it; if the relationship between versions is unclear, the conflict remains unresolved.
In qualifying B2B opportunities with AI, this discipline prevents a lack of information being confused with a lack of interest. Failing to find a published budget does not demonstrate that the company has no budget. The status can remain “to be established”, with a question or an authorised search as the next step.
Write response examples that help the conversation continue
A useful response to a gap identifies what is known, what is missing and which question would allow progress. Demonstrate this pattern with examples close to real tasks. Avoid teaching only a refusal phrase, because repeating “I do not have enough information” can leave the user with no practical guidance about what to provide next.
For the hypothetical training request, an acceptable response would explain that the subject has been identified but the team's actual tasks remain unclear. It would then ask a concrete question about those tasks. The conversation progresses from the available information, without converting the gap into an invented proposal.
You can place an unsuitable response beside the desired version. If the team size is missing, a proposal that assumes a small group needs correcting. The desired version makes the dependency explicit and asks for the detail, rather than presenting an assumption as a confirmed fact.
Define when a hypothesis is acceptable. In an exploratory exercise, the assistant can work with a clearly labelled fictional condition and explain that the outcome depends on it. That hypothesis should not silently migrate into the final summary or a document sent as a real proposal.
Keep questions proportionate to the decision. An assistant that requests the company's entire history to clarify a simple point creates unnecessary friction. Start with the information that changes the next step and use what has already been supplied, without making the person repeat the same brief.

Define when to involve a person
Escalate when an answer depends on a reserved decision, information the assistant cannot access or a conflict the sources do not resolve. The handover should include the request, available facts and specific uncertainty. Announcing that somebody will handle the matter is insufficient unless a process actually exists for that person to receive and resolve it.
In the training example, the assistant can organise the brief and explain the planned formats. An exception to commercial conditions may require a decision from the responsible person. Missing information and missing authority are different reasons to stop, and the message should make that distinction understandable.
When considering when automation needs AI and when rules are enough, separate interpretation from execution. The application can require mandatory fields before allowing an action. Necessary permissions and confirmations should be checked by the system executing it, rather than relying only on the model's written response.
When I made an assistant available to the public, people tried to obtain its instructions and internal information. That experience reinforces the need for boundaries around what the assistant can access and disclose. An insistent conversation does not create permission to provide information outside the legitimate request.
When handing over to the team, retain only the context required to resolve the matter. Explain what has already been asked and avoid promising a response deadline that has not been defined. If the system only prepares a draft handover, it should say so, without claiming that the message has already been delivered.
Test behaviour with deliberate information gaps
Prepare cases where a mandatory detail is missing, a contradiction exists or the person demands an immediate answer. Define acceptable behaviour in advance and inspect the response you receive. Include complete requests too, to check that the assistant can proceed when the conditions are met instead of turning every conversation into a refusal to help.
You can start with different versions of the same brief. Remove the objective from one, change the delivery format in a second document for another, and supply all necessary information in a third. The test becomes clearer when you know exactly what changed and how that change should affect the response.
Assess the content, rather than merely looking for a cautious phrase. An assistant can state that it is uncertain and then invent the missing detail in the next sentence. It can also ask for clarification about something already explicit. Both cases require reviewing the instructions or the organisation of the context.
Save examples that reveal failures and reuse them after making changes. If a correction improves contradiction handling, check that it has not started blocking simple requests. The evaluation should consider the usefulness of the conversation and fidelity to the data, alongside the ability to stop.
Teaching this behaviour means defining, illustrating and testing instructions; it does not imply retraining the model or guarantee perfect compliance. Keep a review path for important cases and update examples when the process changes. The aim is to make gaps visible and manageable before they become unsupported decisions.