AI architect
AI architect and engineer: from architecture to a system in production
I design and ship AI systems in production: data, models, agents, MCP, security and cost. For CTOs and heads of engineering who want an architecture that holds, not another POC.
What an AI architect actually does
An AI architect holds together pieces that produce nothing on their own: your data, the right model for each task, agents that execute, a protocol to plug them into your tools (MCP), security and cost. The real work isn't picking the model of the month, it's making the whole thing run in production, against your constraints.
And I don't stop at the diagram. I design the architecture and I write the code that makes it run. That's what the role means here: one person who thinks the system through and ships it, with no blueprint handed off to a team that reinterprets it along the way.
- Data: where it lives, whether it's usable, what to clean up before writing any code.
- Models: the right model per task (Claude, GPT, open-source), decided on your data, not on the hype.
- Agents and MCP: agents that act in your tools, wired once, reusable with any model.
- Security: evals, guardrails and access control designed in from the start, not bolted on at the end.
- Cost: an LLM bill held by the architecture, not discovered at month's end.
Sovereign and on-prem architecture when data can't leave
For many organizations, data can't go to a third party. When that's the case, I design so nothing leaves: the model and the MCP server that acts on your tools run inside your perimeter, on an EU cloud or directly in your own infrastructure. The agent reads, decides and executes in place; neither your documents nor your queries travel anywhere else.
Sovereignty isn't about the logo on the invoice. Many models, including European ones, run on US clouds and fall back under the US Cloud Act. I check where the model and the connector actually run before advising you, and I move to on-prem or an EU cloud when your data requires it.
Evals, guardrails and observability from the design stage
The difference between a demo that impresses and a system that holds in production is what you wrap around the model. I put it in from the start, not once things have already drifted: evals that measure real quality before every release, guardrails that keep the agent in its lane, and observability to see what it does, what it costs and when quality slips.
And I test the system the way someone with bad intentions would, before it happens for real: prompt injection, data leakage, an agent pushed outside its scope. A production AI system is designed around how it fails, not only how it works.
Delivering an architecture, or delivering an operated system
A clean diagram isn't a system. Plenty of engagements stop at the diagram and a POC on a laptop; the real work starts after that. I deliver something that runs: deployed, monitored, documented, with incident recovery planned and handover organized.
Being solo is an asset here, not a limit. One person thinks the system through and operates it, the architecture is documented, the code is yours, and nothing locks you into me. You can take it back in-house or hand the next phase to someone else whenever you want: it's the opposite of a dependency.
My stack, without pointless name-dropping
I pick tools for your case, not for my habits. The list below isn't there to impress: these are the pieces I actually use, and each one solves a specific problem. If a simpler tool does the job, I take it; if custom work is warranted, I code it.
- Models: Claude, GPT, open-source models deployed privately (vLLM, Ollama).
- Agents and tools: MCP (fastmcp), LangGraph, tool use, webhooks.
- Data and RAG: Python, pgvector, Qdrant, embeddings, reranking.
- Automation: n8n when it's the right level, custom code when the logic outgrows it.
- Deployment: Docker, Terraform, EU cloud or your own (AWS, GCP, Azure, Vercel).
- Reliability: evals (Promptfoo), observability (Logfire, LangSmith), traces and alerts.
What I've already built
A few real systems, described by the work and not the client (I name no one and invent no figures): an MCP infrastructure that gives agents access to internal tools without opening a hole, behind a Zero Trust proxy and SSO; a three-engine anomaly detection system, explained and prioritized by agents orchestrated with LangGraph.
On the knowledge and observability side: an end-to-end RAG chain feeding an internal assistant, kept continuously in sync with the code; and a log-ingestion filter that calls an LLM on the fly to catch anomalies the moment they arrive, as structured JSON. The details are on the dedicated page.
Do you code, or just make slides?
I code. I design the architecture and write the system that runs it: agents, RAG, MCP connectors, workflows, deployment. The diagram is there to make decisions, not to bill a deliverable that stops there. If you only need an audit or a scoping study, that's possible too, but my job is shipping software to production.
How does an engagement work, and what's your rate?
It depends on scope and mode (fixed-price project, time and materials, team reinforcement). I give an order of magnitude on the first call, free, once the need is scoped. I'd rather be straight about budget early than discover a mismatch at the end.
Do you work remotely? Outside France?
Yes. I work remotely for clients in France and across the EU, with regular check-ins and on-site time when it helps. I'm an independent based in France, which keeps contracting and invoicing simple within the EU.
Who owns the code and the architecture?
You do. The code, the documented architecture and the access are yours, with no dependency on me or on a single vendor. Choosing MCP goes the same way: you can switch models or take the next phase in-house without rewiring everything.
Can you join an existing team as reinforcement?
Yes, often. I fit in with your developers and your engineering lead, take on the AI side (architecture, agents, evals, security) and hand over as I go so the team stays autonomous after me. I can also pick up an AI system you've already started and move it from demo to production.
AI architect or AI engineer: what's the difference in your case?
In large organizations one draws and another builds. Being solo, I do both, and that's the point: the person who decides the architecture is the one who writes and maintains it, so nothing gets lost between the blueprint and production.
Contact
Ready to go from demo to production?
Reply within 24 hours · first conversation free, no strings attached.