About
Business problem
first, model second.
An AI engineer and automation consultant building LLM agents, RAG pipelines, and voice systems that hold up in production, not just in demos. Every system starts from an operational problem and works backwards to the smallest architecture that removes it.
What I believe about this work
Demos are easy. Production is the job.
Most AI projects die between the notebook and the deploy. I build the part that survives: evaluation, fallbacks, observability, and robust systems that behave when real users show up.
Business problem first, model second.
Every system I ship starts from an operational pain: leads rotting in an inbox, support queues on fire, knowledge trapped in PDFs. I work backwards to the smallest architecture that removes it.
Full stack, end to end.
Agent orchestration in LangGraph, retrieval on hybrid search, FastAPI backends, and React frontends. One person owns the whole system, so nothing gets lost in the handoff.
The same loop,
every system.
Whether it is a job, a client engagement, or something shipped alone. The steps do not change; only how long each one takes.
I own the architecture and the build. When an engagement needs more implementation capacity than one person has, I bring in a small engineering and automation team I have worked with before, and stay accountable for what ships.
- 01
Understand
The real problem and its constraints, before touching a model or a framework. Output: a clear picture of what production actually requires.
- 02
Design
System architecture, model choices, and data flow, thought through and written down before any code.
- 03
Build
Production-focused implementation in short iterations, tested early against real inputs, not synthetic ones.
- 04
Ship
Deployed, monitored, and documented. No black boxes and no handoff gaps.
- 05
Improve
Evaluated and tuned after launch. Systems get better in production, not worse.
Experience
Enterprise exposure,to product, to AI.
Five roles, each a different part of the same progression: understanding how enterprise systems get built, learning to think in products, then engineering the AI systems themselves.
Builds production-grade Generative AI and Agentic AI systems for enterprise use, with the emphasis on systems that stay reliable under real load rather than experimental prototypes.
- Builds production Agentic AI and LLM applications with LangGraph and FastAPI
- Designs RAG architectures on LlamaIndex and Qdrant with hybrid search and grounded generation
- Engineers scalable AI agents on Python, Azure AI, and Redis with stateful workflow orchestration
- Implements AI safety and reliability mechanisms: PII masking, content safety, and jailbreak detection
- Improves production systems through observability and parallel execution
LangGraphFastAPILlamaIndexQdrantAzure AIRedisPython
Education
B.Tech, Computer Science
JK Lakshmipat University, Jaipur
High School Diploma, Physics, Chemistry, Mathematics
Delhi Public School, India
Middle School
St. Anselm's Pink City Sr. Sec. School
How I work with teams
Works remotely with teams in any time zone, with European and UK working hours covered as standard. Those systems run for users in 10+ countries.
Takes on full-time engineering roles and select contract or project engagements, remotely, in any time zone. Most of that work runs with teams in Europe, the UK, North America, and Australia. Where a company is hiring from abroad, project work runs as a consulting engagement rather than employment, with no local work authorisation required on either side.
How an engagement runs
Most engagements start with the audit, because a fixed, bounded first step is what makes a larger second step decidable. Nothing below is a package: the stages exist so you can picture the shape, and the scope is written down before either of us commits to it.
- 01
Audit
1 to 2 weeks · Usual starting point
A fixed-scope look at the workflow you want automated or the AI feature you want built: what the data actually looks like, which parts genuinely need a model, which parts are better off deterministic, and what production would cost to run.
You get
A written architecture and a build plan you own, whether or not the build happens with me. - 02
Build
4 to 12 weeks
Implementation in short iterations against real inputs, not synthetic ones. You see working software every week, and the architecture from the audit is the thing being built, so scope arguments happen on paper rather than in code.
You get
A deployed system, its evaluation harness, and documentation someone else on your team can pick up. - 03
Run
Monthly, cancel anytime
The part most AI projects skip. Models drift, prompts rot, upstream APIs change their output shape, and a pipeline that was accurate in month one is quietly wrong by month four unless someone is measuring it.
You get
Monitoring, evaluation runs, and a monthly note on what changed and what it cost.
What I do not take on
Four things that come up often enough to be worth saying out loud. None of them are judgements about the work itself; they are places where someone else will do a better job than I will.
- Model training from scratch
- Fine-tuning where it earns its place, yes. Pre-training a foundation model is a different discipline with a different budget, and anyone telling you it is the answer to a business problem is usually selling the training run.
- A chatbot with no system behind it
- Wrapping an API in a chat window takes an afternoon and solves nothing that lasts. The work worth paying for is the retrieval, the evaluation, and the operations around it, which is where the demos that never ship go wrong.
- Design-only or brand work
- The interfaces here are built to make the system legible, not to win a design award. If the deliverable is a brand system or a visual identity, you want a studio, and the build will be better for it.
- Staff augmentation by the hour
- Engagements are scoped to an outcome with a written architecture behind it. An open-ended seat on a backlog is a real service and a reasonable thing to buy; it is not this one.