A production RAG or agent feature in your product by Sevastian RakhimovA production RAG or agent feature in your product by Sevastian Rakhimov
A production RAG or agent feature in your productSevastian Rakhimov

Who this is for

You have a working product and you want an AI feature in it that is genuinely useful — a chat assistant that knows your data, retrieval over your own documents, an agent that does a multi-step job on its own.
You have probably already tried it. Someone wired an API call to a prompt, it was impressive for a week, and then the answers started being confidently wrong, nobody could explain why, and the bill got strange. That is the normal outcome, and it is not a model problem.

What I build

Retrieval that is actually about your data. Chunking and indexing chosen for your content rather than copied from a tutorial, hybrid search where pure vectors fail, reranking, and a strict rule that the model answers from what was retrieved instead of from memory. Most bad RAG is a retrieval problem wearing a generation costume.
Agents as explicit graphs. LangGraph, with named nodes, defined transitions, retries and fallbacks in one place. An agent that fails somewhere findable is an agent you can fix; a prompt in a while-loop is not.
Evaluation, before anything else ships. A reference set built from your real inputs, with a rubric, scored automatically on every prompt or model change. Without it there is no such thing as an improvement — only a change that feels better.
Observability. Every call traced end to end: what was retrieved, what was sent, what came back, what it cost, how long it took. When a customer says it went wrong on Tuesday, you can open Tuesday.
Cost that does not surprise you. Model routing so the cheap model does the easy work, caching for what does not need regenerating, and hard ceilings per user and per tenant.
Failure that is not a blank screen. Timeouts, malformed output, refusals, provider outages — each with defined, tested behaviour.

Why me

This is what I run in my own product. F/AI is an AI fitness trainer I co-founded and run as CTO: plan generation over each user's own training history, a computer-vision body scan, and a multimodal chat coach that can look at a photo of a gym machine and tell you what to do with it. 176,000+ messages have gone through the AI coach; the counter is public at fitgpt.pro/stats.
340,000+ people have used it. When the AI part misbehaves it is my inbox that fills up, which is a strong incentive to build the measurement first.

How we work

Fixed price against a written scope, after I have seen what you have and what the feature needs to do. I integrate into your codebase and your accounts — your API keys, your infrastructure. You get the evaluation set and the traces too, not just the feature, so you can tell whether the next change made it better without me.
FAQs

Starting at$3,400
Tags
Langfuse
LangGraph
OpenAI
Python
RAG
AI Agent Developer
AI Chatbot Developer
AI Engineer
Backend Engineer
LLM
Service provided by
Sevastian Rakhimov Tbilisi, Georgia
2
Followers
A production RAG or agent feature in your productSevastian Rakhimov
Starting at$3,400
Tags
Langfuse
LangGraph
OpenAI
Python
RAG
AI Agent Developer
AI Chatbot Developer
AI Engineer
Backend Engineer
LLM

Who this is for

You have a working product and you want an AI feature in it that is genuinely useful — a chat assistant that knows your data, retrieval over your own documents, an agent that does a multi-step job on its own.
You have probably already tried it. Someone wired an API call to a prompt, it was impressive for a week, and then the answers started being confidently wrong, nobody could explain why, and the bill got strange. That is the normal outcome, and it is not a model problem.

What I build

Retrieval that is actually about your data. Chunking and indexing chosen for your content rather than copied from a tutorial, hybrid search where pure vectors fail, reranking, and a strict rule that the model answers from what was retrieved instead of from memory. Most bad RAG is a retrieval problem wearing a generation costume.
Agents as explicit graphs. LangGraph, with named nodes, defined transitions, retries and fallbacks in one place. An agent that fails somewhere findable is an agent you can fix; a prompt in a while-loop is not.
Evaluation, before anything else ships. A reference set built from your real inputs, with a rubric, scored automatically on every prompt or model change. Without it there is no such thing as an improvement — only a change that feels better.
Observability. Every call traced end to end: what was retrieved, what was sent, what came back, what it cost, how long it took. When a customer says it went wrong on Tuesday, you can open Tuesday.
Cost that does not surprise you. Model routing so the cheap model does the easy work, caching for what does not need regenerating, and hard ceilings per user and per tenant.
Failure that is not a blank screen. Timeouts, malformed output, refusals, provider outages — each with defined, tested behaviour.

Why me

This is what I run in my own product. F/AI is an AI fitness trainer I co-founded and run as CTO: plan generation over each user's own training history, a computer-vision body scan, and a multimodal chat coach that can look at a photo of a gym machine and tell you what to do with it. 176,000+ messages have gone through the AI coach; the counter is public at fitgpt.pro/stats.
340,000+ people have used it. When the AI part misbehaves it is my inbox that fills up, which is a strong incentive to build the measurement first.

How we work

Fixed price against a written scope, after I have seen what you have and what the feature needs to do. I integrate into your codebase and your accounts — your API keys, your infrastructure. You get the evaluation set and the traces too, not just the feature, so you can tell whether the next change made it better without me.
FAQs

$3,400