Senior AI Engineer · Production agents
Bengaluru, India · IST
Your agent works in the demo. I make it work in production.
I build the layer around the model that production needs: MCP servers that connect it to your systems, evals that catch regressions, permissions that limit what it can touch, and tracing that shows what it did. Four of my agents run in enterprise production today.
- agents live in enterprise production
4
agents live in enterprise production
- production systems shipped
11
production systems shipped
- MCP servers & integrations built
7
MCP servers & integrations built
- AMD AI Sprint 2025 · IISc
1st
AMD AI Sprint 2025 · IISc
01Selected work
Shipped, not sketched.
Each system is shown the way an engineer would want to see it: the architecture, the boundary it runs inside, and what changed.
Also in production
02The short version
Most AI projects die between the demo and the on-call rotation.
A working prototype proves a model can do something once. It says nothing about what happens at 3am when the ticket is ambiguous, the logs are noisy, and the query times out on high cardinality.
That gap is the work I care about. Closing it means meeting systems where they already are, so I write the tool layer myself, including the MCP servers that let an agent reach an observability stack and a ticket queue reliably rather than approximately.
Every ticket, manually
3 manual searches
- Search for the right procedure
- Dig through the logs
- Search history for a similar case
- Actually fix it
Three searches happen before anyone touches the problem. Repeated on every ticket, at every hour of the night.
Every ticket, with the agent
0 manual searches
- Context already on the ticket
- Actually fix it
The engineer's first action is judgement instead of search. Nothing about the fix itself was automated.
3 → 0
manual searches before the engineer starts work
Bars are illustrative — they show the shape of the change, not a measurement.
03How I build
I build the harness, not just the agent.
A model is the easy part. What makes an agent useful in production is everything around it: the tools it can reach, the access it is given, the checkpoints it stops at and the evals that tell you it still works. Every system on this site was built the same way.
- 01how a person does it today
Understand the job
Before any model, I map the workflow: what triggers it, what a person looks at, which decisions they make, and what done looks like. If I cannot describe the human version, the agent will not get it right.
- 02tools → MCP
Give it the human's tools
The agent gets the same tools that person uses (logs, metrics, tickets, docs, the repo), exposed through MCP servers and narrow tool interfaces. When the tool does not exist, I write it.
- 03failure modes first
Ask how it goes wrong
Ambiguous input, noisy logs, the wrong tool, a confident answer with nothing behind it. I list the ways it can fail and design for those before adding features.
- 04least privilege
Set the blast radius
Read-only by default, allowlisted commands, tokens pinned to hosts, secrets the model never sees. The agent gets exactly the access the job needs.
- 05human checkpoints
Keep a person on the decision
Agents prepare and recommend. Anything irreversible (a merge, a deploy, a publish, a delete) waits for a human. That boundary is why these systems were allowed near production.
- 06evals + tracing
Evaluate, ship, watch
A test set before launch, regression runs on every change, tracing once it is live. What happens in production becomes the next round of evals.
Principles that hold across every system
Automate the toil, keep the judgement
I point agents at the work that is repetitive, boring and low-value for a person: hunting for the right procedure, assembling context, building and redeploying, formatting a post. If it can be automated, it should be. The decisions that need judgement stay with people.
Build on the systems that already exist
No rip-and-replace. I wrap what already runs (Grafana, Loki, Prometheus, ticket queues, Confluence, GitHub Actions, Notion) behind MCP servers and tool interfaces. When the server I needed did not exist, I wrote it.
Human in the loop by default
Every agent I have put into production prepares, recommends or proposes, and a person approves anything irreversible. The incident copilot posts a recommended fix and the SRE acts on it. Merges, deploys and published posts all pass through a person.
Evaluated before it ships
A working demo is not a reason to ship. I define what correct means first, build test cases from real examples, run regression suites and LLM-as-judge scoring on every change, and trace behaviour once it is live, so a prompt or model change is a measured change.
“The interesting engineering is not making an agent capable. It is making it trustworthy enough to run in production.”
04Where it plugs in
No migration. The agent meets the stack where it is.
The common assumption is that an agent means a new platform, a new vendor and a quarter of integration work. It does not. The whole system is a tool layer written against systems that already run, and a person at the end of it.
Writing that layer is the part most projects underestimate. When the MCP server I needed did not exist, I wrote it.
The engineer
decides
Reads the recommendation and decides. The loop closes on a person.
The agent
reasons
Retrieves, reasons, and grounds every claim in something it actually read.
MCP + tool layer
I write this
Written against the systems that already exist. When the server I needed did not exist, I wrote it.
The stack that already runs
- Grafana
- Loki
- Prometheus
- Jaeger
- Kubernetes
- Ticket queues
- Confluence
- GitHub Actions
05Track record
Roles, and results a stranger can check.
2025 — present
Senior AI Engineer
Production agent systems for engineering and IT operations. Custom MCP servers, autonomous anomaly detection on the observability stack, containerized agent workloads on Kubernetes.
2024 — 2025
AI Engineer
Multimodal GenAI invoice processing (10 minutes of manual effort down to under one), RAG over 100+ enterprise PDFs at 95%+ contextual accuracy, transformer fine-tuning, microservices on Cloud Run with CI/CD.
2024
Freelance GenAI Engineer
Independent client work — custom chatbots, real-time query resolution and AI-driven insights for small teams. Where I learned to scope an engagement rather than a task.
1st
place — 24-hour sprint at IISc
1st place — AMD AI Sprint 2025
24-hour competition at the Indian Institute of Science, sponsored by Hugging Face and Meta.
Top 100
of 31,000+ registrants
Finalist — Meta PyTorch OpenEnv Hackathon
Top 100 of 31,000+ registrants. Built a reinforcement-learning environment for decision-making under time pressure and incomplete information.
1,341
builders — a world record
Guinness World Record participant
Largest agentic AI hackathon — 1,341 participants, Google Cloud and Hack2skill, 2025. Built a multi-agent assistant on a custom MCP server.
06Writing
What I write about
Short, practical posts on building agents that hold up after the demo. Written from systems I have actually shipped, not from announcements.
Permissions and blast radius
Deciding what an agent must never be able to touch, before deciding what it can.
MCP tool-surface design
Why the tool layer, not the model, decides whether an agent reaches a system reliably.
Eval-driven development
Defining “correct” first, and making “done” a fact the system can check.
Hooks and guardrails
Turning rules an agent is asked to follow into constraints it cannot break.
Get in touch
Building an agent that has to survive production?
I write about MCP design, evals and guardrails on LinkedIn most days. If you're working on something similar, I'm happy to talk shop.