Every AI project I have seen starts the same way: everyone is excited, and nobody agrees on what they are building. The CEO means “cut costs.” The engineers mean “agents and RAG.” Marketing means “we can say AI in the deck.” Support means “please, anything that reduces tickets.” All four say the word AI in the same meeting, and all four believe they agreed.
Leading AI work at an agency taught me that this is not a communication problem. More meetings do not fix it. It is a definition problem, and it has a technical solution.
The eval set is the real alignment document
The best alignment tool I have used is not a strategy document. It is a table of real questions with the correct behavior written next to each one. This input should get this answer. This one should trigger a tool call. And this one — this is where the room goes quiet — should be refused.
Writing that table forces every hidden disagreement into the open, early. Should the assistant answer pricing questions? Should it guess when the docs do not cover something? When should it hand over to a human? People who nod along to “an AI assistant for our customers” discover they mean different products. Better to discover that over a table than over an incident.
I believe this strongly enough that I built it into open-source tooling: gold labels where refusing and asking for clarification are correct answers, not failures. Because “the model answered” is not success. The model did what we agreed it should do is success — and that requires having agreed.
Demos kill alignment
A demo is tuned for the five inputs shown in the meeting. Everyone leaves agreeing on those five inputs and nothing else. Then input number six arrives in production, the system does something nobody discussed, and every stakeholder feels let down in a different direction. The excitement from the demo becomes fuel for the blame.
My rule now: a demo may open the conversation, but the eval set closes it. If a behavior matters to someone in the room, it becomes a row in the table. If it is not a row, we have not agreed on it — and we say that out loud instead of pretending.
Three habits that keep a team aligned
- Numbers, not adjectives. “Better” is banned in reviews. Faithfulness went from X to Y on the same gold set, or it did not. This one rule removes most arguments — including, sometimes, arguments I was winning with adjectives.
- Failure modes get names. “It is hallucinating” is four different bugs: retrieval missed, chunking cut the answer in half, the model ignored the context, or the question had no answer and the system did not refuse. A team with a shared failure vocabulary debugs in minutes what a vague team debates for days.
- Non-engineers own rows. Support and product people should write and veto rows in the eval table. They know what a correct answer looks like better than the engineers do. The best gold set I built was mined from resolved support tickets — a real question, a verified answer, a known source document. Once non-engineers own rows, they stop treating the AI as magic and start treating it as a system with a spec they helped write.
None of this is exciting. That is the point. The teams that ship dependable AI are not the ones with the most excitement. They are the ones that turned excitement into rows, numbers, and names before writing much code.