Where to put an AI agent: the decision taken last that rules from the start
Where to put an AI agent is a question that almost always arrives at the end, once the thing works and somebody has to see it. It arrives late, and it shouldn't: this isn't a packaging decision. It decides who actually uses the agent, how long it has to answer, what permissions it is born with and what stays on the record when it gets something wrong. Picking a surface is picking architecture, latency budget and security model in one move.
The thesis of this guide is short and it holds in every company: an agent that lives where people already work gets used; an agent that lives in its own tab dies alone, no matter how good it is. This is not about enthusiasm or training. Every new surface you ask someone to open is an attention toll they pay daily, and that toll has a measured price: research published by Harvard Business Review in August 2022, covering 137 workers across three Fortune 500 companies, counted roughly 1,200 daily toggles between applications and windows — close to four hours a week, around 9% of working time, spent purely on reorienting. Source: How Much Time and Energy Do We Waste Toggling Between Applications?, Harvard Business Review, August 2022.
The surrounding noise doesn't make room for a new tool either. The Microsoft WorkLab report on the infinite workday, published in June 2025 from aggregated, anonymized Microsoft 365 signals, puts an interruption every two minutes during the workday — 275 a day for the top 20% most-notified users — across meetings, email and chat. Source: Breaking down the infinite workday, Microsoft WorkLab, June 2025. Against that, asking someone to remember one more tab is not a small ask. It's competing for the most expensive slot your team has.
The five real surfaces and who is on the other side of each
In practice there are only five places an enterprise agent gets installed, and each one comes with a different user attached. You don't pick a surface because you like it. You pick it by finding where that person is at the exact moment the work shows up.
- Inside the CRM or the ERP. User: the employee who already lives there eight hours a day. Best adoption, worst demo value — nobody wows a buyer with a side panel. In exchange, the agent shows up next to the record it is about to touch, with the account and the history already on screen, and nobody has to be told where to find it.
- Slack or Teams. User: the team, mid-conversation. Good for work that starts as a question — "does this customer have a support contract?" — and for decisions made collectively. The real advantage: question and answer are visible to everyone, and that builds trust far faster than a private chat ever will.
- WhatsApp. User: the customer who already writes to you there. It has the most commercial traction in Spain, Italy and Portugal, and the most platform rules attached. You pick it because the customer is already there, never to move them there.
- Web chat. User: an anonymous visitor who is deciding. The most demanding surface on latency and the poorest on context: you don't know who they are. Its job is to qualify and capture, not to resolve customer cases.
- Email. User: the process, more than the person. Supplier invoices, orders, requests that already land in an inbox. The least glamorous surface and the one hiding the most repetitive work, because nobody looks at it as a channel. They look at it as a folder.
There is a sixth one that almost everyone picks by default, and it is left off the list on purpose: your own tab, the internal app with its own URL and login. Not useless — it works for deep work, long sessions, an expert user who goes there deliberately. The problem is that it gets picked for the builder's convenience, not because that is where the work is. If the use case is "handle something that comes up while you're doing something else", your own tab is the worst option available.
Latency: how much silence each channel takes before you lose the user
Every surface carries an implicit time budget nobody writes down and everybody respects. You find out when you break it: the user declares the agent dead and leaves. These are the orders of magnitude worth designing against.
| Surface | Response budget | What it forces you to build |
|---|---|---|
| Web chat | Seconds | Fast model + partial answer while it works; never wait for the complete answer |
| Seconds to a couple of minutes | Immediate acknowledgment; the customer is not staring at the screen | |
| Slack / Teams | Tens of seconds | A reaction or an "on it", then the real message; async is already accepted here |
| Inside the CRM / ERP | Seconds if it is a button; minutes if it writes to the record | Decide whether it is an interaction or a background process — two different designs |
| Hours | Almost nothing: latency stops being the problem and traceability becomes it |
The hardest consequence to swallow is that the channel outranks the model. If the surface demands seconds, you cannot afford three chained calls to the most capable model no matter how well it answers. You will have to split the work — cheap to classify and route, capable to decide — and return something before you are done. That split is worked out in which model to use in an AI agent, and it is a decision you make after the surface one, not before.
Permissions: every surface arrives with its own already switched on
Installing an agent on a surface is not security-neutral: it inherits that surface's permission model, and the default almost always asks for too much. Worth checking before you sign, not after the first incident.
- CRM / ERP: it inherits, and that is the good news. The agent can run with the role of the user who invoked it, so if the rep cannot see that account, neither can the agent. It is the only case where the surface hands you the work already done. What to watch for is the temptation to give it a service account with admin rights "so nothing breaks".
- Slack / Teams: its own scopes, and the dangerous one is history. It installs as an app with its own permissions. Reading a channel's full history is far more than most cases need — receiving the messages where it is mentioned covers the majority. Asking for full history turns the agent into a permanent reader of internal conversations, and that deserves to be a conscious decision.
- Web chat: strangers. It talks to unauthenticated visitors, so it cannot have read access to specific customer data. Anything that smells like "tell me my order status" needs an identification step first, or you ship an elegantly designed data leak.
- WhatsApp: fragile identity. A phone number is not a verified identity — numbers get recycled and phones get lent. Any action with consequences needs an extra verification step.
- Email: scope is the trap. Granting access to a mailbox grants access to its entire history. Scope it by label, folder or dedicated alias, never by whole mailbox.
The rule common to all five: permissions get requested per use case and reviewed with an expiry date. You do not accept whatever the installer brings. The full version — what you grant, how you revoke it and what gets logged — is in what permissions to give an AI agent.
What stays on the record and what evaporates when the tab closes
The day the agent gets something wrong — and it will — the question is not "why?", it is "where do I look?". The surface decides whether that question has an answer in two minutes or in two days.
Slack and Teams are the best surface on this axis and almost nobody weighs it when choosing: the conversation stays written down — who asked, what the agent answered, who pushed back — in a place the company already retains and already knows how to export. Inside the CRM you get something similar if the agent writes to the record instead of a volatile panel: the note stays attached to the customer and the case. Web chat is the opposite extreme: the session closes and, unless you built persistence on purpose, there is nothing to audit beyond whatever your vendor decided to keep and for how long.
This connects to what happens when the agent hesitates or runs out of answer: handing off to a human is only cheap if the surface keeps the context. In Slack or in the CRM, the person walks in and reads what is already there. In a web chat with no persistence, the person starts from zero and the customer repeats everything. What has to travel in that handoff is in what an AI agent does when it does not know the answer.
The channel rules you do not negotiate: WhatsApp and email
Two of the five surfaces come with their own platform rules, and they are not guidelines: ignore them and the channel stops working. Worth knowing before you promise an experience the platform will not allow.
On WhatsApp, when a user messages you a 24-hour customer service window opens; inside that window you can reply with free-form messages, and if the user writes again the clock resets. Outside it you can only reach out through pre-approved templates, classified by category — utility, authentication, marketing — with different rules and pricing per type. Source: official Meta documentation, WhatsApp Business Messaging Policy, accessed September 14, 2026. The operational translation for agent design is direct: a WhatsApp agent is reactive by default, and any flow that needs to start the conversation has to be designed as an approved template before you write a line of code. The detail of what Meta allows and what it does not is in what Meta allows in a WhatsApp AI agent, and the commercial version of the case is in answering WhatsApp 24 hours a day.
Email has no platform to sanction you, but it has two constraints that bite just as hard: sender identity (if the agent replies from a generic address, response rate collapses; if it replies from a person's address, that person owns whatever it says) and threading (replying by starting a new thread breaks tracking on any process). Neither is technical, and both decide whether the channel works.
The decision table: four questions, one surface
The decision closes in one afternoon with four questions, in this order. The order matters: the first one kills half the options and the rest sharpen what is left.
- Who is the user and what do they have open when this work appears? Employee inside a system → that system. Team talking → Slack or Teams. Customer who already writes to you → their channel. Anonymous visitor → web chat. Nobody, because the work arrives on its own → email.
- How long can they wait before assuming they were abandoned? If the answer is seconds, the architecture has to return something before it finishes. If it is hours, you have budget to spare and you can spend it verifying better.
- What permissions does that surface force me to request, and how many of them do I actually need? If the minimum the surface allows is already more than the case justifies, that is a legitimate reason to change surface.
- When it fails, where is it written down? If there is no answer, either you build the persistence before launch or you pick another surface.
And one architecture rule that makes all of the above reversible: the agent is a service, the channel is a thin layer on top. If the logic — the steps, the conditions, the calls into your systems — lives inside your chat vendor's visual builder, changing surface is not moving, it is rebuilding. If it lives on your side, behind an input and output contract, moving the same agent from web to WhatsApp, or from its own tab to Teams, is days of work. That condition is what turns the surface decision into something you can correct when usage data contradicts you.
We start here, before the model and before the prompt: where the work is, who does it and what they have open at that moment. It is what sits underneath AI adoption for teams — because having AI in the company is not the same as the company using AI — and what gets built with enterprise AI infrastructure when the agent has to live inside systems that are already in production. The rest of the build — permissions, autonomy, memory, evals — is in building an AI agent that survives production.