span 01 · about · pune, india
From queues to agents.
For the last few years I've been the engineer who makes the unglamorous parts of a product hold up: the queue that absorbs a webhook storm, the permission model that lets three companies share one platform without seeing each other's data, the cache that keeps a dashboard fast at closing time.
Agents changed what those skills are for. An LLM that calls tools is a distributed system with an expensive, non-deterministic node in the middle. It needs what my backends needed — idempotency, retries with backoff, isolation, observability — plus evals, because a 200 response no longer means it worked.
So I'm moving from building platforms that happen to have AI features to building the reliability layer for AI agents themselves. This site is part of that: the agent behind ⌘K is a real tool-use loop, and every case study shows its architecture.
span 02 · principles
How I build
01
Make failure boring
Every external call can fail, time out or run twice. Design for that first, then make the happy path fast.
02
Isolation before intelligence
An agent that can read another tenant's data is a breach, not a feature. Access control belongs inside retrieval.
03
If it isn't traced, it didn't happen
Every model call, tool call and retry gets a span. Debugging an agent without traces is guessing.
04
Evals, not vibes
A prompt change is a deploy. It ships with a test set and a number that moved.