perception & generation → the model. never the other way around.
01 · About
I build the parts of AI systems that have to be trusted, not just impressive in a demo.
AI/Full-Stack Engineer building agentic AI, RAG, and voice AI systems alongside production NestJS/FastAPI backends. Focused on evaluation rigor over demo polish — every project below documents what actually works, what doesn't yet, and why.
Agentic Systems, With Guardrails
LangGraph agents where risk-tiering is a deterministic, auditable rule table — not an LLM's confidence score — with durable human-in-the-loop checkpoints for anything high-stakes.
Retrieval & Memory
RAG systems where access control and contradiction-handling are architectural decisions, not afterthoughts — permission-aware vector search, hybrid vector + graph memory.
Production Backends
NestJS and FastAPI services at real scale — 50+ database schemas, async job queues, caching layers, and third-party integrations shipped and maintained in production.
International Institute of Information Technology, Naya Raipur
B.Tech, Electronics and Communication Engineering
Dec 2021 — Jun 20258.11 / 10 CGPA
02 · Experience
Where the production code lives
Two very different domains — e-commerce infrastructure and government hydrology systems — with the same expectation: it has to hold up at real scale.
Full-Stack Developer ·Scalixity
Bengaluru
Apr 2026 — Present
Built and maintained 25+ NestJS modules on a Fastify server with PostgreSQL (Drizzle ORM), covering orders, vendors, returns, loyalty, campaigns, reviews, and admin analytics across 50+ database schemas.
Implemented Redis-cached full-text and trigram fuzzy search, BullMQ async job queues for Virtual Try-On processing, Shiprocket multi-vendor shipping integration, and a Sharp/WebP image pipeline with AWS S3 storage.
Developed a multi-channel notification system (Brevo email, Twilio SMS, Firebase push), JWT + Firebase Auth, and contributed to the Next.js 15 frontend with Razorpay payments and TanStack Query-driven data fetching.
Contributed to the Integrated Decision Support System (IDSS) for the Government of Telangana, building backend services in Java 8/11 and Spring Boot to process hydrology and water-resource data from 1000+ sources — reservoirs, river gauges, rainfall stations, and pump houses.
Built and maintained RESTful APIs and event-driven data workflows ingesting real-time and historical water-system data, powering automated scraping, transformation, and combined batch/streaming pipelines.
Worked on distributed data processing with Kafka and Flink, improving system reliability and pipeline performance while debugging production issues in the ingestion layer.
An AI system's riskiest decisions — who gets contacted, what gets escalated, what executes without approval, what a query is allowed to see — should be made by rules a human can read and audit. The model handles perception and generation. It never gets the final word on consequences. Each project below documents what's verified, what's still in progress, and what the known limitations are — no numbers are smoothed over.
SentinelRAG
Permission-aware RAG with native vector-level RBAC / ABAC / ReBAC
Red-team gate passingPython · FastAPI · Qdrant
A RAG system where access control is enforced inside the vector search itself — not bolted on after retrieval.
0.0%
Red-team leak rate
100%
Fail-closed compliance
12 × 5 personas
Adversarial vectors tested
The problem
Naive RAG — and naive post-filtering — leaks sensitive chunks, wastes compute retrieving documents it can't return, and confirms a restricted document's existence just by denying access to it.
The key decision
Authorization metadata (sensitivity tier, department, clearance, project scope) is denormalized onto every vector payload at ingestion, then enforced as a filter predicate inside Qdrant's HNSW graph traversal. Unauthorized vectors are never evaluated as candidates — there is nothing left to leak.
Why it holds up
Hybrid RBAC + ABAC + ReBAC resolved into a single Qdrant filter predicate per query, not three separate checks
Fail-closed by default — an invalid token or a DB miss drops to public clearance, never to open access
Zero existence-confirmation leakage: a denied query and a non-existent query return the identical response
Every query and denial is SHA-256 hash-chained into an immutable audit trail (SOC 2 / HIPAA-oriented)
In progress — eval harness nextPython · FastAPI · LangGraph
Decides whether a voice-authenticated call — a password reset, a payment approval — should proceed, ask a verification question, or require step-up verification, instead of trusting a voice as identity proof by default.
100% (60/60, n=300)
Phase 1 held-out accuracy
4 / 6 phases shipped
Build status
The problem
Most voice-auth flows treat a voice as sufficient identity proof. A strong deepfake signal, or a subtly-off call pattern, should raise the bar — not get silently waved through.
The key decision
A deterministic, config-driven risk table combines an acoustic deepfake score, a per-caller behavioral baseline (updated online via Welford's algorithm), and workflow sensitivity. A single strong acoustic signal escalates the tier even on an otherwise low-sensitivity workflow — it is never overridden just because the rest of the call looks calm.
Why it holds up
Acoustic detector: 50 features (pitch jitter/shimmer, spectral shape, 13-coefficient MFCC) via a class-balanced Random Forest
Behavioral analytics tracks a rolling per-caller baseline online — a first-time caller is scored 'unknown', never defaulted to low-risk
Risk engine verified end-to-end against a real, running Postgres audit trail — not a mock
Documented honestly: Phase 1's 100% is a small, clean-condition sanity check, not a production claim — the clean-vs-degraded telephony eval (Phase 5) is the real test, and it's still in progress
Deliberately injects the failure modes voice agents hit in production — background noise, dropped packets mid-word, real degraded phone calls — and uses an LLM judge to score whether the agent degraded gracefully or failed silently.
50 tests, no network calls
CI test suite
packet loss, not noise
Dominant failure mode found
The problem
Voice agents get tested on the happy path: clean audio, native accents, uninterrupted speech. Production gives them background noise, dropped packets, and callers who trail off mid-sentence — and most teams find out only after it ships.
The key decision
Two chaos lanes score through the identical LLM judge and land in the same dashboard: a synthetic lane that mutates clean audio (noise overlay, simulated packet drop), and a real-PSTN lane that places an actual phone call through a live telephony API against the exact same self-hosted agent brain — so a synthetic model of a fault can be directly checked against what a real degraded call actually does, not just assumed to be equivalent.
Why it holds up
Ran the same utterance at increasing chaos intensity and found the counterintuitive result: white-noise overlay barely stressed a modern Whisper-class STT even at max intensity — packet loss (temporal gaps) is what actually broke comprehension
A real outbound PSTN call via a live telephony API surfaced a genuine, independently-scored Silent Failure — a production-relevant bug synthetic testing alone wouldn't have caught
Documented the limits of its own comparison honestly: the real-call test initially exercised a generic hosted persona, not the identical brain under test, until a self-hosted audio lane closed that gap
Self-hosted WebSocket audio lane verifies HMAC-signed frames, buffers turns via energy-based VAD, and streams a real reply back — verified end-to-end against real audio and real model calls, not mocks
Code-switched voice agent with a telephony-robustness eval harness
Shipped — eval harness needs a live model key for task-completion numbersPython · FastAPI · LangGraph
A Hindi-English (Hinglish) voice agent with real tool-calling and barge-in — built to feed a standalone eval harness measuring exactly how much accuracy degrades under simulated PSTN telephony conditions versus clean audio.
48 Hinglish utterances
Eval corpus
3 tiers, audit-logged
Risk-tiered escalation
The problem
Most voice-agent demos report accuracy on clean, single-language audio. That number says nothing about a real phone line, and even less about code-switched speech most ASR and eval tooling isn't built to score correctly.
The key decision
The eval report is treated as the actual deliverable, not the voice demo — a PSTN-simulation pipeline (8kHz resample → bandpass → G.711 mu-law round-trip) runs the same labeled Hinglish corpus through the real ASR and agent, clean vs. degraded, segmented by code-switch density, so the number reported is what the pipeline behind the demo actually does under degradation.
Why it holds up
Diagnosed and fixed a script-mismatch bug (Whisper output in Devanagari scored against romanized ground truth) that had silently invalidated early WER numbers — the full writeup is kept in the repo rather than quietly patched over
Caught its own eval's false result: degraded audio initially scored a lower WER than clean audio, traced to STT hallucinations on a handful of clean clips at a sample size too small to average out — reported as a statistical-power gap, not a robustness finding
Real-time barge-in via asyncio task cancellation, per-connection session state, and a WebSocket gateway with VAD-based turn-taking
Every turn — transcript, intent, risk tier, tool result, per-stage latency — is audit-logged to Postgres with PII redaction applied before persistence, fail-open if the database is unreachable
Human-in-the-loop approval agent for high-stakes actions
ShippedPython · LangGraph · React
A durable LangGraph agent that auto-executes safe actions and hard-freezes to a Postgres checkpoint — not a blocking console prompt — the instant it hits a high-stakes one, resuming exactly where it left off hours or days later.
The problem
Most human-in-the-loop agent demos use a synchronous input() block: it can't survive a server restart, and it can't handle a reviewer editing a payload instead of just approving or rejecting it.
The key decision
Risk tiering is a deterministic rule table — dollar thresholds, VIP/flagged-customer checks — never an LLM's confidence score. Tier-2 actions serialize the full agent state to Postgres via LangGraph's native checkpointer and interrupt, freeing the process entirely until a human approves, edits, or rejects with a reason that routes back into replanning.
Why it holds up
Tiered risk engine: auto-execute, execute-and-notify, or hard-block-until-approved
Reviewers can live-edit a proposed payload (e.g. reduce a refund) before it executes, not just approve or reject
A rejection with a reason ('prorate it') feeds back into the graph, which replans and proposes an adjusted action
Integration tests assert durable state survival across a simulated interrupt-and-resume, not just the happy path
Benchmark harness built — live report pendingPython · FastAPI · Qdrant · Neo4j
A pluggable memory layer giving any agent persistent, contradiction-aware memory across sessions — combining Qdrant vector search with Neo4j graph traversal behind a rule-based hybrid router.
18 (3 categories)
Benchmark sequences
The problem
Most agent-memory demos show a fact stored and recalled once. They don't show what happens when a later session contradicts the first one, or when the answer needs a two-hop traversal across linked facts.
The key decision
A supersede-based contradiction policy never deletes a fact — it timestamps the old one as superseded in both Postgres and the Neo4j edge, preserving full audit history instead of silently overwriting memory.
Why it holds up
18-sequence benchmark across simple-recall, contradiction, and multi-hop categories, with a falsifiable prediction written before the run
Rule-based retrieval router picks vector, graph, or both per query in a handful of auditable lines — no learned router, no black box
Scoring logic itself was verified against five hand-built adversarial fixtures — stale-fact miss, graph-vs-vector precedence, planted contamination — before trusting it on real data
The benchmark report was intentionally left ungenerated rather than fabricated: it needs a live run against real Neo4j/Postgres/Anthropic infrastructure the build environment didn't have
FastAPIQdrantNeo4jPostgreSQLClaudeLangGraph
DocuMind MCP
Citation-grounded RAG, exposed natively as an MCP server
ShippedPython · FastAPI · MCP
One internal knowledge base, exposed once over the Model Context Protocol — every MCP client gets grounded retrieval for free, with zero bespoke integration code.
The problem
N AI clients (Claude Desktop, Claude Code, a Slack bot) against M internal data sources normally means N×M bespoke integrations, each reinventing auth, parsing, retrieval, and citation rendering.
The key decision
Retrieval is exposed as a primitive — a search_docs tool plus docs://catalog and docs://document resources returning structured, similarity-thresholded snippets — instead of a single opaque ask_question black box. The calling client's own LLM does the reasoning and citation synthesis, preserving MCP's transparency.
Why it holds up
384-dim local embeddings (BAAI/bge-small-en-v1.5) — no external embedding API dependency
API-key auth with SHA-256-hashed credential storage, rate limiting, and a structured request-audit log
Verified with a self-contained protocol-level test: a full SSE handshake plus JSON-RPC query cycle, not just unit tests
Documents tracked per source connector (filesystem, Confluence, git) with last-synced timestamps for staleness visibility
PythonFastAPIMCP (SSE)QdrantSQLite
Sentinel Ops
Multi-agent incident triage with deterministic escalation
Working prototype — limitations documentedn8n · Groq/Llama
Classifies incoming support tickets with an LLM — but a separate deterministic rule engine, not the LLM's own confidence, decides whether a ticket actually gets escalated to a human.
The problem
Trusting an LLM's confidence to gate escalation is a single point of failure: one soft classification silently under-escalates a genuinely risky ticket.
The key decision
The risk scorer combines the LLM's classification with an independent keyword scan of the raw ticket text — if either signal indicates risk, it escalates, and the deterministic layer never overrides a risk signal for a 'smoother' LLM-only judgment. A second, separately-scheduled workflow re-classifies a sample of past tickets with a blind LLM judge and alerts if agreement drifts.
Why it holds up
Built entirely on free-tier infrastructure — self-hosted n8n, Groq's free tier, a free Slack workspace
Self-evaluating: a blind-judge workflow measures its own routing agreement rate on a schedule and alerts on drift
Limitations documented, not hidden: a medium-urgency mapping gap found during testing, a same-model-family judge-bias risk, and a currently-broken email escalation channel are all called out directly rather than patched over silently
n8nGroq / LlamaSlackGoogle Sheets
Consent Trail
Compliance-gated voice outreach automation
Consent gate shipped — audit workflow in designn8n · Groq
An outreach workflow where the decision to contact someone is made by a deterministic rule engine, never by the LLM — the AI only ever personalizes and classifies, it never decides whether the call is allowed.
The problem
In AI-driven outreach, an LLM deciding whether a call is appropriate — or an opt-out that takes a batch job to register — is a compliance failure waiting to happen.
The key decision
A deterministic Code node (no LLM) gates every contact against the opt-out registry and re-contact interval before personalization ever runs. The call outcome is then independently scanned for opt-out language by both a classifier and a keyword scan — either signal alone registers the opt-out immediately, in the same run.
Why it holds up
One of three related projects — with Sentinel Ops and Praxis — applying the same philosophy to a different domain: consequential decisions get made by rules a human can read and audit; the AI handles perception and generation only
A second, independently-scheduled workflow audits the system's own call history for opt-out violations — a compliance mechanism nobody checks isn't one
Voice delivery is pluggable: a deterministic mock executor for offline testing, or a documented Twilio path for real calls
Limitations named directly: the audit workflow itself isn't exported yet, and the Twilio path is unverified until run against a real call
n8nGroqGoogle SheetsTwilio (optional)Slack
04 · Skills
Toolbox
Generative AI & Agentic Systems
LangChainLangGraphLangSmithRAGSelf-RAGCRAGGraphRAGMCPAgentic AIQdrantChromaDBNeo4jText2SQLOpenAI APIAnthropic Claude APIOCR PipelinesAsync AI PipelinesTool Callingn8n