The Fastest Answer in the Room
By Nick Amis - Head of AI Services
10/21/2026
The first week usually goes well.
Someone drops a question into a team channel, and the answer is there before anyone has finished reading the question. It is a good answer. It is also three times longer than anyone wanted, it arrived ahead of the person whose job it was to answer, and it quietly corrected something that person had said on Tuesday. Nobody mentions any of that. A month later the channel is quieter, and the questions that matter are moving through direct messages again.
Being right is not the same as being easy to work with
By the time an AI worker reaches a team, a lot about it has been specified: what it covers, what it is allowed to reach, how accurate it has to be, and who checks. What that list leaves out is how it should behave around the people it works with. Conduct was never part of a specification for software, because software did not have a manner. Anything that answers in a shared channel does.
Nothing in that first week was an error. The answer was right, and it arrived faster than anyone in the channel could have managed. The cost was social, and social costs do not appear in the review a team runs after the first month. Conduct is not a softer version of capability. It is a second specification, and it is usually an empty one. Early on I would watch the questions rather than the answers, specifically whether they are still being asked where everyone can see them.
Organizations have always known this about people. Everyone has worked with someone whose answers were excellent and whose presence in the meeting made the meeting worse. That never appears in a role description, and with people it does not have to. They watch the room and adjust, and the ones who do not adjust hear about it.
The same sentence in two rooms is two different events
Take one sentence: "The figure you used came from the old forecast, and here is the current one." Sent as a direct message to the person who used the old figure, it is help, and nearly anyone is glad to get it. Posted in a channel where that person's manager is reading, it is a correction delivered in public by software. The words did not change. The room did.
A worker that cannot tell those two rooms apart will be right and resented, and resentment is not a thing anyone escalates. People do not file tickets to say the worker embarrassed them. They ask somewhere else next time. Six weeks later, the tool the company standardized on is being routed around by the people it was bought for, and usage still looks fine on the report.
Nobody writes down the rule about not correcting a colleague in front of their manager. That is exactly why it has to be written down now.
Nobody writes down the rule about not correcting a colleague in front of their manager. That is exactly why it has to be written down now.
Not knowing is a behavior, not a gap
What decides whether a team keeps trusting an AI worker is what it does when it is unsure, and this is where a general assistant and a designed worker come apart. A general assistant produces fluent answers under uncertainty, because fluency is what it was built and tuned for. On the screen, a confident guess and a solid answer are the same object. The difference surfaces downstream, after somebody has already acted on it.
A more careful model does not fix that. What fixes it is deciding that behavior in advance: which part of an answer rests on something it can point to, which part does not, and where it says so, in the same message rather than in a footnote nobody opens. When the unsure part matters, it goes to a person, named rather than nearest, with what has already been tried attached so that person does not start from the top.
Which calls belong to the worker in the first place is a different question, and this series mapped it earlier in What Decision Boundaries Actually Look Like. This piece starts after that map is drawn. Given a decision that is the worker's to make, what is left is how it carries itself while making it, and in whose hearing.
I keep coming back to how ordinary the human version of this is. A good analyst says she is confident about one part of an estimate and much less confident about the rest, and everyone downstream adjusts without being asked to. It is unremarkable behavior that takes a person years to learn and costs nothing to receive. Getting the same behavior from an AI worker is a decision somebody has to make on purpose.
Conduct has to be written, because it cannot be absorbed
People arrive with this already installed. Years of social learning, then a week of reading one specific room: how a manager takes disagreement in public, and which corrections belong in a private message rather than in the meeting. New colleagues are never handed that document, because there is no document. They pick it up by being there.
An AI worker picks up none of it by being there, and no amount of capability closes that. So conduct has to be authored the way the rest of the role is authored. Someone decides it, writes it down, and changes it a month later when the team says the thing is too chatty. An earlier piece in this series, Who, Not What, argued that a role needs a written who, covering what the worker owns and what it hands to a person. Conduct is the part of that description a colleague actually meets.
It also has to be observable. A rule nobody can see followed is a wish, and behavior that cannot be reviewed cannot be corrected. That is the argument this series has already made about what a worker knows, applied unchanged to how it acts.
So there are four things worth designing under the hood of an AI worker, and the fourth one rarely gets a meeting: what it earns by doing the work, what it is handed, who it is, and how it behaves around the people it works with. The first three are read by whoever writes them. The fourth is judged in real time, by a room that has read nothing.
That is the design question. The harder one belongs to the organization bringing the worker in, which now has to say out loud how work gets done here, in enough detail that a new worker can be handed the answer.
Head of AI Services, Arkane Digital
Nick leads AI implementation across enterprise workflows, focusing on turning experimentation into repeatable, operational systems that drive measurable outcomes.