Head of Engineering — the whole org: backend, frontend, mobile, data and AI, working directly with the founder on strategy.
PLATFORM
Multi-bank, multi-geography architecture across the US, Canada and the UK — data residency designed so new geographies land without rework.
REALTIME
Rule & signal-processing platform on Apache Flink for fraud, compliance and credit — already a +20% lift in anomaly detection.
DATA/ML
Feature store powering churn (78% recall, 0.83 F1, ~89% precision) and LTV models; leading the warehouse migration to Databricks.
AI
From zero: RAG, NL-to-SQL on a semantic data layer, an agent platform on LangGraph/LangSmith, fraud dashboards wired to Anthropic models.
Cerebrum — AI agent platform · disputes & compliance
Cerebrum · 100+ agents in production
25%
disputes resolved end-to-end.
No human in loop — understand, investigate, reach customer, close.
90%
compliance reporting & QC.
Humans review exceptions only. Built on LangGraph, LangSmith, Java.
AI collections — Retell AI × ElevenLabs · voice agents
Collections · Retell AI × ElevenLabs
+72%
over human collectors — B1, B2, B3 fully automated.
80–90% of collector bandwidth freed for the hard buckets (B4–B6). ElevenLabs voices on Retell AI, calling based on feature-store signals — who to call, when to call, how to optimize collection.
Payments — US ACH routing · real-time settlement
Payment routing · US ACH → intraday rails
90%
of transactions now settle in real time.
ACH in the US has no native real-time settlement — daily or 3-day windows. Built a routing engine that reads user and bank-account signals to decide which transactions can move to intraday rails. Six months ago this number was 10%.
Latency — CQRS · CDP · client-side rendering
CQRS · CDP · client-side rendering
500ms<120ms
App launch for migrants arriving in the US, UK, Canada from anywhere — data residency per country, cross-border network hops, and Zolve app sessions under 2 minutes. Solved with CQRS reads, TTL-synced data at the user level, and template rendering moved to the client.
Zolve is a banking app, not a classroom. No GPU rendering, no CPU-intensive streams — React Native handles it fine, and fungibility means one engineer owns across the full platform.
8→2–3
engineers per release.
No-code release platform lets PMs compose new screens from the widget library and ship without engineering — powered by the same skeleton templates the CQRS layer delivers on launch.
Noon Academy — edtech · 2018 to 2022 · scale
2018 — 2022 · edtech · Classroom & Platform
16M+
students reached. 10M+ active users at peak.
EVENTS
Hundreds of millions of events processed per day — live voice, sketch strokes, chat, emoji, sync packets — across 4 regions with varying network conditions.
ORG
Built and led a 20+ engineer org across mobile, backend, realtime infrastructure and platform — from scratch, with very low attrition over 3+ years.
Noon Academy — CPU / GPU rearchitecture · engineering
CPU / GPU rearchitecture · sync at scale
90→20%
CPU load during a live class.
All sketch rendering moved to GPU. Voice, chat, and network sync stayed on CPU. Each processor doing what it's designed for — the CPU was no longer fighting the GPU for the same device.
−40%
battery drain per session.
2-hour classes ran cool and without heat throttling post-rearchitecture. Reconnection after a network drop synced state in under 2 seconds — no session lost.
Career — 13 years · five companies · trajectory
Thirteen years, five chapters.
2022 — NOWZolvehead of engineering
2018 — 2022Noon Academyengineering leader
2017 — 2018Tata 1mgsr. ios developer
2016 — 2017Yudekfounding engineer
2013 — 2016SapientNitrojava → mobile · mcdonald's, avon
B.Tech, Information Technology — Motilal Nehru National Institute of Technology, 2009–2013.
Stack — engineering · data · AI tooling
The stack.
Engineering
JavaSwiftKotliniOSAndroidReact NativeRxSwiftRxJavaSQLColumnar DB
Mridul Gupta · Bengaluru, India · English — full professional
scroll / ↑ ↓ keys
01 / 11
Engineering deep dive · AI & Agent Platform · Zolve
Cerebrum.
An internal no-code agentic platform built at Zolve on top of LangGraph, with full session logging, drag-and-drop agent orchestration, agent-to-agent handoff, native connectors, RBAC, and per-agent cost guardrails — all running on Java in production with 100+ agents.
100+agents in production
25%disputes resolved autonomously
90%compliance QC on agents
0humans in the loop (dispute resolution)
How an agent runs — the session log
01
Session Init
Every agent execution opens a session — unique ID, timestamp, triggering context, and the agent definition loaded from the registry.
02
Agent Identity
Which agent is running, its version, its assigned connectors, its domain scope, and its cost ceiling in dollars.
03
Context Window
The live context — memory retrieved, connector data injected, conversation history threaded in — visible per turn in LangSmith.
04
Conversation Log
Every message, tool call, and model response is persisted. Full replay, cost breakdown by turn, and anomaly flagging on deviation.
Platform architecture
Core Platform · Java
Cerebrum Runtime
Built in Java — the platform layer that owns session lifecycle, agent registry, connector management, RBAC enforcement, and the cost ledger. LangGraph is the graph execution engine underneath; Java is the control plane wrapping it.
Orchestration · LangGraph
Agent-to-Agent Handoff
Agents are nodes in a LangGraph. The output of one agent becomes the input of the next via a typed pipeline connector — drag one agent's output port to another's input in the UI, and Cerebrum wires the data contract and the execution order. Multi-step workflows compose from single-purpose agents without writing orchestration code.
Builder UI · No-code
Drag-and-Drop Composer
Business users and non-engineers build workflows visually. Agents appear as cards on a canvas — drag to connect, configure the data mapping on the connector, and publish. The connector is the pipeline: one agent's structured output becomes the next agent's structured input, with schema validation at the boundary.
Observability · LangSmith
Full Trace + Cost Visibility
Every session is traced in LangSmith — token usage, latency per step, model calls, tool invocations, and total cost. The cost is surfaced back into Cerebrum's ledger, where guardrails can pause or terminate an agent that hits its dollar ceiling mid-run.
Connectors · Native
Data Sources & Integrations
Native connectors for Google Sheets, internal databases, CRMs, and APIs — configured once per agent, scoped by RBAC. An agent only sees the connectors it's been granted. Connector output is typed and versioned so pipeline handoffs are stable across agent updates.
Access Control · RBAC
Guardrails & Governance
Two control surfaces: cost guardrails set a dollar ceiling per agent per run — the platform auto-stops over-budget agents; data RBAC controls which connectors, schemas, and data domains each agent (and the team member building it) can access. Domain expertise of the builder gates which agent types they can create.
Engineering challenges
State across handoffs
Each agent-to-agent connector had to carry typed, versioned context without leaking internal state — a shared schema registry and serialization contract between agents solved both correctness and debuggability.
Cost control at runtime
Token usage is non-deterministic. A hard dollar ceiling means tracking cumulative spend per turn, in real time, and interrupting gracefully when the limit is hit — not failing noisily or silently continuing.
Session memory at scale
100+ concurrent agents each maintaining their own session context required a memory architecture that was cheap to write, fast to retrieve per session ID, and auditable — conversation-scoped vector memory plus a relational session log satisfied all three.
No-code ↔ reliable execution
Giving non-engineers a drag-and-drop composer while keeping production-grade execution meant the UI was a pure configuration surface — it writes a declarative graph definition that the Java runtime compiles and validates before any agent runs.
RBAC without brittleness
Data access rules needed to survive agent updates, connector changes, and team membership changes without manual re-review — modelled as capability grants on the agent definition, not on the individual run, so access is always re-evaluated at session init.
Engineering deep dive · AI Voice Collections · Zolve
Retell AI × ElevenLabs.
When customers don't pay, they move through delinquency buckets B1 → B6. Post B6 is charge-off. The problem: human collectors were spread thin across all six buckets, leaving them under-resourced for the hardest ones. The fix: automate B1, B2, B3 with an agentic voice solution and give collectors 80–90% of their time back for B4, B5, B6 where judgment matters.
The delinquency bucket model
B1
1–30 days
First missed payment. High volume, straightforward reminders.
AI automated
B2
31–60 days
Reminder + push to pay. Still predictable conversation patterns.
AI automated
B3
61–90 days
More persistent outreach. AI outperforms humans here by +72%.
The feature store — already powering churn and LTV models — was extended for collections. Signals at the user level (payment history, behavior patterns, past engagement) determine which customers to call, in which order, and at what time of day for the best connection and conversion rate. The model optimizes for collection, not just contact.
Voice Layer · ElevenLabs × Retell AI
The agentic calling framework
ElevenLabs provides the voice — realistic, human-sounding audio with configurable tone and pacing. Retell AI is the agentic calling platform that orchestrates the conversation: dials out, runs the dialogue, handles branching (payment committed / needs follow-up / dispute raised), and logs every call with transcript and outcome. No custom voice model — this is an agentic solution built on top of best-in-class voice infrastructure.
Outcome Loop
Optimize on collection
Every call outcome — payment made, promise to pay, no answer, dispute — feeds back into the feature store. The system learns which call scripts, timing slots, and contact cadences convert best per customer segment, and the routing model updates accordingly. Collection rate improves over time without changing the infrastructure.
Impact
Collector bandwidth reclaimed
Before: collectors spent the majority of their time on B1–B3 — high volume, low complexity, low yield for skilled collectors. After: 80–90% of that bandwidth is returned to the human team, who now focus exclusively on B4, B5, and B6 where relationship skills, negotiation, and judgment drive real outcomes. The AI did not replace collectors — it made them dramatically more effective.
Engineering deep dive · Fintech · Payment Routing · Zolve
Settlement Engine.
The US has no native real-time payment settlement. The dominant rail — ACH — settles on a daily or 3-day window. For a fintech serving migrants who need their money moving now, this was a meaningful UX and trust gap. Six months ago, real-time settlement at Zolve was 10%. Today it's 90%.
10%→90%real-time settlement · 6 months
3 days→ instant for routed transactions
ACHUS primary rail — no native RTP
The problem with US payments
Context
Why real-time settlement doesn't exist by default in the US
ACH (Automated Clearing House) is the backbone of US payments. Standard ACH settles in 1–3 business days. Same-day ACH exists but has limits and fees. The RTP (Real-Time Payments) network and FedNow are newer rails that support instant settlement — but not every bank or transaction type is eligible. The opportunity: identify which transactions can move to intraday or instant rails, and route them there automatically.
Signal Layer · User
User-level signals
Payment history, account age, behavioral risk score, past settlement patterns — signals that indicate whether a given user's transaction is a good candidate for instant routing without elevated risk of return or failure.
Signal Layer · Bank
Bank-account signals
Counterparty bank capabilities — does the receiving institution support RTP or same-day ACH? What is the historical return rate for this bank? Real-time routing decisions require knowing what the destination can accept, not just what the sender wants.
Routing Engine
The decision layer
Given both signal sets, the routing engine decides per transaction: standard ACH / same-day ACH / intraday rail. The decision balances settlement speed for the customer against cost and return risk. Not every transaction should be on an expensive rail — the engine finds the optimal path for each one.
Engineering deep dive · Fintech · Latency · Zolve
500ms → <120ms.
Zolve's users are migrants — arriving in the US, UK, or Canada from India, Zimbabwe, Nepal, Bangladesh, or anywhere else. Data residency rules mean their data must stay in the right jurisdiction. Network hops between jurisdictions add latency. And the Zolve app session length is under 2 minutes — every millisecond of load time is a visible fraction of the total experience.
500msend-to-end round trip before
<120msapp launch after CQRS + CDP
<2 minZolve app session length
3data-residency jurisdictions
The old architecture and why it was slow
before 01
Client request
App opens, requests a screen — backend fetches all user data from the database for that context.
before 02
Template service
Backend wraps the data in a template — the server builds the full rendered payload for the client.
before 03
Large payload
A templated, pre-rendered bundle travels over the network. Payload was large — cross-border hops added 300–500ms on their own.
before 04
500–700ms total
Backend sub-200ms. But end-to-end: 500ms to 700ms. The network and the payload size killed the experience.
The CQRS + CDP architecture
Reads · CDP (Content Data Platform)
Separate read layer with TTL
A CQRS read layer — CDP — syncs user-level data points whenever a write happens on the backend. Each data point carries its own TTL. While TTL is alive, the client reads from CDP (fast, edge-cached). When TTL expires, CDP fetches fresh from the source database and re-syncs. The client never hits the core database directly.
Client · Template Service + Skeleton
Rendering moved to the device
On launch, the app checks when templates were last updated and downloads only what has changed — skeleton screens with no data, just layout. These are cached on device. The CDP then sends raw data, not templated bundles. The client merges data into the skeleton locally. Today's phones — 8–16GB RAM, high-compute — do this in milliseconds.
Result
What changed
Two things eliminated: the backend templating step (removed from the critical path), and the large pre-rendered payload (replaced with raw data, dramatically smaller). Backend services were always under 200ms — the problem was what was being sent over the network and how much of it. Breaking that with CQRS and client-side rendering cut launch time by 76%.
Residency + Fungibility
Works across jurisdictions
Each CDP instance is deployed per data-residency zone (US, CA, UK). The client connects to the right zone automatically — no cross-border data movement for reads. The same skeleton + raw data architecture works identically in each jurisdiction, so features ship once and work everywhere.
Engineering deep dive · EdTech · Noon Academy · 2018–2022
16M+ Live Students.
A live classroom on a phone is one of the most hardware-demanding things you can run. Voice streaming. Live sketch drawing. Chat. Emojis flying. All simultaneously, on a mobile CPU, across varying networks, for sessions up to 2 hours. At 10M+ active users, hundreds of millions of events per day. The CPU was always overloaded. Performance was degrading. Heat and battery drain made 2-hour sessions painful.
16M+students reached · 10M+ active at peak
100s of Mevents processed per day
90→20%CPU load during live class
−40%battery drain per session
50K+concurrent classrooms at peak
<2sreconnect + state sync after drop
The CPU/GPU rearchitecture
The problem
Everything was on the CPU
Voice, sketch rendering, chat, emoji animations, network buffering — all on the CPU. Even 8–16GB RAM devices were overloaded. Battery drain was severe. Heat throttled performance further. The classroom experience was degrading in proportion to session length — the longer the class, the worse it performed.
Rearchitecture · GPU
Sketching moved to the GPU
All sketch rendering — every stroke, update, and redraw — was moved to the GPU via the native iOS and Android graphics APIs. The GPU is purpose-built for this: parallel pixel operations, hardware-accelerated compositing, no CPU competition. What took multiple CPU update cycles per frame now happened in a single GPU pass — dramatically faster and cooler.
Rearchitecture · CPU
Voice and network stay on CPU
Voice decoding, chat, WebRTC connection management, and network-layer sync all stayed on the CPU — these are sequential, latency-sensitive operations that the CPU handles well. The separation freed each processor to do what it's designed for. 2-hour sessions ran cool with normal battery consumption after the split.
Sync · Backend
Sketch-voice sync per student
Voice and sketch are independent streams — they can drift. A teacher's voice and their sketch stroke have to feel simultaneous to each student, regardless of individual network conditions. Built per-student sync logic that compensated for variable latency at the infrastructure level, not by slowing the stream down to match the worst connection in the room.
Resilience · WebRTC
Drop and rejoin without session loss
Mobile networks drop. A student losing connection mid-class shouldn't lose the session state. WebRTC connections were made resumable — on reconnect, the session synced from the last known good state, not from zero. Built the sync framework with event fingerprinting and checksums to detect and fill gaps without interrupting the live session for others.
Observability · Druid + Cassandra
Device-level visibility at scale
Every client sent a network packet to the backend every 500ms — voice quality, sketch lag, sync state, battery level, signal strength. This was stored in Cassandra and queried via Apache Druid for real-time observability. Sync issues could be traced to a specific user, device, teacher, or geography — not just "the Middle East region had problems today."
Backend scale
The infrastructure numbers
At peak: 50K+ concurrent WebRTC connections — each classroom an independent voice + sketch session. Event throughput from all clients: ~6,000 events per second sustained, higher during lesson start/end spikes. Fingerprint + checksum validation ran per-event at sub-10ms. State recovery on reconnect: under 2 seconds to full sync. The backend was multi-region across 4 geographies; sessions were pinned per student to their region's infra to minimize latency while WebRTC traversal handled the last mile.
Engineering deep dive · Trajectory
13 years.
From Java developer to Head of Engineering — five companies, three geographies, one consistent thread: staying close to the engineering while owning more of the business. Story coming soon.