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 work directly with you on architecture and implementation. Scope, responsibilities, and any additional contributors are agreed before an engagement starts.
- 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.
Employment history is professional background. My independent services are separate; employers do not sponsor or endorse them.
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.
About In Time TecGlobal AI & software partner
A global technology partner trusted by enterprise clients across the US, built on a rare promise: ROI, or they don't get paid.
- 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
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
I work remotely with international teams. We agree on collaboration hours and communication before the engagement starts.
Independent consulting and project work, scoped directly with you. My employment history is professional background and does not imply employer involvement or endorsement.
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
Scope agreed first · 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
Milestones agreed together
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
Support by agreement
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.