What I do
I build AI systems that hold up on real data and real workflows: retrieval you can check, agents that finish the job, and the evaluation that tells you when either is wrong.
01 · RAG & document intelligence
Answers you can trace to the source
Most RAG breaks on real documents. Tables get flattened, scans lose their layout, and the answer comes back with a page number at best. After the first wrong answer, people stop trusting it.
Getting it right
- Retrieval that keeps layout (tables, figures, stamps), not only extracted text
- Citations people can check: the page and the region
- Retrieval quality measured on real questions, not demo ones
- Refusing when the evidence isn't there
What I build
- Question answering over large document collections
- Search across contracts, filings and reports
- Field extraction from scanned documents, linked to the source
- Knowledge assistants grounded in internal documentation
Proof
Typical stack
ColPali · pgvector · Neo4j · bge-m3 · cross-encoder rerankers · LangGraph · FastAPI · Gemini / Claude / OpenAI
Questions
Does this work with scanned PDFs and tables?
Yes. Atlas retrieves over page images rather than OCR text, so tables, figures and stamps survive retrieval, and the citation is drawn on the original page.
How does someone verify an answer?
Every claim carries a citation to the page and region it came from. A verifier re-checks each claim against its cited page before the answer is shown.
Can it run without sending documents to a third party?
Yes. Embedding and generation models can be self-hosted. The Atlas architecture notes document the move to a private GPU for confidential documents.
02 · Agents & multi-step workflows
Agents that finish multi-step work
Agents look great in a demo, then loop, skip steps or act on a wrong guess once real inputs arrive. The fix is rarely a better prompt. It's structure.
Getting it right
- Deterministic code for every step that doesn't need judgment
- Explicit steps and state, so every run can be inspected and resumed
- Checks between steps, and a human approval where a mistake is expensive
- Budgets on retries and spend
What I build
- Pipelines that plan, retrieve, act and verify
- Agents that operate across existing tools and APIs
- Human review queues for low-confidence cases
- Multi-agent systems where one agent checks another
Proof
Typical stack
LangGraph · CrewAI · AutoGen · Google ADK · Redis · Postgres · OpenTelemetry
Questions
When is an agent framework worth it?
When the flow has loops, checkpoints or approval gates. For a fixed sequence of steps, plain functions are simpler and easier to test.
Where should a human be in the loop?
At actions that are expensive to undo, and wherever the system's own checks say it isn't confident.
03 · AI reliability & evaluation
Know when your AI is wrong
It's easy to see what an AI system did. It's much harder to say whether it was right. Without evaluation, every prompt change is a guess and regressions are found by users.
Getting it right
- Evaluation sets built from real failures, run on every change
- Narrow, checkable questions instead of one vague quality score
- Verification gates that stop bad outputs before anyone sees them
- Tracing and cost per request, so failures and spend are visible
What I build
- Evaluation harnesses and regression suites
- Model-graded checks with explicit thresholds
- Verification and refusal gates
- Observability: traces, cost ledgers, budget guards
Proof
Typical stack
Langfuse · OpenTelemetry · Prometheus / Grafana · pytest · TypeSafe · custom harnesses
Questions
Rules or a model as the judge?
Both. Code checks what can be checked deterministically, a model handles judgment, and each has its own threshold.
How big does an evaluation set need to be?
Start small and real: a few dozen labelled cases drawn from actual failures already catch regressions. Grow it every time a new failure appears.
04 · MCP & tool integrations
Connect AI to the systems you already run
An assistant that can't reach your tools can only talk. One that can reach them needs clear limits on what it's allowed to do.
Getting it right
- Tools designed around real tasks, not raw API endpoints
- Authentication and scoped permissions per tool
- An audit trail for every action an agent takes
- Built on existing APIs, without a rebuild
What I build
- MCP servers that expose internal APIs and data
- Tool layers for agents, with permission scopes
- Integrations with enterprise APIs and internal tooling
Typical stack
MCP (Python / TypeScript SDKs) · FastAPI · OAuth · Docker · GCP / AWS / Azure
Questions
MCP or plain function calling?
MCP when several AI clients need the same tools. Plain function calling when a single application owns them.
How I approach it
- 01
Understand
The problem, the data and what a wrong answer costs, before choosing any model or framework.
- 02
Thin slice
One narrow path working end to end on real inputs, early.
- 03
Measure
Evaluate on real cases. Decide with numbers, not demos.
- 04
Harden
Failure handling, tracing, cost limits and documentation.