AI agents

How to deploy an AI agent in a company

Most first agent projects stumble on the same step: a model was chosen before a task was. Here is the reverse order, the one that leads to a tool still in service a year later.

By Wake Systems··9 min read

Choosing the model takes ten minutes of the project

The first decision is not technical. It is naming one precise task, and only one, that the agent will take on end to end. Everything follows from it: the budget, the schedule, and the very possibility of saying whether the result is good.

Companies that succeed with their first deployment almost always pick the same kind of task: repetitive, high-volume work that several people do the same way, and whose result can be verified in seconds.

Projects aiming at "an assistant that helps the team" almost never fail for technical reasons. They fail because nobody can say, three months in, what the agent actually produced.

A simple rule settles it: if you cannot describe the task in one sentence containing a trigger, an action and a result, it is not ready to be handed to an agent.

Four conditions, checkable in one meeting

Four conditions can be checked before committing to anything. When they are met, deployment is short. When one is missing, the project starts by filling that gap, and that is already useful work.

  • Volume. Multiply the unit time of the task by its real frequency. If the total is counted in working days per month, an agent earns its place. If it is counted in hours, look elsewhere.
  • Repeatability. Two people handle the same case the same way. If that is not true, the shared rule has to be written first.
  • Verifiability. Someone can say within seconds whether the result is good.
  • Access to the material. The necessary information exists somewhere and can be read.

A fifth, non-quantitative criterion weighs as much as the others: tedium. A task nobody wants is always done poorly at the end of the day. Handing it to an agent improves quality as much as speed, and the team welcomes the project instead of resisting it.

Real cases beat pages of instructions

This is the step most often skipped, and it is what separates agents that stay in service from those unplugged after a month.

An evaluation set is a list of real cases, together with the answer that was given and judged good. It is built in a few hours from a mailbox or a ticket history, and a few dozen cases are enough.

Its first use is measurement. The agent handles those cases, its answers are compared to the reference ones, and you get an agreement rate. Without that figure, an agent's quality is debated in meetings, each person citing the example that struck them, and the discussion never concludes.

Its second use is more unexpected. Reading back handled cases almost always surfaces a consistent practice no procedure ever mentioned, and sometimes two ways of handling the same case depending on the person. Those gaps are settled once, and the benefit exceeds that of the automation.

An instruction describes an intention; an example shows a result. Between "reply professionally" and a series of replies actually sent by your best handler, the gap in precision is considerable.

The material to gather around it

A recent model can read, write, classify and reason. What it does not know is your company: your ranges, your commercial exceptions, your real lead times, the reason that one customer is handled separately.

That material already exists, scattered across shared folders, mailboxes and the memory of two or three people. The work is to gather it, not to invent it.

  • Reference documents: catalogue, terms and conditions, price lists, procedures.
  • Decision rules: what is accepted, what is refused, what must go to a human. Two accurate pages beat twenty approximate ones.
  • In-house vocabulary: abbreviations, range names, the terms your customers use.

On our projects this preparation accounts for most of the schedule, and it falls mainly on the business side. It is a real workload, and it is also what later serves to train new joiners.

If you are still unsure which kind of tool you need: AI agent, chatbot or automation, which one for which need

One to two weeks, in order

On a well-bounded scope, a deployment fits into one to two weeks, and development is not the longest part.

  • Framing: describe the task as you would explain it to a new hire, gather the documents, launch the access requests. One day.
  • The evaluation set: extract real cases and their correct answers. A few hours.
  • Building and tuning, until the agreed level is reached.
  • Parallel running: the agent handles the same cases as the team, sending nothing. You compare.
  • Go-live, with systematic human approval.

Access requests belong on day one. Getting read rights on a production system often involves people outside the project and regularly takes longer than the build itself.

Loosen in stages, never the reverse

An agent is deployed in autonomy stages, and the order is not negotiable: you can always loosen, you recover badly from lost trust.

  • Stage 1: the agent prepares, a human approves everything. The starting point, even when the measurements are excellent.
  • Stage 2: the agent handles the cases it judges simple and passes the others on with the context already gathered.
  • Stage 3: the agent handles most of the flow, with spot checks and a written escalation rule.

Moving from one stage to the next is decided on figures: an agreement rate measured over a sufficient volume of cases, and a stabilised list of escalation reasons.

Some categories stay permanently at stage 1, and that is a healthy choice: anything that commits the company legally, any dispute, any complaint. The agent still adds value there by assembling the file before a human steps in.

Four figures to watch

An agent without measurement becomes an opinion again, and an opinion gets unplugged at the first anomaly. Four indicators are enough, and they are set up with the agent, not afterwards.

  • Handling rate: the share of the flow taken on without intervention.
  • Agreement rate: on checked cases, the proportion where a human would have done the same.
  • Escalation reasons: why the agent passes a case on. The most useful of the four, because it tells you what to improve.
  • The delay between a request arriving and being handled, the one your customers feel.

Regular review is enough, and it explains why a followed agent keeps improving for months while one delivered and then left alone degrades as the company changes.

If you are looking for where to start, do not look for the most strategic task. Look for the most tedious one, the one nobody is asking for. The benefit is immediate, the team becomes an ally of the project, and you will have built along the way the evaluation set that serves every agent after it.