About
I build the agent, then I keep it alive.
I am an AI engineer working on production agent systems for engineering and IT operations. Most of what I have shipped lives in the least forgiving place an AI system can live: inside the workflows an on-call engineer depends on at three in the morning.
Four of my agents run inside a Fortune 500 pharmaceutical enterprise — incident triage on the enterprise ITSM queue, an observability copilot over a multi-application Kubernetes estate, and a knowledge agent serving the whole business through Confluence. One of them cut mean-time-to-acknowledge by roughly half. Alongside that I run a client’s production computer vision service single-handedly, using a three-agent delivery pipeline I built so that one person could carry it.
That combination is the thing worth knowing about me: I have built agents inside enterprise constraints, and I have been the only person on call for one. Both teach you the same lesson from different directions — the interesting engineering is not making the agent capable, it is making it trustworthy.
Give me the problem statement. I build the system that solves it reliably, in production, where it creates measurable value.
Before I specialized in operations agents, I spent three years shipping the layers underneath them — RAG systems, multimodal extraction pipelines, forecasting models, computer vision and transformer fine-tuning. Ten production systems in total. That history is why I am comfortable saying when an agent is the wrong answer.
I work in the open too. I write about production agent engineering on LinkedIn most days — using a content pipeline that is itself one of the case studies on this site.
How I work
Principles
Four things that show up in every system I have put into production.
Human-in-the-loop by default
Every agent I have put into production retrieves, reasons and recommends — a person decides. The incident copilot posts a recommended fix onto the ticket; the SRE acts on it. That boundary is why these systems were allowed anywhere near production in the first place.
Scoped, non-destructive access
My DevOps diagnostic agent has SSH into a production EC2 host with a hard allowlist of read-only commands. It can tell you exactly what is broken and what the fix should be. It cannot apply it. Capability is easy; deciding what an agent must never be able to do is the engineering.
Built on the stack you already run
No rip-and-replace. I wrap what you have — Grafana, Loki, Prometheus, Jaeger, ServiceNow, Confluence, GitHub Actions — behind MCP servers and tool interfaces. When I needed a Grafana-stack MCP server that didn't exist, I wrote one.
Failure modes before features
High-cardinality PromQL that times out. Ambiguous tickets that retrieve the wrong runbook. Log noise that poisons a summary. I design for these first, because they are what actually decides whether an agent is trusted six months in.
Toolkit
What I work with
- Models
- Claude (Sonnet 4.5)OpenAIGemini — multimodalOllama / vLLM
- Agent & orchestration
- MCP — custom + official serversLangChain / LangGraphClaude CodeMulti-agent pipelinesCustom frameworks
- Evaluation
- LLM-as-judge pipelinesRegression suitesTracing & agent observabilityStructured output control
- Retrieval
- RAG pipeline designFAISSChromaChunking & embedding strategy
- Observability
- GrafanaLokiPrometheusJaeger
- Enterprise systems
- ServiceNowConfluenceJiraSlackGitHub Actions
- Platform & backend
- AWS (EC2, S3, Lambda, Bedrock)KubernetesDockerPythonFastAPIPostgreSQL
- Testing & ML
- Playwrightscikit-learnPandas / NumPyComputer vision — grading & defect detection
Model Context Protocol
Servers and integrations I have built
Most teams consume MCP servers. Fewer have written one. When the Grafana-stack server I needed did not exist, I built it — and that is the layer that decides whether an agent can reach your systems reliably or not.
- Custom Grafana-stack MCP server (Loki / Prometheus / Jaeger)
- Confluence
- Jira
- GitHub
- LMS platforms
- Playwright-based scrapers
Enterprise work described on this site is anonymized. No client names, source code, documentation contents, log data or customer information appear anywhere here — only the architecture patterns and the outcomes I am free to discuss.
Before the agents
Earlier shipped work
RAG systems, ML pipelines and LLM applications shipped before I specialized in operations agents. Listed briefly — the seven case studies are where the current work lives.
Supply Chain Forecasting System
Enterprise ML pipeline for supply chain optimization — containerized and shipped with full CI/CD rather than handed over as a notebook.
- Python
- scikit-learn
- Flask
- Docker
- 92% forecast accuracy
- 25% cost reduction
WebAI — Website Assistant
Always-on customer assistant trained on a business's own site content, with a knowledge base that updates in real time.
- Next.js
- LangChain
- FAISS
- Vector search
- 80% efficiency gain
- 24/7 coverage
ANPR Model Fine-Tuning
Transformer-based number-plate recognition for a smart-city programme. The EV case was effectively broken at 11% — different plate colours and formats the base model had never learned.
- Transformers
- Fine-tuning
- Computer vision
- 11% → 88% on EVs
- 75% → 92% on non-EVs
Recognition
1st place — AMD AI Sprint 2025
24-hour competition at the Indian Institute of Science, sponsored by Hugging Face and Meta.
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.
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.
Limited availability
Tell me the problem.
I’ll tell you if an agent is the answer.
A 30-minute call, no pitch. Describe the manual loop that hurts and I’ll give you a straight read on whether this is worth building — including when the honest answer is a script, not an agent.
30 minutes · video call · no pitch