About Me

About me

Hey, I'm Vansh. I'm an Engineer 2 at Cvent. I build AI agents, RAG pipelines, and automation systems, and my job is basically making sure they actually hold up in production, not just in a demo.

Most of what I do day to day is RAG pipelines, agent orchestration, backend systems, and the engineering around them. A lot of it comes down to taking something that "works when I test it" and getting it to work reliably when real users are using it. I've shipped 27+ production-grade AI and automation systems across HR, Finance, Sales, IT, and Client Services. I've worked on everything from AI agents and serverless workflows to internal platforms and evaluation systems, and I've become increasingly interested in what happens after the initial prototype works.

One of the systems I've built is a RAG pipeline for reading and completing vendor forms. It uses LangChain, pgvector, cross-encoder reranking, and agents for document retrieval and form-field resolution. It reached around 90% field accuracy when validated against 500 historical vendor forms and eliminated about two full-time roles' worth of manual effort. Another is an HR early warning system that I built with React, Node.js, Snowflake, and Redis. It surfaces workforce risk signals for managers across 5,000+ employees, with query latency around 300ms.

I've also worked on AI systems where getting the model to produce a good answer is only one part of the problem. For one CRM workflow, I built an AWS Lambda pipeline that routes inbound emails through Azure OpenAI and LangChain for intent classification, creates new cases when needed, and notifies the right reps. We validated it against a 10K-sample golden dataset and built evaluation workflows around production monitoring and rep feedback. That experience has made AI evaluation and observability just as interesting to me as building the AI workflow itself.

But I didn't start out building AI systems.

Before this role, I was an RPA developer intern on the same team. That's where I learned that automating a UI and actually solving the problem are two very different things. I worked on enterprise automation projects and ended up rewriting one of our production pipelines from a UI-driven workflow into an API-first one. The runtime went from around 5 minutes to under 5 seconds. That was one of the first experiences that pushed me to think beyond the tool I was using and focus more on the actual system underneath it.

That shift has probably influenced how I approach engineering more than anything else. I like building things, but I also like understanding what happens when they stop working. What happens when the input isn't what you expected? What happens when an agent retrieves the wrong context? What happens when a workflow has to run thousands of times instead of once? What do you measure when the output isn't deterministic? Those are usually the parts I find most interesting.

Outside of work, I started DSA & DEV, a community for developers preparing for interviews and looking for jobs. It's at 6,000+ members now, which still catches me off guard sometimes. Building it has given me a completely different perspective from working on enterprise systems. It's one thing to build something for a defined internal workflow and another to build something that people voluntarily come back to and use. I've worked on the platform, community, job discovery, resources, dashboards, and the systems behind it, and it has been one of my longest-running side projects.

I'm also AWS Certified (Solutions Architect Associate), and I studied Electronics & Communication Engineering at Punjab Engineering College, Chandigarh. Most of what I've learned about software engineering has come from building things, working with people who are better than me, breaking things, fixing them, and trying to understand why something worked or didn't work in the first place.

This blog is where I'll write about the stuff I don't usually get to talk about: how RAG systems behave once real users touch them, what breaks when you put AI agents in front of people, how to evaluate AI systems when a simple accuracy number isn't enough, the backend and infrastructure decisions behind AI products, and whatever else I end up building.

I don't want this to be a collection of tutorials where everything works perfectly on the first try. I want to write about the messy parts too. The approaches that didn't work, the edge cases I didn't think about, the production problems that took longer than they should have, and the engineering decisions that looked obvious in hindsight.

Basically, this is where I'll document what I'm building, what I'm learning, and what I break along the way.