AI agents for business: where to start

An AI agent is not a smarter chatbot. It is software that takes a goal, reads your data, uses your tools and chains steps until it reaches an outcome: a ticket routed, an invoice entered, a follow-up drafted. Chosen well, it takes hours of repetitive work off a team. Framed badly, it produces plausible errors at high speed. The difference is not the model. It is the choice of the first workflow, the place left for humans and the way you measure. Here is how we start in 2026, in six weeks.

What an agent does well, and where it fails

Current language models, from Anthropic (Claude), OpenAI or Mistral, are very good at reading, summarising, classifying, extracting information from a document and writing a first draft. Connected to tools, they become agents: they query a CRM, search a document base, fill in a form, prepare an email.

Their weaknesses are well known, and they should be named on day one:

• Hallucination. A model can state something false with full confidence. On an open-ended task, that is unavoidable without verification.
• Prompt injection. A crafted document or email can carry instructions the agent may follow. It is the first risk in the OWASP Top 10 for LLM applications.
• Data leakage. What the agent reads can surface in what it writes, or end up with a model provider if contracts and hosting are not chosen carefully.
• Cost drift. An agent that loops, rereads the same document ten times or uses the largest model for everything quickly costs more than planned.

None of this rules agents out. All of it calls for an architecture where errors are expected, detected and caught.

Choosing the first workflow

The first agent should not be the most ambitious one. It should be the most measurable. We look for a workflow that is repetitive, frequent, rule-based and checkable, where a mistake costs little or is easy to undo.

A useful test: if you cannot write down on one page what a correct outcome looks like, the workflow is not ready for an agent.

Human in the loop, by levels

"Human in the loop" does not mean a person reviews everything forever. It means the level of autonomy depends on the risk of each action.

1. The agent proposes, a human decides. The agent prepares the draft, the classification or the entry. A person approves in one click. This is where almost all our projects start.
2. The agent acts, a human spot-checks. Once quality is measured, simple cases go through on their own. Uncertain cases, where the agent flags doubt, go to a human.
3. The agent acts alone within strict bounds. Only for reversible, logged actions with hard limits.

Irreversible actions (send, pay, delete, publish) stay behind human approval. That is not a temporary precaution; it is a design rule.

Data and tools

An agent is only as good as the information it receives. Three workstreams always come up.

• The document base. To answer from your documents, we use RAG: texts are split, indexed in a vector store (pgvector on PostgreSQL does the job well), and the agent retrieves the relevant passages before answering. Quality depends mostly on cleaning the documents: outdated versions, duplicates, contradictions.
• The tools. The agent acts through APIs or the Model Context Protocol (MCP), an open standard that describes the tools a model can call. Each tool gets the minimum rights: read-only until writing is actually needed.
• Hosting. Depending on data sensitivity, we pick a provider with a no-training commitment, EU hosting (Mistral offers this option), or a self-hosted open-weight model. GDPR applies as for any processing.

Measuring with evals

A successful demo proves nothing. What matters is the rate of correct outcomes on real cases. So we build an evaluation set (the "evals"): around a hundred cases drawn from history, with the expected answer. Every change to the prompt, the model or the tools is replayed against that set.

Evals answer three questions: is the agent reliable enough for this level of autonomy, does a new version do better or worse, and which kinds of cases cause trouble. Without them, every change is a bet.

In production, we add observability: every run is logged, with its steps, the tools called, the cost and the final decision. When a user reports an error, we can reproduce it.

Keeping costs under control

An agent's cost is mostly model calls, billed by the volume of text processed. It is steered with a few simple rules: a light model for simple steps (classify, extract) and a stronger one only for reasoning, caching of repeated context, a cap on steps and spend per task, and daily tracking. We set a per-task budget during the pilot; it becomes one of the criteria for scaling up.

A six-week path

Weeks 1 and 2: frame and measure today. Pick the workflow, write the definition of a correct outcome, gather around a hundred real cases and measure the time spent today. Decide the human-in-the-loop level and where the data will be hosted.

Weeks 3 and 4: build the pilot. A first agent connected to the real tools, read-only or in "propose" mode. Evals in place, logs on, a per-task budget. Iterate on the cases that fail.

Week 5: test with the team. The people who do the work today use the agent in real conditions. They approve, correct and report. Their feedback feeds the evaluation set.

Week 6: decide. Measured reliability, cost per task, time actually saved, team feedback. Three possible outcomes: extend autonomy, add a second workflow, or stop. Stopping is a legitimate result, and far cheaper than finding the problem six months later.

What to remember

Start small, measurable and reversible. Keep humans on the decisions that matter. Measure with evals, not demos. Give the agent minimum rights and a budget. And train the team that will work with it: an agent nobody knows how to supervise does not stay in production for long.