Des chatbots aux agents : déployer une IA qui fait un vrai travail

Every AI vendor demo this year shows an agent booking flights, refactoring codebases, or negotiating invoices. Almost none of those agents are in production. The gap between a working demo and a reliable agent is not model quality — it is everything around the model.

We have shipped agents that process thousands of operational tasks a week for clients, and we have also killed agent projects that should never have been started. This post is the checklist we wish we had on day one.

What makes an agent different from a chatbot

A chatbot responds. An agent acts: it plans a sequence of steps, calls tools, reads the results, and decides what to do next. That loop is exactly what makes agents valuable — and exactly what makes them hard. A wrong answer in a chat is annoying; a wrong action in a system of record is an incident.

The practical consequence: agent reliability is not measured by answer quality benchmarks. It is measured by task completion rate, action error rate, and time-to-detect when the loop goes off the rails. Define those three numbers before you write a single prompt.

The tooling layer is the product

In our experience, 70% of agent failures are tool failures, not reasoning failures. The model calls your API with a plausible-but-wrong parameter, the API accepts it, and the error surfaces three steps later. Tools need the same design discipline as public APIs — arguably more, because your primary consumer is a very confident intern.

• Validate every tool input with a schema at the boundary, and return machine-readable errors the model can recover from
• Make tools idempotent where possible, so a retried step cannot double-charge a customer
• Return compact, structured results — dumping a 5,000-row payload into context wastes money and degrades reasoning
• Give the agent a way to say 'I cannot do this' as a first-class outcome, not a failure

Guardrails: evaluation, permissions, and rollback

Treat the agent like a new junior employee with root access — then decide which of those permissions to actually grant. The pattern that works for us: a scoped permission set per workflow, a dry-run mode that logs intended actions for review, and hard blocks on irreversible operations above a defined value threshold.

Evaluation is the other half. Build a regression suite of real tasks — including the awkward ones — and run it on every prompt, tool, or model change. Agents drift in ways ordinary software does not: a model update can silently change how the agent formats a tool call. Without an eval suite, you will find out from your users.

Cost and latency: the silent killers

An agent that takes 40 seconds and 30,000 tokens per task is a demo, not a product. Track cost per completed task from day one — it is the number that decides whether the project survives budget review. Cache aggressively, keep context windows lean, and route simple steps to smaller models.

Latency matters even more for user-facing agents. Break the loop into visible steps and stream progress. Users forgive a 30-second task if they can see it working; they abandon a silent 8-second wait.

Start with one workflow, not a platform

The most expensive mistake we see is the 'agent platform' project: months of infrastructure before a single workflow ships. The teams that succeed pick one well-bounded, high-volume, low-blast-radius workflow — triaging inbound tickets, reconciling invoices, enriching CRM records — and ship it end to end.

One production workflow teaches you more about tooling, evaluation, and cost than any architecture diagram. Let the second workflow reuse what the first one proved. That is how an agent capability compounds — one workflow at a time.