Deploying an AI agent in your company, step by step

First of all: what decides success

An agent rarely fails for technical reasons. It fails because it was given a badly chosen task, or because nobody decided what it was not allowed to say. Both are settled before the first line of code, and this is exactly what separates a successful deployment from a project that stalls after a few weeks of real use.

So the opening question is not "which model should we use", but: which question are we asked forty times a day, and what happens if the answer is wrong? This shift in focus completely changes how the project is approached. It is no longer about choosing a technology first, it is about starting from an observed, concrete, already repeated need, and building the agent only around that precise need. Everything else, including the choice of model, follows naturally from that first decision.

An agent is not a search engine

The most frequent confusion is treating the agent like an internal search engine, capable of finding any piece of information in any document. That is not its role. A well scoped agent answers a set of precise questions, identified in advance, with material prepared for it. Outside that scope, its best answer is still to hand the visitor over to a human, rather than attempt an approximate answer that sounds right without being right.

1. Scoping and collection

We identify the task, then gather the material that already holds the answers: documentation, programme, catalogue, procedures, question history. That material almost always exists. It is simply out of reach for the person at the moment they ask the question, scattered across several files, several people, or several formats nobody ever took the time to bring together in one place.

This is also the moment when the list of forbidden subjects is written. It is shorter than people expect, and more important than the rest. An agent that knows precisely what it must never address, never promise and never make up inspires more trust than an agent that answers everything without distinction. This list is built by observing the questions actually asked, including the trickiest ones, rather than by guessing in advance what might cause a problem.

Where the material comes from

In practice, this material is rarely found in a single document. It is spread across the existing site, the answers already given by phone or by message, internal notes written to train a new hire, and sometimes the memory of a single person who knows the trade by heart. Gathering this material in one place, in a usable form, is often the longest step of scoping, and also the most useful: it serves the agent, but it also serves the whole team.

2. Configuring the agent

The agent is built on that material, not on general knowledge. We define what it may assert, what it must hand over to a human, and above all what it is not allowed to produce itself: prices, availability, contractual commitments. Those values will be calculated by the server, never written by the model. This separation, between what the model can freely phrase and what must come from a verified source, is probably the single most decisive configuration choice for the agent's reliability.

3. Personalisation

Visual identity, tone, in-house phrasing, and the exit points: at what moment does the agent offer to take a message, to call, to book an appointment. An agent with no exit point answers well and serves no purpose. The exit point turns a conversation into a concrete action, and this detail is often what separates an agent that entertains from an agent that produces a measurable result for the company.

Tone as a strategic choice

The tone the agent adopts deserves particular attention. A phrasing that is too formal can create distance with an audience used to a direct exchange; a phrasing that is too casual can, on the contrary, hurt credibility on sensitive subjects. The right setting is rarely found on the first try: it gets adjusted over the course of the first real conversations, once the agent is live.

4. Integration

The agent is placed on the pages where the question arises, not only on the home page. On a twenty page site, that means twenty pages. It is an integration detail that doubles the volume of use. A visitor with a precise question on a precise page will not necessarily go looking for the agent elsewhere: if it is not where the question comes up, the opportunity is lost.

The guardrail set here

Quotas per visitor per day, conversations stored outside the web root with a short retention, and a server filter that reads back every answer before display. These three things are put in place at deployment, not after the first incident. They fall directly under our approach to responsible AI: an agent open to the public must be governed from the moment it goes live, not only corrected afterward.

5. Testing in real conditions

We replay the real questions, including the ones outside the scope, the ones fishing for a price, and the ones asked in another language. We check that the refusal is clean: an agent that says "I do not know, here is who to contact" is worth more than an agent that improvises. This testing step must be demanding, almost adversarial: it is better to find the weaknesses during testing than the day after launch, in front of a real visitor.

What we try to break

A good test does not just check that the agent answers the expected questions correctly. It actively tries to push it outside its scope: ambiguous questions, the same question asked with different phrasing, attempts to extract information it is not allowed to give. This phase, often underrated, is what reveals whether the guardrails set earlier actually hold, or only work on paper. It also builds confidence for everyone involved: once the team has seen the agent handle the hardest cases cleanly, they trust it to be put in front of real visitors.

6. Live monitoring

The first days are the most instructive. We read the real conversations, spot the questions the agent answers badly, and enrich the material as we go. An agent deployed and left alone degrades; an agent watched during the first week gets markedly better. This close follow up also helps spot unexpected uses, questions nobody anticipated during scoping, which sometimes reveal a broader need than the one identified at the start, and can inform the next round of scoping long after the initial launch.

7. Report and debrief

What was asked, what was absorbed, what was handed over to a human, and what needs to change. That document is what says whether the agent deserves to be extended, reduced, or stopped. This report is not a simple formal summary: it is the basis for the next decision, whether to add a new scope, to narrow the subjects covered, or to conclude that the automated task was not the right one after all.

Checks before going live

• Has the list of forbidden subjects been reviewed by someone who knows the trade, not only by the technical team?
• Is every piece of sensitive data shown by the agent recalculated by the server, or could it be improvised by the model?
• Has the agent been tested in a language other than the one expected by default, in case a visitor writes differently?
• Does the exit point offered by the agent, a message, a call or an appointment, match an action the team is ready to handle afterward?
• Who, precisely, will read the first conversations once the agent goes live?

Common mistakes when deploying

• Choosing the model before identifying the task and the material available. The technical choice should come last, not first.
• Letting the agent generate sensitive information itself, such as a price or an availability, instead of having the server calculate it.
• Installing the agent only on the home page, when the questions actually arise on specific pages spread across the whole site.
• Putting the agent live without having defined the list of forbidden subjects, thinking it can be fixed afterward.
• Dropping the monitoring after the first week, when that period is precisely the richest source of learning.

Questions to ask before deploying an agent

• Which question comes up most often, and does the material to answer it already exist somewhere?
• Which subjects is the agent, under no circumstance, allowed to address or decide on its own?
• Which sensitive data must be calculated by the server rather than written by the model?
• On which precise pages of the site does the question actually arise?
• Who, in the team, will read the conversations from the first days and enrich the material as it goes?

Asking these questions upfront, during an assessment, allows the project to be scoped before development is committed, and avoids discovering too late that an agent answers a badly chosen task.

How long it takes

That depends entirely on the scope and on the state of the available material. We prefer to announce a lead time after scoping rather than before having looked. What we can say: the first version arrives sooner than expected and does less than was asked, because we narrow the scope before extending it.

This approach follows directly from our method described on the AI agent page, and relies on the same principles presented in our use cases. If your team is still hesitant about the scope to give a first agent, an engagement can scope the project before committing to a disproportionate development effort.

Frequently asked questions

Where does an AI agent deployment start?

With scoping: identifying the repetitive task, gathering the material that already holds the answers, and writing the list of what the agent is not allowed to say. The choice of model comes much later.

Which pages should the agent be installed on?

All the ones where the question arises, not just the home page. That integration detail doubles the volume of use.

What should be monitored after go live?

The real conversations of the first days. They reveal the questions the agent answers badly, and allow the material to be enriched. An agent left alone degrades.

How long does a deployment take?

It depends on the scope and on the state of the existing documentation. The lead time is announced after scoping, never before. The first version deliberately does less than was asked.