Generative AI Engineer · Agentic Systems · Forward-Deployed AI
I build AI systems that connect enterprise data, tools, and business workflows — from agent orchestration and evaluation to backend APIs, cloud deployment, guardrails, and production troubleshooting.
My recent work is centered on enterprise agentic analytics: LangGraph orchestration, capability-based routing, schema-grounded NL2SQL, retrieval, model evaluation, human-in-the-loop controls, and AWS/Azure delivery. Earlier work spans computer vision, speech, NLP, and serverless ML systems.
~6 years in applied AI / Python engineering · New Delhi, India
LinkedIn · Email
In plain English: I help organisations put AI to work on their own data and systems, safely. Most of my projects answer one question: what has to be true before an AI system is allowed to act on real business data? In practice that means clear limits on what an AI agent may do, evidence that it behaves correctly when things go wrong, and a record a person can check.
| Project | What it demonstrates | Stack / evidence |
|---|---|---|
| TESTAMUR | Verifying creditors' claims in India's corporate insolvency process, end to end. Scanned proofs of claim (Form C), phone photos of letters of authority and files named IMG-20260914-WA0007.jpg are read once (text layer first, OCR only where needed), matched to the right creditor (GSTIN, CIN, LEI and bank identifiers first, then names inside the process, abstaining on near twins such as "Shree Anvaya Fincorp"), and checked at the cheapest tier that can decide: rules for the three-year limitation, the claim against the corporate debtor's books, rupees in words against figures, the PAN inside the GSTIN, the IFSC of the bank named, a charge registered against the debtor, and an authority that covers voting; a local model only for loan-agreement clauses, and only with a quote it can prove. Then everything after the verdict: a review queue whose decisions are rule-bound inputs, random audits with exact bounds and a per-check breaker, Learn-then-Test thresholds, an adversarial false-PASS panel, a transactional outbox that opens tasks, creditor reminders, holds on votes and payouts and signed webhooks exactly once, an assistant that answers from the records with verified citations, and a tenant-scoped MCP server where agents propose and people dispose. On a generated adversarial world with ground truth (412 uploads, 3 insolvency firms): 415 of 430 statuses exactly right, 14 handed to a person, 0 vouching when the truth says otherwise; 1,772 of 1,774 field and metadata judgements right; 1 false PASS from the clause model, on a non-critical clause; a simulated reviewer brings all 430 statuses right; 269 of 269 assistant questions right, superseded-version, near-twin and cross-tenant traps included. |
Python · SQLAlchemy (SQLite; Postgres in CI) · RapidOCR (ONNX, CPU) · llama.cpp (Qwen3-4B, CPU) · MCP · 163 tests, 55 safety mutants caught · harness gates and one required check in CI · README numbers generated from committed reports · synthetic data |
| NOISEFLOOR | A governed SRE autoscaling agent that plans inside a JEPA world model (LeJEPA's SIGReg, no decoder), tested with a pre-registered experiment as its telemetry fills with noise. Delta Lake data with a leak-guarded loader, five world-model variants on one recipe, latent CEM planning with exact actuator rollouts, one governance gate for every agent, STERNWATCH audit envelopes, MLflow tracking. Result (104 models, 3,920 paired days, run once in CI on the tagged commit): at nominal 80% noise JEPA beats a reconstruction world model (-38.5 daily cost, 95% CI [-56.6, -21.4]) and is not distinguishable from a tuned runbook that reads clean metrics; a cost-only latent beats SIGReg, reversing a registered prediction, and an EMA teacher beats it in a comparison registered without a direction. An independent code review after publication found two baseline bugs and a planner-gate interface bug; v0.2 fixes them and reports the corrected baselines (runbook 274.7-281.3 against the registered 285.3) beside the registered numbers, which stand as run. | PyTorch (CPU) · Delta Lake (delta-rs) · MLflow · AutoMQ via STERNWATCH · hierarchical bootstrap, TOST, Holm · 56 tests · 16-job CI grid · pre-registration tag · reviewed and corrected in v0.2 |
| lewm-t4 | LeWorldModel (Maes, Le Lidec, Scieur, LeCun and Balestriero, 2026), a JEPA world model, reimplemented as one PyTorch file and checked three ways: loaded with the authors' weights, encodings are bit-exact and planning costs agree to about 2e-7 (relative); in the authors' own TwoRoom planning benchmark it succeeds and fails on exactly the same 50 episodes (86%); trained from scratch in 9 hours on free Kaggle T4s, two runs reach 92% and 96% on the same episodes, not significantly different from the released model's 86% (paired McNemar p = 0.38 and 0.06). The from-scratch recipe differs from the authors' in initialisation and learning-rate schedule, as the README states, so those two runs test this recipe, not theirs. | PyTorch · ViT · AdaLN-zero transformer · SIGReg · Kaggle T4 x2 (fp16) · parity re-measured against the official checkpoint in CI |
| STERNWATCH | Event-sourced governance for AI agents: a governed agent's decisions streamed live to a Kafka-compatible log (AutoMQ) as policy-stamped envelopes, a ledger rebuilt from the log alone, a replay that re-decides recorded tool calls under a changed policy without re-executing anything (unchanged, flipped, or needs-evidence), and the same stream landed as typed columns in an Apache Iceberg table through AutoMQ's Table Topic and a schema registry, checked against the ledger and queried with SQL. | Python · kafka-python · Avro · PyIceberg · DuckDB · AutoMQ 1.7.4 + Iceberg REST + Schema Registry in CI · 83 tests · live recording of the real orchestrator: 63/63 events, 0 replay mismatches · committed reports |
| Governed Agent Orchestrator | A bounded runtime for tool-using agents: capability contracts, plan validation, parallel-wave execution, argument constraints, shared execution budgets, effect classes, human approval, fallbacks, DecisionTrace, policy memory, FastAPI and SSE. | LangGraph · FastAPI · Python 3.11+ · 29 offline tests · committed guard demo and 20-objective audit |
| ASTERION | Deployment rehearsals for enterprise agents: a customer acceptance contract becomes bounded failure-mode rehearsals (outages, stale data, duplicate events, tenant boundaries), a Witness-Coverage Gate keeps untested obligations from counting as passed, and human approval binds to an exact evidence digest. Reference and native LangGraph engines share the same nodes. | LangGraph · FastAPI · Pydantic · SQLite · Docker · Terraform · 73 tests, 0 skipped on Python 3.11–3.13 · container and Terraform checks in CI · synthetic local prototype |
| SENTINEL | Verification scheduling under freshness decay: Beta beliefs that age toward a prior, free feed evidence kept separate from costly noisy verification, decisions from an asymmetric loss table, and a scheduler that ranks checks by expected reduction in decision loss per unit cost. Compared with entropy, score-sorted, oldest-first, random and never on two seeded synthetic worlds; the README reports where it wins (scarce budget) and where it loses (larger budgets) and why. | Python · no runtime dependencies · 10 tests · committed simulation reports · simulation only |
| Retention Uplift | Budget-constrained retention targeting for a telco churn case: a data audit that finds sure things and lost causes from counts, a calibrated churn model, honest interval bounds on an observational discount flag (no demonstrated effect), an exact knapsack across save-rate scenarios, a learn-while-earning control group, and a governed pipeline whose critic vetoes lists that break the budget or target customers who churn regardless. | Python · scikit-learn · scikit-uplift · 8 tests · committed run with memo, offer list and decision trace · synthetic case-study data |
| REGIMEFORGE | Decision replay under rule change: records rule/input dependencies, conservatively selects potentially affected decisions, then replays into unchanged, flipped, or needs-evidence against an independent full-replay reference. |
Python · zero runtime dependencies · 142 tests · 9 scenarios + 120-seed randomized check |
| NL2SQL Agent | Schema-grounded NL-to-SQL with FK join-path resolution, read-only SQL validation, bounded repair, execution limits, evidence traces, and deterministic result matching. | Python · sqlglot · SQLite · Transformers · 50 tests · 24/30 measured model result match + 30/30 oracle-harness check |
| NOESIS | Inspectable adaptive-agent experimentation: multi-judge evaluation, step-level reward components, Thompson/UCB/ε-greedy strategy selection, prompt-version tracking, policy updates, rollback, and persistent SQLite state. | Python · asyncio · Pydantic · SQLite · offline end-to-end loop + evidence report |
| SCHEMAMORPH bench | A schema-drift benchmark that separates structural validity, round-trip consistency, and semantic correctness — including a counterexample where a mapping round-trips perfectly while carrying the wrong meaning. | Python · no runtime dependencies · seeded transformations · reproducible benchmark report |
| ShopNova Agent | Cloud-native support agent with Gemini function calling, four Cloud Functions, Firestore memory, Pub/Sub hand-off, bounded looping, and a server-side refund approval boundary that model-supplied input cannot bypass. | Flask · Gemini · Cloud Functions · Firestore · Pub/Sub · CI-backed approval-bypass regression test |
| Contract Clause Extraction | Source-traceable LLM extraction of audit and inspection clauses from contracts, with lexical gating, defensive parsing, and reviewer-ready Excel output. | Transformers · FLAN-T5 · Mistral · pandas · public SEC-filed sample · 8/8 target clauses found, 1 false positive |
| Customer Service RAG | PDF-grounded support Q&A plus a deterministic complaint state machine and validated FastAPI service; the LLM routes intent while tested code owns validation and state. | Streamlit · LangChain · FAISS · FastAPI · SQLite |
| MORD House Image Similarity | Earlier applied-computer-vision work: image-similarity screening of field-survey photographs for a government housing-scheme fraud-detection workflow. | Python · computer vision |
Portfolio principle: reported results are tied to reproducible commands or committed reports, and synthetic / mocked experiments are labeled as such inside the relevant repository.
| Project | The business problem, in one sentence | Who typically has this problem |
|---|---|---|
| TESTAMUR | When an Indian company goes into insolvency, every creditor must prove its claim and a resolution professional must check each one within days, from crooked scans and phone photos, while the result decides who votes on the company's future; this reads, matches and checks that evidence against the law and the company's books, says when it is not sure instead of guessing, and turns every problem it finds into work that closes itself once fixed. | Insolvency professionals and their teams; lenders and debenture trustees filing claims; legal-operations teams checking documents at volume |
| NOISEFLOOR | Dashboards are mostly noise, yet an automated operator must still decide when to add capacity or shed load; this tests, with a pre-registered experiment, which kind of learned model keeps planning well as the noise grows. | SRE, platform and capacity-planning teams; anyone evaluating world-model agents |
| lewm-t4 | Research results only help if they can be reproduced independently; this reimplements a recent JEPA world model (LeWorldModel, 2026), shows the reimplementation matches the original on the authors' weights and benchmark, and retrains it from scratch on free GPUs to planning success on par with the original's (92% and 96% against 86%). | ML research and platform teams adopting new model families |
| STERNWATCH | When an AI agent has acted and the rules later change, nobody can say which past actions would now be refused; this keeps every decision as durable evidence and replays it under the new rules. | Platform, risk and compliance teams running agents that act on real systems |
| Governed Agent Orchestrator | An AI agent that can use tools might send the wrong report, run too many actions or do something irreversible without sign-off; this project shows how to set hard limits and keep a checkable record. | Any team giving AI agents access to internal data and systems |
| ASTERION | Before an AI agent goes live for a customer, both sides need proof that it copes with outages, stale data and duplicate events, and a sign-off tied to exactly that proof. | Enterprise software vendors and customer-facing engineering teams |
| SENTINEL | Security and compliance teams have far more findings than they can re-check; this decides which check is worth the limited budget next. | Security operations and field-verification teams |
| Retention Uplift | A small retention budget is wasted on customers who would stay anyway or leave anyway; this targets the customers an offer can actually change. | Telecom, subscription and banking retention teams |
| REGIMEFORGE | When a rule or policy changes, which past automated decisions would now come out differently, and which need more evidence? | Lenders, insurers, claims processors and compliance teams |
| NL2SQL Agent | Business users want to ask data questions in plain words without letting an AI run unsafe, expensive or wrong database queries. | Analytics and business-intelligence teams |
| NOESIS | Teams that change an AI agent need to know whether it really got better, and whether the automated judges scoring it can be trusted. | AI platform and evaluation teams |
| SCHEMAMORPH bench | Data pipelines keep "working" after a partner renames or swaps a column, yet deliver wrong numbers; this benchmark measures that failure. | Data engineering and integration teams |
| ShopNova Agent | A support assistant that can look up orders and issue refunds must never approve money movements on its own. | E-commerce and customer-support teams |
| Contract Clause Extraction | Finding specific obligations, such as audit rights, across contracts is slow by hand; AI extraction has to point back to the exact paragraph. | Legal, procurement and compliance teams |
| Customer Service RAG | A support chatbot must answer from the company's own documents and record complaints correctly, without inventing policies. | Customer-support teams |
| MORD House Image Similarity | Programmes that pay out on photo evidence can be gamed with duplicate or reused photos; this screens for look-alike images at scale. | Public programmes and insurers that rely on photo evidence |
How to read each repository: every project README opens with the problem in plain English, an executive summary and an end-to-end diagram, then the technical detail, and closes with a SWOT analysis, industry use cases, a glossary and annotated further reading.
Industries this work applies to: financial services and insurance, telecom and subscription businesses, e-commerce and retail, healthcare administration, the public sector, security operations, and any company building data platforms or AI products for enterprise customers.
| Area | What I work on |
|---|---|
| Customer problem → working system | Translate ambiguous workflows into typed APIs, agent/tool contracts, validations, measurable acceptance paths, and deployable services. |
| Agentic AI with controls | LangGraph, capability catalogs, agent registries, human approval, bounded execution, structured outputs, evaluation, MCP/tool integration, persistent traces. |
| Data + retrieval | Schema-grounded NL2SQL, vector/hybrid RAG, embeddings, metadata filtering, reranking, semantic caching, pgvector, ChromaDB, Azure AI Search. |
| Backend + cloud | Python, FastAPI, PostgreSQL, AWS, Azure, GCP, Docker, GitHub Actions, Terraform, streaming and event-driven APIs. |
| Production ownership | Integration debugging, security hardening, model/provider benchmarking, observability, performance work, production RCA, and client/SME delivery. |
I am exploring the systems problems that appear after agents become useful enough to act: bounded authority, decision replay after rules change, evaluation reliability, integration/schema drift, and deployment evidence.
The goal is not to collect chatbot demos; it is to build small, inspectable systems with explicit failure boundaries, measurable behavior, and reproducible evidence.
Put simply: once AI agents can take real actions, the hard questions stop being "can the model answer?" and become "who allowed this action, how do we know it worked, and what happens when the rules or the data change?" Each project above takes one of those questions and answers it with working, tested code and an honest statement of its limits.