Do we need to train a model on our data?

Rarely. In most cases, good retrieval and a well-built context are enough, at a fraction of the cost and time. I am not a data scientist and I do not train models: what I bring is the integration architecture.

Do you work with one particular provider?

No. The choice depends on your data, confidentiality constraints, expected latency and cost. I design integrations so the provider stays replaceable.

Can our data stay confidential?

That is a design constraint, not an option bolted on later. Isolation, permissions, logging and hosting choices are settled at architecture time, against your actual requirements.

How long have you worked on this?

AI is a recent extension of my work, not fifteen years of practice. My fifteen years are in development, architecture and production delivery of software systems, industrial ones included. That is precisely what most stalled AI projects are missing when they try to reach production.

AI & Agents

Bring AI into your existing systems

AI agents, RAG, MCP and LLM integration: I design and connect AI capabilities to the applications, data and business tools you already run.

Let’s talk about your use case See the AI engagements

The model is not the hard part

Wiring an LLM into a demo interface takes an afternoon. Making it hold inside a real system means handling access rights, answer quality, failure modes, traceability, cost and day-to-day operation. That is where projects stall.

An AI proof of concept is easy. Integrating it reliably into a real information system is a software architecture problem. That is precisely what I have done for fifteen years.

User
employee, customer or operator
Application or copilot
your product, your interface
AI orchestration
context, routing, usage policies
LLM or agent
reasoning and tool selection
Tools, MCP, APIs
exposed actions, with their permissions
Systems, data, business services
your databases, your APIs, your documents

The chain runs from the user down to your existing systems. Most of the work sits between the model and your systems, not in picking the model.

What I actually do

AI inside an existing product

You already have an application or a SaaS. I add AI capabilities inside the product and wire them to the backend and data already in place.

A read of the existing product and where AI genuinely fits
Connection to the backend, the APIs and the data model
Respect for the permissions and isolation you already enforce
Integration into the existing user journey, not a parallel interface

RAG and knowledge bases

Letting the model draw on your documentation, business data and internal documents rather than on what it thinks it knows.

Indexing, content chunking and embedding choices
Relevant retrieval and answers that cite their sources
Permission-aware retrieval: each person queries only what they may read
Answer quality measured before and after going live

Agents and orchestration

Agents that can reason about a task, pick a tool, call your services and chain actions, asking for approval when the stakes justify it.

Task decomposition and an explicit boundary on autonomy
Tool selection and action chaining
Human approval on sensitive or irreversible operations
Defined behaviour on failure, uncertainty or looping

MCP and tool calling

Exposing your APIs, internal tools and business services to an assistant or an agent, under control. The protocol matters less than what you allow and what you log.

An inventory of actions to expose, and of those to keep closed
Tool contracts that are readable, testable and versioned
Data access through the application layer, never directly
Call logging and rate limits

Production architecture

The difference between a successful demo and a service you can operate comes down to ordinary engineering concerns.

Authentication, authorisation, secrets and isolation
Guardrails, answer evaluation and audit logs
Observability, tracing and cost tracking per usage
Fallback, rate limiting, resilience and fit with your CI/CD

AI engagements

Short formats, so you can decide on evidence rather than on a slide deck.

AI opportunity audit
1 day
An analysis of processes, systems and data to identify which AI use cases are genuinely worth pursuing, and whether they are feasible.
Deliverable: Prioritised use cases, feasibility and technical prerequisites.
AI architecture review
1 to 2 days
An audit of an existing LLM, RAG or agent architecture: answer quality, security, cost, observability and readiness for production.
Deliverable: Breaking points identified and a route to production.
AI integration POC
3 to 5 days
A working prototype connected to a real application, documents, APIs or business tools, so you can decide on evidence.
Deliverable: A runnable prototype and a target architecture note.
MCP connector or agent tooling
2 to 5 days
Exposing your APIs and business services to an assistant or an agent, safely, with the permissions and limits that go with it.
Deliverable: A working connector, documented and tested.

These can continue into development, architecture or team support when the subject justifies it.

Evidence rather than a promise

Chegou is a product I design and build myself: a PWA that helps foreigners in France deal with administrative procedures. AI reads administrative letters, answers questions in context, drafts correspondence and generates an action plan, all backed by a real backend, real permissions and a real cost model. It is the most direct example of what this page describes.

See the Chegou project

Frequently asked questions

Do we need to train a model on our data?
Rarely. In most cases, good retrieval and a well-built context are enough, at a fraction of the cost and time. I am not a data scientist and I do not train models: what I bring is the integration architecture.
Do you work with one particular provider?
No. The choice depends on your data, confidentiality constraints, expected latency and cost. I design integrations so the provider stays replaceable.
Can our data stay confidential?
That is a design constraint, not an option bolted on later. Isolation, permissions, logging and hosting choices are settled at architecture time, against your actual requirements.
How long have you worked on this?
AI is a recent extension of my work, not fifteen years of practice. My fifteen years are in development, architecture and production delivery of software systems, industrial ones included. That is precisely what most stalled AI projects are missing when they try to reach production.

Let’s talk about your AI use case

Thirty minutes is usually enough to separate what is feasible from what is not, yet.

Get in touch