On a quiet afternoon, the same configuration closed a lost-card chat, talked a shopper through a Pro plan, and answered a sizing question for a hiking boot - and none of those visitors ever knew they were talking to one setup. An AI agent on a website is not one widget with one job. It is three jobs in the same box, and the box only works when the three stay in their lanes.
Sales
Sales is where the agent becomes a closer. The job is to answer pricing honestly, compare plans, and book a demo or push a shopper to checkout when the moment is right. The agent hands the warm lead to a human the second the question turns into a contract review.

Product guidance
Product guidance is the lane people forget to scope, and it is often the one that converts. The job is to help a visitor understand what they are looking at - features, fit, compatibility - using the catalog and the help docs as the source of truth. The three lanes share a brain, which is why the brand voice check matters. The training step is where I used to rush. On day one I would point the agent at the help docs and ship it. After the second wrong refund I started treating the training pass like a real job: connect the data sources, set the guardrails, then write instructions the agent can act on. The data sources are the easy half. I connect the catalog, the returns policy, and the shipping page first, because those answer most chats before a human ever sees them. I keep the variables verified so the agent reads live inventory instead of a stale PDF. The instructions are the half I keep rewriting - short, plain, with the escalation rule on every line. The guardrails are what I write first now, before the agent ever sees a visitor. The escalation rule sits at the top: any refund over a set dollar amount goes to a human, no exceptions. The brand voice rules sit next - short sentences, no jargon, no promises about shipping that the help docs do not back up. Then the channel list: chat, email, WhatsApp, the same set of rules written once. I edit those guardrails in the place the platform gives me, not in a prompt the engineering team has to redeploy. That single change - guardrails in the UI, not in code - is what stopped the second wrong refund. The data sources I wire up first, in order:
- The catalog, with live inventory and verified variables, so a sizing answer is not a guess from last quarter.
- The returns policy, the page a refund chat will quote, because a wrong quote costs more than a slow one.
- The shipping page, the one that answers "where is my package" before a human ever sees the chat.
- The help docs, layered in after the first three, because the catalog and policy already cover most of the traffic. The instructions I wish I'd written on day one are four lines, not a manual. State the agent's lane on the first line. State the escalation rule on the second. State the brand voice in one sentence on the third. State the data source the agent should trust on the fourth. Every instruction after that is an example, not a rule, because examples drift and rules hold. That is the file I rewrite the most, and it is the file the agent reads the loudest. I ran real customer scenarios through the agent before it touched a live visitor. Edge cases came first - the lost card, the duplicate order, the angry refund - because those break the brand voice faster than any happy-path chat. Then I read every reply aloud, line by line, until it sounded like the person who answers our tickets on a Tuesday afternoon.
Support
Support is where the agent earns trust or loses it. The job is to resolve real problems - damaged orders, refund status, account changes, the "where is my package" chat that lands late. Speed matters, but accuracy matters more. A wrong refund is louder than a slow one.

The first week is not the launch. The first week is the tuning. I watched the resolution rate the way I would watch a new hire on their first shift, and I did not touch the shipping button until the numbers stopped moving on their own. Resolution rate is the metric I check first, every morning, before coffee. It tells me how many chats the agent closed without a human stepping in. A steady climb in the first five days meant the guardrails were holding and the catalog was answering most of the questions. A flat line on day three meant a gap in the help docs, and I wrote the missing line that afternoon. The number I cared about was not the percentage itself but the shape of the curve - climbing, flat, or dipping. Dipping meant I had broken something with a Tuesday edit, and I rolled it back before lunch. Escalations are the second number, and they tell a different story. An escalation is not a failure. It is the agent reading the rule and getting out of the way, which is the whole point. I tracked the reason tag on every handoff: refund over the dollar limit, contract review, angry tone, lost card. The tags told me where the rules were right and where the rules were too tight. A spike in the angry-tone tag on day four meant the brand voice was slipping, so I rewrote the third line of the instructions and watched the tag fall the next day. A spike in the contract-review tag meant sales was sending the wrong stage of shopper to the agent, which was a routing problem on my end, not the agent's. The first week I tuned instead of shipped. I read the transcripts the way I read a draft of my own writing, looking for the sentence that sounded almost right but not quite. I rewrote that sentence. I reran the same scenario and checked the reply. I did not add a new feature, did not connect a new channel, did not push a campaign. The only thing I changed was the instruction that the agent was already misreading, and I changed it in the UI, not in code. That single habit - tuning in the UI, one rule at a time, until the curve settled - is what carried the launch into week two without a rollback. I also kept a short list of the chats I would have answered differently, and I read that list on day seven. It was longer than I wanted, shorter than I feared, and every line on it became a guardrail the next Monday. Tuning is just that loop, written down, run on purpose, and stopped before it turns into a second launch. The agent is live. The inbox is quieter. The numbers are mine to watch, and the rule I keep coming back to is simple: tune in the UI, one rule at a time, and stop before the loop becomes a second ship.