Backend & Distributed Systems · Applied AI
I build systems where being wrong isn't an option. Then I point that discipline at AI — and translate it for the people who have to trust it.
I'm Vipul — a backend engineer on a financial core, where a mismatched record isn't a bug, it's an audit finding. That's a fast way to learn "it worked when I tried it" is never good enough. Now I build AI to the same standard — for people who can't afford it to be wrong.
What I actually do
Three things, and they reinforce each other.
Right the first time, at scale
I work on a financial core where a wrong record isn't a bug — it's an audit finding. So I build for correctness under load: migrations that move tens of millions of records without dropping one, reconciliation that survives out-of-order events instead of silently mislinking accounts. The kind of right that holds up when someone checks.
AI someone can actually bet on
I bring that same standard to AI. Making an agent work in a demo is easy; the part I care about is proving it holds up before it touches anything real — putting a number on whether it works, then shipping it where the answer matters. Reliability isn't a feature I add at the end; it's the reason the thing is worth deploying.
Explaining it to whoever signs off
Correctness only counts if the people who don't write code trust it. I've defended migration and reconciliation results to compliance, audit, and tech-lead reviewers — turning consistency and event-ordering guarantees into terms a non-engineer can approve. It's the part I like most.
Selected work
Two builds, same rule: prove it works, then hand it to someone.
Find out if your agent breaks before your users do.
Anyone can get an agent working in a demo. Almost nobody can tell you whether it holds up — those are different jobs, and this does the second one. Plug in your LLM agent, build evals from a template, and benchmark it on reliability, latency, and cost, with a full trace behind every run.
- A 12-case benchmark porting real distributed-systems failures: duplicate-key retries, DLQ poison messages, config drift, rate-limit storms, unsafe remediation.
- A typed Agent-Under-Test contract + HTTP JSON adapter — register any external agent and run it against the same suite as the built-in reference agent.
- FastAPI + PostgreSQL services for runs, trace persistence, eval execution, and comparison APIs (Pydantic, SQLAlchemy, Alembic).
- A full trace per run — schema and guardrail checks, latency, tokens, cost, model/prompt version — so agents compare on reliability, not vibes.
A research agent, built for people who'd actually use it.
Students at a top business school were paying as much as $200/mo for AI tools they barely knew how to drive — and still hitting rate limits mid-analysis during case competitions. The ask sounded like "help me research faster." What it actually needed: read the primary filings, don't hallucinate the numbers, don't cap out. So I scoped that and started building.
- Discovery, not order-taking. Traced "research for a case comp" down to what it really needed — primary SEC filings, risk-factor diffs, segment data, footnotes — and where flat-rate tools were failing him.
- Bounded multi-agent design. A frontier model plans and synthesizes; a swarm of cheap models does the reading; a verifier grounds every figure to a source line — because a wrong financial is worse than a vague one.
- The AI angle on purpose. Each role routes to the cheapest model that can do that job — and the whole thing runs through my Agent Reliability Workbench, so the cost story gets proven, not promised.
- Value defined before the build. Not a slicker chatbot — cents per report instead of a $200 flat rate, no rate-limit ceiling, and quality that holds. The same architecture is a 40–70% inference-bill cut at company scale.
Experience
Where the numbers come from.
Software Engineer, Enterprise Microservices
On a 3-engineer team modernizing a legacy core account system for 100M+ accounts. I owned the Contact and Authorized User pipelines end-to-end — 700M+ records through parsing, business rules, PostgreSQL, and publishing to 4+ downstream services — and delivered migration and reconciliation at 99.9%+ validated accuracy. I also resolved a production incident where audit-field-only diffs were looping legacy-sync events and firing false downstream updates.
Python Developer Intern
Built probabilistic modeling workflows (PyMC3, ArviZ) over large financial datasets and integrated FINRA API data into quarterly projection pipelines.
B.S. Computer Science
Foundations for the systems work I do now — plus the years of explaining technical things to people who don't share the vocabulary.
Get in touch
Forward-deployed, AI solutions, and backend engineering.
If you're putting AI into production somewhere it genuinely has to work — with your team or a customer — and you want someone who'll build it and stand behind it, I'd like to hear about it.