Ragavarshini R

Constraint

Checkout changes ship to more than 52 European markets at once. Every additional authentication step costs conversion; every regression is measured in real transactions, not in test coverage.

And you cannot fix funnel leakage you can't see — detection time is part of the problem, not separate from it.

Decisions

• Delivered the full path — React, Next.js and TypeScript interfaces through Java/Spring and Node.js services over REST and GraphQL — for the platform versions now live across 52+ EU countries.
• Ramped the new checkout version country by country to 52+ EU markets, now carrying roughly 95% of EU checkout traffic. Conversion was watched at each step of the rollout, not totalled at the end of it.
• Re-engineered Amex delegation flows to cut a full authentication step out of the user journey — 4× improvement in delegation conversion.
• Owned conversion strategy for enterprise merchants end to end: found the friction points across checkout, prioritized the fixes, and drove them through to release rather than filing them — conversion on the new checkout version up 30% across the EU markets it shipped to.
• Led performance optimization of the checkout module, cutting latency on the critical path — measured release by release against the conversion numbers, not asserted afterwards.
• Built the internal conversion tooling — automated real-time monitoring and custom Datadog reporting — taking conversion analysis from one to two weeks of manual investigation down to a few hours, and funnel leakage from something you went looking for to something that surfaces on its own.
• Architected the agentic diagnostic system over BigQuery and Datadog that autonomously surfaces root causes of user drop-offs.
• Scrum Master for the team — running Agile ceremonies and raising delivery predictability.

Constraint

“Why did conversion dip in DE last week?” was a question that cost an engineer hours. Pull the numbers from BigQuery, find the funnel step that moved, then start joining event tables and Datadog logs by hand — and the knowledge of which query answers which symptom lived in a handful of people's heads.

The same question arrives scoped three different ways — by country, by merchant, or by experiment — and a good share of the time the answer is something the team has already seen before and written up.

Decisions

• Check before diagnosing. The pipeline pulls conversion for the requested scope from BigQuery first and stops there if nothing moved. No dip, no investigation — the cheapest possible answer is “nothing happened”.
• Escalate in tiers, cheapest first. A diagnostic agent localizes the dip to a checkout section from the drop-off funnels. An analyzer agent then runs a fixed set of queries — one set per known problem type — against that section.
• Open-ended search only when the deterministic tiers come up empty. If the analyzer's output doesn't point at a specific problem, a hypothesis agent takes over: event tables, Datadog, and call logs, within a bounded search surface.
• Institutional knowledge as a retrieval corpus. The hypothesis agent references a library of past analysis documents, so a recurring issue is recognized rather than re-investigated from scratch. “We've seen this before” stops being a hallway conversation.
• A report agent closes it out — the numbers, the conversion movement, the drop-off level, and the cause with the stats behind it. The output is something you can send to a merchant or a stakeholder, not a chat transcript someone has to summarize.
• Tool access through typed MCP servers over BigQuery and Datadog: read-only and scoped at the server layer, with argument validation and structured errors, so agents fail loudly instead of inventing results — and credentials never enter an agent's context.

Constraint

A platform serving millions of users against 99.9% uptime SLAs, in healthcare, where a maintenance window is not something you get to ask for.

And a distributed system whose services each logged differently — which meant every incident started with an archaeology phase before anyone could start debugging.

Decisions

• Zero-downtime database migrations on a platform serving millions of users, with no customer-visible impact. Treated as a design problem up front, not a maintenance window to negotiate.
• Scalability work on the Marketplace framework, cutting query execution time by 25%.
• Low-latency redesign of encounter functionality, improving system responsiveness and stability by 30%.
• Introduced Apache Kafka for asynchronous, event-driven communication and real-time webhook processing across services.
• Standardized logging across distributed services — MTTR down 20% team-wide. This is the one I'd point at: it wasn't a feature, it was a convention everyone adopted, and it outlived every project it touched.
• Set query optimization and load-management practice for high-traffic paths, sustaining the 99.9% uptime SLA.
• Owned critical dependency and framework upgrades holding the platform's security and performance baselines.

Constraint

A double-entry ledger is only useful if it cannot go out of balance. Application-layer checks bind only the code paths that remember to call them — a migration script, a bulk importer, or a psql session at 2am walks straight past all of them.

Separately: an AI agent investigating a discrepancy needs to read the ledger, and must never be able to write to it.

Decisions

• Five invariants pushed into PostgreSQL, not the service — so the database is what refuses a bad write, whoever issues it.
• Amounts as BIGINT minor units with a separate direction column. No decimal type, no rounding drift, no currency-scale guessing.
• Corrections by reversal only. Never UPDATE or DELETE — post the mirror transaction, so the mistake and the fix both stay in the audit trail.
• Idempotency by request fingerprint. SHA-256 of the canonicalized body: replay the same key with a different payload and you get a 409, not a silent success returning someone else's transaction.
• The MCP server holds no database credentials. It calls read-only HTTP endpoints — the same boundary any external consumer faces — and exposes four tools: get_balance, list_transactions, trace_transaction, find_imbalances. Every response carries the exact request it made, so an answer can be checked.
• Tested against real PostgreSQL via Testcontainers, never H2. An invariant contract test attacks each rule through raw SQL, bypassing the service entirely, to prove it's the database doing the refusing.

Constraint

A router agent that should only use the right tool will eventually use the wrong one. Prompt instructions are not an access control mechanism.

CrewAI's sequential process also has no native conditional branching — so there was no framework-supported way to pick a path and commit to it.

Decisions

• Two crews, not one. A router crew classifies the question. The retriever-and-answer crew is constructed afterwards, with exactly one tool bound to it — so the agent physically cannot call a tool outside its route.
• Branching in plain Python between the crews, not in a prompt. The framework didn't offer it, so the control flow lives where control flow belongs.
• Retrieval and answer generation as separate chained tasks, so each agent output is inspectable, and the answer agent is constrained to the retriever's evidence. Out-of-scope questions return an explicit refusal rather than a confident invention.
• A full reasoning trace per run to CSV: question, chosen route, router reasoning, tool used, retrieved evidence, final answer. Routing decisions you can't audit are routing decisions you can't tune.
• Wrapped LangChain's Tavily search in a CrewAI BaseTool subclass to pass tool validation, and moved the pipeline onto kickoff_async so it runs inside the Jupyter event loop.