Website, WhatsApp, Slack, Teams or Jira: where your AI agent should actually live

Search for how to integrate an AI agent and the comparison pages all have the same shape. Five channels in a grid, ticks in most of the boxes, and a conclusion that happens to be the channel the author sells. None of them is lying, exactly. Each one is answering which channel is best when the question you actually have is which channel is best for these users, doing this work, and nobody selling one channel can answer that for you honestly.

I covered how each channel is built earlier this month, and the posts since then went deep on each of them. This one sits above all of that. It is the decision you make before any of it: where the agent should live, which in practice means where it should live first, because the second channel is always cheaper than the first and the wrong first channel is the most expensive mistake in the whole project.

Most teams choose by one of two methods. The channel the most senior person in the room uses, or the channel the demo looked best in. Both produce agents that work and that nobody opens after the second week. Three questions do better.

approval gates between you and launch on your own websiteand nobody to stop an unauthenticated endpoint spending money either

0

free WhatsApp service messages per business number per monthsince 1 October 2026, billable after that, undelivered without a card on file

1,000

Slack scopes a mention driven agent needs to startevery one added later goes back in front of a workspace admin

2

points an hour in Atlassian's default pool for a Jira appshared by every tenant you serve until you are moved to a per tenant tier

65,000

The decision table

Read across a row, not down a column. Each channel is a bundle of a user, a place and a bill, and the right channel is the row where all three match the people you are building for.

Question one: who is the user, and how sure are you

Start with the person, because the channel decides how well you know them and that decides what the agent is allowed to do for them. An agent that can only answer public questions can live anywhere. One that can look up an order, refund a payment or move a ticket can only live where you can tell who is asking.

That table explains most of the answers before you get to the others. A customer support agent for a B2B product belongs inside the signed in product, because that is the only place the agent knows which account it is talking to and what that account pays for. An anonymous visitor gets an agent on the marketing site you build and own, with public knowledge and a budget. A business whose customers already send it WhatsApp messages should meet them on WhatsApp, and should treat linking the phone to an account as the first feature rather than the last.

Employees are the easy case, because the company chose for you. If it runs Slack the agent goes in Slack, starting from the two scopes that are enough. If it runs Teams it goes in Teams, and if the agent already exists elsewhere it gets there through an adapter rather than a rewrite. An internal agent offered in the chat tool the company does not use has an adoption rate you can calculate in advance, and it is zero.

Question two: where is the work recorded

The second question is where people already are, and the obvious answer is wrong often enough to be worth slowing down for. People discuss work in chat. They record it somewhere else: a ticket, an order, a CRM record, a pull request. An agent that lives where work is discussed produces summaries. An agent that lives where work is recorded produces outcomes.

Engineering teams are the clearest example. The bug is discussed in a Slack thread, and the decision ends up as a status, an assignee and a comment on a Jira issue. Put the agent only in Slack and it writes an excellent summary of the thread that somebody then has to copy into Jira by hand, which is the job the agent was meant to remove. Put it in Jira, built on the REST API with the user's own permissions, and reachable by a mention from the Slack thread, and the summary becomes the comment, the status change and the assignee in one step. Since September an agent you build can also be assigned the work item directly, which is Atlassian making the same argument with a product.

The same rule applies outside engineering. A support team works in a helpdesk, so the agent drafts replies there rather than answering customers in a chat widget the support team cannot see. A sales team works in the CRM. A consumer business with customers on WhatsApp records the order in its own system, so the WhatsApp agent is a door into that system rather than a second place where orders half exist.

Question three: what does it cost once the demo is over

The model bill is roughly the same whichever channel the message arrived through. What differs is everything around it, and the part that surprises people is not the price of running the agent. It is the price of changing it after launch, because four of the five channels put somebody else's approval between you and the next release.

Then the running costs that do not show up in a prototype. On WhatsApp, Meta meters service replies past the free thousand and every template, and if there is no payment method on file the messages past the allowance are simply not delivered, which is covered with the error codes in the WhatsApp gotchas. On Jira, the points quota means an agent that re-reads the same issue on every turn is spending a shared budget. On your own website, the cost of an open endpoint is whatever somebody else decides to spend on it. Slack and Teams are the cheapest to run and the slowest to change permissions on, which suits internal agents that do a stable job.

The answers most teams land on

Run the three questions and the same handful of answers come out most of the time.

• A B2B SaaS support agent: inside the signed in product. The account is known, entitlements are readable, and nothing needs approving. Add Slack later for customers who live there, as a door into the same core.
• A consumer business whose customers message on WhatsApp: WhatsApp, with the website second. In Pakistan, the Gulf, India and much of Latin America that is where the customer already is, and a website widget is a detour. Budget for verification and templates from week one.
• An internal operations agent: whichever of Slack or Teams the company pays for. One of them, not both on day one. The second is a smaller project once the first is right.
• An engineering or support workflow agent: Jira, reachable from chat. The ticket is the record, so the tools and permissions belong there. The chat tool gets a mention and a reply.
• A public assistant for prospects: your own website. Public knowledge, a per session cap, a daily ceiling, and no tools that touch an account.
• All five: one core, then one adapter at a time. The adapter split in the channel by channel post is what makes the second channel cost a third of the first.

When the answer is more than one channel

It usually is, eventually. The sequencing that has worked for me is to build the first channel the questions above picked, with the core and adapter split from the first commit, and to start the paperwork for the second channel in the same week. Meta verification, a Teams tenant consent and an Atlassian review run on calendars you cannot compress, so the cheap way to have a second channel in month two is to have filed for it in week one. Slack before Teams when both are wanted, because Slack is the faster place to get the core right and Teams is where you want the waiting to happen while the code is finished.

What does not change between channels is the list in bounding an agent so it finishes the job: identity resolved before tools run, state the agent can rely on, idempotency on every inbound event, and an audit trail of what it did and as whom. Pick the channel well and those four are a week of work. Pick it badly and they are still a week of work, spent on an agent nobody opens.

The best channel for an agent is the one where you know who is asking and the work is already written down. Everything else is a door into it.

Tell me who your users are and what the agent has to get done for them, and I will tell you where it should live first, what the second channel costs, and which approval queue to join this week. That answer comes with a fixed scope and a fixed price. Start that conversation here, or see the engineering behind it on the AI capabilities page.