Service 03
Agents and tools wired to your real data
We build AI agents, automations and business applications that work on your real data, not on a flattering demo. The goal is not to add AI somewhere, it is to take repetitive work away from people who have better things to do. What leaves for a model provider and what stays with you is an architecture decision, taken during scoping and written down in plain terms.
Our approach
Why we work this way.
Most AI projects fail at the same point: the demo works, production does not. In between sit your real data, with their duplicates and their special cases; your tools, with their temperamental APIs; and your users, who ask for things nobody anticipated. So we start from the other end: one precise task, measured on your own cases, and a prototype we abandon without regret if it does not hold.
The same foundation serves business software. Back office, customer portal, tracking tool: these are ordinary applications, with users, permissions and data that must not be lost — and AI only steps in where it saves time. We would rather have a plain tool that runs every day than an impressive demo nobody opens the following month.
What it covers
The detail, item by item.
Agents and assistants on your data
A useful agent is one that knows your business. We wire it to your documents and your systems, and we bound what it is allowed to say and to do.
- Document retrieval (RAG) over your procedures, contracts, catalogues and archives
- Answering customers from validated information, with the source cited
- Qualifying inbound requests and routing them to the right person
- Assisted drafting: replies, meeting notes, proposals, from your own templates
- Extracting structured information from unstructured documents
Process automation
Before AI, there is often a plain automation that settles the problem for good. We start there when that is the case.
- Document handling: quotes, invoices, purchase orders, supporting documents
- Scheduled follow-ups, on rules you control
- An end to double entry between two tools that do not talk to each other
- Scheduled syncs, with error recovery and an alert when one fails
- Recurring reports produced and sent without anyone touching them
Business applications and internal SaaS
When no off-the-shelf product matches the way you work, a custom tool becomes worth it again — provided it stays small and does exactly what it is asked.
- Back office and management tools, shaped to your real processes
- Customer portal: case tracking, documents, exchanges
- Tracking dashboards fed by your data, with no manual export
- Roles, permissions and an audit log
- Importing what exists, including from the spreadsheets holding the place together
Integrations
We plug into what exists rather than replace it. A project that begins with “we would first have to change your CRM” is a project that will not land.
- CRM, ERP and invoicing tools
- Email, calendars and collaboration tools
- Existing databases and data warehouses
- Third-party APIs, webhooks, files dropped on a server
- Picking up in-house APIs, even poorly documented ones
Supervised production
An agent in production without supervision is an incident waiting its turn. Supervision is part of the delivery, not of an option.
- Structured logs: every decision is traceable and readable back
- Guardrails: a bounded scope of action, volume limits, irreversible actions forbidden
- Human takeover at the sensitive points, designed in from the start
- A set of cases drawn from your own activity, replayed on every change
- A correction loop: what fails in production goes back into the test cases
- Usage tracked, so that no consumption bill is ever a surprise
What you receive
Checkable, at the end of the engagement.
- A written scope: what the agent does, what it does not, and what it hands to a human
- The source code and the data with you, with all the access
- Structured logs that make every decision the agent takes traceable
- A set of test cases drawn from your activity, replayed on every change
- A data architecture note: what leaves your systems, for which service, and why
- An admin area to adjust rules, messages and lists without coming back to us
Process
How we proceed
Scoping on a real case
Together we pick one precise, frequent, measurable task rather than an “AI project” with no edges. We write down what counts as success, and what counts as an error — both, before starting.
A prototype evaluated on your data
A prototype runs on a sample of your real data and is judged on cases you chose, difficult ones included. If it does not hold, better to know then: it is the cheapest stage of the project.
Integration and guardrails
Connecting to your tools, permissions, action limits, human approval wherever an error would be expensive. Logs and test cases are written alongside the code, not afterwards.
Supervised go-live
Going live on a narrow scope, logs read back with you, corrections, then widening when the numbers from your own tracking justify it. Opening up gradually is not excessive caution: it is what lets you catch an error before it spreads.
Frequently asked questions
The questions that come back, and our answers.
- Does our data go to a model provider?
- It depends on the architecture chosen, and that is a decision, not a side effect. A model hosted at a provider receives what you send it: we then scope what is transmitted, what is filtered or anonymised, and what never leaves your systems. Other workloads run entirely on your own infrastructure, with open models, at the cost of a different result or a different price. We ask the question during scoping, we write the answer into an architecture note, and we promise no compliance and no certification that we do not hold.
- Can an agent get it wrong?
- Yes. A language model produces a plausible answer, not a verified one: denying that would be lying to you. The whole job is making the error rare, visible and inconsequential. Answers draw on your documents and cite their source, the scope of action is bounded, every irreversible operation goes through human approval, logs are readable back, and the cases that failed join the test set. A supervised agent gets corrected; an agent left alone drifts.
- Can we start from a narrow scope?
- That is what we recommend. One task, one department, a handful of users: the first scope exists to check that the gain is real, and it costs little compared with a full rollout that would then have to be undone. Widening is decided on observed results, not on an opening intention.
- Who owns the code?
- You do, along with the data and the access. The repository, the hosting and the accounts for the services used are in your name. We document the setup so another team can take the project over without us: that is the only serious proof that the work was done properly.
The other services
The same contact from end to end.
Tell us about your project
One email is enough.
Write to us in a few lines: your business, what you are trying to achieve, and the deadline that matters to you. We answer in English or in French, with a straight opinion — including when the honest answer is that another service, or none at all, would serve you better.