Why the chat tool, not another app
Every new tool in a company carries a cost nobody puts in the budget: someone has to learn it, remember where things are clicked, and roll it out to each person separately.
So we start from software the team already uses without training. An agent answering in the thread beside colleagues is not another application to master — it is another participant, and that is the one category of deployment that asks nobody to learn a new skill.
What it actually does
It is not about writing paragraphs. It is about the work somebody on the team does every day that does not require their judgement: read a ticket and summarise it for the rest; prepare a draft reply for approval; gather a status from three places so nobody assembles it by hand; produce a recurring report, on time, in one format; write the small internal tool nobody has time for.
In our deployment that is dozens of such items a day. They share one property: if a person had to do them manually, they would not get done.
What we don't let it do
These are limits we set — not a list of things the model cannot do. The difference matters, because a limit is a company decision, not a property of the technology.
Hiring, negotiation, risk assessment and the conversation with an angry client stay with people, even where the agent could prepare the material for them. The agent does not send an offer, change a configuration or spend money, because none of those can be undone. And it does not carry responsibility: responsibility is not a function you can hand to a model.
In our setup the agent prepares the result and leaves the decision and the signature to a person.
What has to be settled before the start
The company grants and revokes access; the agent cannot widen its own permissions. It sees the documents it has been admitted to, not all of them because that was more convenient.
The company keeps a record of what the agent did and on whose behalf. Without it, the first question — "who sent this" — goes unanswered, and that question always comes.
The company has a procedure for when the agent stops working or starts working badly: who notices, who decides to switch it off, and who does its work in the meantime.
The trap that kills most of these deployments
Not the model. The absence of an owner. Someone on the team tries the agent for a week, is delighted, goes back to their job, and the tool dies quietly because it was nobody's responsibility.
It is the same problem we wrote about separately: software that samples has a service schedule. An agent in your chat tool is no exception — supervising it is somebody's job, or the deployment gets started over.
What this means for your company
Pick one task that genuinely repeats and is genuinely needed — not the most impressive one, the one whose absence has annoyed the team for months.
Assign one person to review and approve the result. Not "the team" — one person, with a name.
Write down the limits the agent does not cross. That list matters more than the feature list: it is the one that survives an audit, and the one that protects the deployment when something goes wrong.