The First Meeting Is Mostly About Expectations
We delivered essentially the same document assistant to two customers in the same quarter. One renewed and expanded it. The other stopped after six months with a working system that nobody used, and the divergence was visible in the kick-off notes.
Two Projects, One System
Both customers wanted an assistant over technical documentation. Both got structure-aware chunking, hybrid retrieval, a refusal path and a review queue. Measured accuracy on their respective labelled sets was within two points of each other.
One expanded the system to a second department. The other stopped, and the closing meeting was not about quality: their users had expected something that answered everything, encountered a system that declines about one question in eight, and concluded it did not work.
What Was Different in the First Hour
The successful project's kick-off produced a written list of what the assistant would not do. Not as a disclaimer, as a scoping artefact that their department heads reviewed and signed. It named the question types that would be declined and where those would go instead.
The other kick-off produced a list of what it would do, which is what a kick-off normally produces and which sets an expectation that any refusal is a defect. We ran that meeting. The failure was ours before anything was built.
The Research Framing
Vishwarupe and colleagues published work in 2026 on expectations management in domestic AI systems, arguing that expectations are treated as an afterthought or delegated to compliance rather than being handled as part of the design.
The setting is different from ours and the argument transfers exactly. Expectation is not a communications task performed after delivery; it is a property of the system that is decided when someone first describes what it will be, and it is much harder to change afterwards.
| Sentence we insist on | Why |
|---|---|
| What it will refuse to answer | Makes a refusal a feature, not a fault |
| Where a refused question goes | Turns a dead end into a route |
| What a wrong answer costs here | Sets the verification level |
| Who checks whether it is working | Names an owner before there is a system |
The Four Sentences
What it will refuse. Where a refusal goes. What a wrong answer costs in this process. Who is responsible for noticing whether it works. Four sentences, agreed and written before design starts, and the first two are the ones that change how users experience the system.
None of them is technical, and all four are answers we cannot supply. The customer has to write them, which is why the first workshop now has their department heads in it rather than only their IT function.
How the Refusal Sentence Changes Behaviour
A user told in advance that the assistant does not answer questions about pricing or personnel encounters a refusal and reads it as the system working correctly. A user told the assistant answers questions about the documentation encounters the same refusal and reads it as a broken system.
Same system, same message, opposite conclusion. That asymmetry is most of why the two projects diverged, and it costs nothing to get right except a conversation nobody wants to have while everyone is enthusiastic.
What We Stopped Doing
Demonstrations with our own examples. They are impressive, they set the expectation that everything works like the demonstration, and they are chosen from the part of the question distribution where the system is strong.
The first meeting now uses their questions on their documents, including the ones that fail. That makes for a worse meeting and a better project, and it has not cost us work: the two customers who declined after seeing failures would have declined six months later at greater expense.
The Uncomfortable Version of This Article
The abandoned project was not the customer's fault. They asked reasonable questions, we answered them accurately, and we never said the sentence that mattered: about one question in eight will not be answered, and here is why that is the correct behaviour.
We knew it. It was in our proposal as a technical characteristic rather than as an expectation, and a number in a proposal is not the same as a shared understanding among the people who will use the thing.
What We Do Not Claim
We do not claim expectations explain every failed project. Ours failed for that reason and we have had others fail for cost, for data quality, and once because the process the assistant supported was discontinued.
We also do not claim four sentences are sufficient. They are the minimum we now refuse to start without, and a larger organisation with more stakeholders needs a longer conversation than a workshop can hold.