An employee asks her company's internal AI assistant when she needs to enroll a new dependent. The answer comes back in seconds, correct and complete, pulled from the current policy. She reads it twice, then opens Teams to ask a colleague what she is actually supposed to do.
The answer was right. Nothing around it told her whether that policy applied to her, when it last changed, or who handles the enrollment once she decides.
We tend to evaluate an assistant on whether the answer was correct, because that is the part the product team can test. She is running a different check. Is this current? Does it apply to me? Where did it come from? What do I do now? Who do I talk to if it is wrong? The answer is one input into that check. The rest she has to get somewhere else.
The answer is the smallest part of the experience. Everything that decides whether someone can act on it lives around the answer.
Accuracy was the right first problem, and getting an assistant to find the right passage instead of a confident invention took real work. That work finished sooner than we expected. The harder problems sit next to the answer, not inside it.
Most of them are small design decisions. A citation the reader can open. A date on the source. A sentence that says where coverage stops, before someone finds out the hard way. A handoff that carries the question with it, so nobody has to tell the story twice. None of these change the answer. All of them change whether the answer is usable.
One of those goes further than the rest. Showing the source does more than reassure the person reading. It puts that document back in front of someone who can judge it. Internal knowledge is usually reviewed by teams sitting a few steps from the work it describes, which held up fine when a handful of people read an article in a month. An agent reads it constantly and answers from it constantly, so anything stale stops being a small problem quietly. The teams closest to the work are the ones who can say whether an article is still true, and the citation is what puts their name on it.
That is a knowledge problem before it is an AI problem, and it is the ground everything else here stands on.
The hardest of those design decisions is what to do with uncertainty. An assistant that sounds equally sure about everything teaches people to trust it evenly, which means they trust it just as much on the answers it got wrong. An assistant that says plainly what it does not know gives up a little authority in the moment and earns the kind of trust that survives a bad answer.
These decisions get harder as the number of agents grows. Copilot Studio put agent building in reach of teams that have never shipped software before, which is good for any large company. It also means one person might use four or five different agents in a week, each built by a different team. One cites its sources, and another does not. A third keeps talking when it should say it cannot help. Working that out falls to the person using all the agents, and none of that effort shows up on the team that built any single agent.
So the question is what the person asking does next. If the next move is obvious, the experience worked. If the next move is opening Teams, the answer was correct and the experience was unfinished.
Tuning what an agent says is the satisfying part. I can change a line, watch it land better, and keep going for an hour. What happens after it answers is quieter, and it is where the person using it actually lives.
That is the part of Ask Hubert, an internal assistant my team builds, that I care most about now: the ten seconds after it answers, and whether someone can see where the answer came from, what it does not cover, and where to go when it is not enough. Those questions sit in front of any team building an agent.
Every agent we add either makes the day easier or leaves one more thing for someone to figure out. Which one it is depends on what we build around the answer.