AI & LLM engineering
Agentic systems and retrieval pipelines that hold up outside a demo.
How I approach it
Most LLM projects do not fail at the model. They fail at retrieval, at evaluation, or at cost — three problems that only appear once real users ask questions the demo never covered.
So the work usually starts with measurement rather than architecture. If there is no way to tell whether a change made the system better, every subsequent decision is a guess, and the guesses compound until nobody can explain why last month's version felt sharper.
Where the deployment cannot reach a cloud at all — a wearable, a device with a power budget measured in days — the constraint moves inference on-device and decides the architecture before any product question does.
What this covers
- Agentic architectures and multi-step tool-using workflows
- Retrieval: chunking, embeddings, vector stores, and the quality of what comes back
- On-device and power-efficient models where the cloud is not an option
- Evaluation harnesses, so a change can be shown to be an improvement
What you get
- A working system in your repository, not a notebook
- An evaluation harness you can run yourself after I am gone
- Honest numbers on latency and cost per request
- Documentation of what was tried and rejected, so it is not retried later
Relevant work
Other services
Need this on a project?
Describe what you are building and where it is stuck. The scoping call costs nothing, and you get a written scope and price before any work starts.