AI API costs: how not to blow up your bill
4 min read
Key takeaways
- An agent acts on your systems: the risk is no longer a bad answer but a bad action.
- Start in proposal mode: the agent prepares, a human validates, for several weeks.
- Limit the tools available to the agent to the strict minimum, with read-only rights by default.
- Every irreversible action must go through explicit human validation.
- Log every decision: without traceability, no incident can be analysed.
An assistant that answers badly costs thirty seconds. An agent that acts badly sends an email to a customer, modifies an order, or triggers a reminder on a case that has already been settled.
The move from one to the other is a change of nature, not of degree. Here is how to make it without incident.
What an agent can really do today
An agent chains three capabilities: it understands a request in natural language, it chooses tools to call, and it evaluates the result to decide what comes next.
What works well in 2026:
- Qualification and routing: reading an incoming request, classifying it, enriching it, and directing it to the right queue with a summary.
- Case preparation: gathering information scattered across several systems and producing a summary ready for decision.
- Data reconciliation: comparing two sources, flagging discrepancies, proposing corrections.
- Conditional follow-ups: identifying pending cases, preparing the appropriate message, submitting it for validation.
What works poorly, and is best not attempted first: processes with fuzzy rules, those whose special cases are written down nowhere, and those where an error is not visible for several weeks.
The selection criterion: a good process for an agent is repetitive, its rules are known, and its errors are quickly detectable and recoverable. If any one of these four conditions is missing, keep a human in the loop on every action, at least to begin with.
The five essential safeguards
1. The principle of least privilege
The agent accesses only the tools strictly necessary for its process, with read-only rights by default. Each write capability is added explicitly, justified, and limited in scope.
An agent with general access to your information system is a vulnerability, whatever the quality of its instructions.
2. Separating proposal from execution
Every irreversible action (external sending, accounting change, deletion, contractual commitment) goes through human validation. Reversible, low-stakes actions can be automated once trust has been measured.
This boundary is written in black and white, in a document that the business teams validate. It is the most important document of the project.
3. The iteration cap
An agent that loops consumes budget and may repeat an action. Set a maximum number of steps per task, and a limit on calls per hour. This safeguard also protects the bill, as we explain in our article on API costs.
4. Full logging
Every decision, every tool called, every parameter, every result. Without this log, an incident cannot be analysed and trust cannot be rebuilt.
It is also what lets you answer the question management will inevitably ask: "why did it do that?"
5. The kill switch
A way to stop the agent immediately, known to several people, tested before going into production. It seems obvious; it is regularly missing.
The rollout method that avoids incidents
| Phase | Duration | Mode | What we measure |
|---|---|---|---|
| Observation | 2 weeks | The agent proposes, nothing is executed | Rate of correct proposals |
| Assistance | 4 weeks | A human validates each action | Rate of validation without correction |
| Partial autonomy | Ongoing | Automatic execution on safe categories | Error rate, incidents, rework |
| Extension | Gradual | New categories, one at a time | The same indicators, by category |
Moving from one phase to the next rests on a number, not on a feeling. Our reference threshold: 95% of validations without correction over at least two hundred cases, category by category. Below that, we stay in assistance mode and fix the instructions or the data.
95%Rate of validation without correction before any autonomy
200Minimum cases observed before deciding, per category
6 wksTypical time before the first automated action
The mistakes that cost a lot
Giving too many tools at once. An agent with twenty tools chooses badly and becomes impossible to debug. Three to five well-defined tools are better, and additions are made one at a time, measuring as you go.
Confusing autonomy with the absence of supervision. An agent that is autonomous on one category of actions remains monitored: indicators, manual sampling, weekly review. Autonomy applies to execution, never to oversight.
Automating a poorly defined process. If three people on the team handle the same case differently, there is no rule to automate. You first have to settle it, and that is organisational work, not engineering.
Neglecting the failure case. What does the agent do when information is missing, when a system is unavailable, when the request falls outside its scope? The default response must be "stop and report", never "do the best you can".
An agent in production is not judged on what it gets right, but on its behaviour when it does not know. An agent that stops and asks can be used; an agent that improvises never can.
Where to start
Choose one process, repetitive, with detectable errors, and deploy it in proposal mode. Six weeks later, you will have real figures rather than a theoretical debate about the reliability of AI.
It is the same logic as the one described in our article on choosing a first use case: starting small is not a lack of ambition, it is the only way to reach production.
Sources
- Recommandations de sécurité pour un système d’IA générative (in French) — ANSSI (France's national cybersecurity agency)
- LLM06:2025 Excessive Agency — OWASP Gen AI Security Project
