Insights — Agents and tools
A useful agent is not a free agent.
The difference between an agent that works for you and a gadget that impresses rarely comes from the model you chose. It comes from what you allowed it to do, the tools you put in its box, and what you keep under human control. Here is our design doctrine.
01 — The problem
An agent without a frame takes expensive — and sometimes irreversible — initiatives.
An agent wired to your tools with broad access will eventually perform an action nobody validated: email a customer, edit a record, delete a file, trigger a payment. That is not a model quality issue, it is a scope issue.
So we start from the opposite of a demo: we first write down what the agent must not do, and we only widen access after observing its real behaviour in supervised production.
01Bound the tools, not just the instructions
Telling an agent “never delete anything” in its prompt protects nothing: a model is not a security mechanism. The only boundary that holds is a technical one.
Every tool exposed to an agent is therefore a narrow function with its own permission checks: read a document folder, read a customer order, create an email draft. Never a generic access to a whole database, never write access that bypasses application rules.
- One tool = one precise action, with its permission checks
- No direct database access: the agent goes through business APIs
- Credentials are the user's, never an administrator account's
- Strict separation between reading and writing
02Three levels of validation
Not all actions are equal. We classify every capability by risk, and the level of control follows.
- Automatic: reading, searching, computing, preparing a draft — with no effect on the real world
- Single confirmation: writing in an internal tool, sending to a colleague — the user sees and approves
- Double validation: customer commitment, accounting entry, deletion, external sending — approved by a second role, with a trace
03Log everything, because an agent must be able to explain itself
Every run records the question asked, the tools called, the data returned, the decision taken and the cost consumed. Without that journal, an incident becomes an impossible investigation and a customer complaint becomes indefensible.
The journal also improves the agent: it shows misunderstood requests, useless tools and steps the agent systematically fails. That is the raw material for tuning, and it is specific to your business.
04The use case that justifies an agent — and those that do not
An agent is justified when the task needs several steps, several sources and an intermediate decision: preparing a technical file from scattered documents, qualifying an incoming request, reconciling an order and an invoice, watching an indicator and alerting.
It is not justified where a simple rule does better and cheaper. An automatic send, a calculation, a sort: classic automation is faster, more predictable and free at runtime. We tell our clients so, even when it makes the project smaller.
- Choose an agent: several steps, several sources, an intermediate decision
- Choose automation: a stable rule, a clear trigger, no judgement
- Automate nothing: what commits a person or a relationship with no possible control
The architecture of a framed agent: sources, retrieval, bounded tools, execution journal and validation at the right level.
02 — Common questions
What we are asked before wiring an agent
Can the agent act without anyone approving?
Only on actions with no real-world effect: reading, searching, preparing a draft, computing. Any write or external send goes through validation, and high-impact actions require a traced second approval. That is not an optional setting: it is the condition for going to production.
Can sensitive data leak through the tools?
Each tool only sees what the user asking the question is themselves allowed to see. An agent launched by a salesperson cannot read an HR file restricted to management. Permissions are checked on every call, not once at connection time.
How long does a first production agent take?
Four to eight weeks for a closed scope and one business tool, tests included. The time goes into rules, permissions and the evaluation set, not the model: that is what separates a prototype from an agent your teams actually use.
Do you have an agent use case in mind?
Describe the task and the tools involved: we will tell you whether an agent is justified, what scope to give it, and what must stay under human control.