> system_design
Architectures
The systems I have built, as I would walk them in a design review: interactive architecture diagrams plus the functional requirements, non-functional bars, capacity assumptions, and tradeoffs behind each one. Every diagram expands fullscreen on click. One section, the agentic QE platform, is shown as a genericized reference pattern (how I would build it, no client names); everything else is the architecture as deployed.
AI-Infused Agentic QE Platform
interactive · reference architecture · how I would build itproject page →The one section shown as a genericized reference pattern rather than the deployed system: GraphRAG on Neo4j plus agentic retrieval over the issue tracker, generation through a custom Playwright MCP tool server, an audit-defensible eval layer, and one codebase beaming into customer-managed clouds A/B/C. Generic primitives only, no client names.
Toggle between the presentation architecture render and an interactive explorer where you can hover any node for the design rationale. Click either to maximize.
> functional requirements
- Generate production-grade Playwright/Cypress test scripts from natural-language user stories
- Agentic retrieval over Jira/ADO: linked epics, acceptance criteria, and existing tests as style examples
- CI-integrated execution so generated suites run where engineering already looks
- Manager-facing quality scoreboard: Acceptance-Criteria Coverage, Test-Design Coverage, RAGAS
- Tenant-aware RBAC with module-level CRUD-X permissions and role templates
> non-functional requirements
- Hallucination under 5% (from ~15%) via GraphRAG + entity normalization + reranking
- Multi-cloud portability: one codebase into customer-managed AWS/Azure/GCP, identity adapted per tenant
- Strict tenant isolation for data, cost telemetry, and permissions
- Audit-defensible evaluation so the platform survives budget reviews
> scale + capacity
- 17 enterprise QA teams at peak adoption on shared infrastructure
- ~7,000 concurrent test executions per day sustained across tenants
- Per-tenant token budgets and context compression tuned to each tenant's query patterns
- Low-complexity queries rerouted to lighter models to cut per-tenant LLM spend
> key tradeoffs
- GraphRAG costs ~30-40% more tokens per query, but ~50% fewer regenerations nets a lower cost per acceptable output
- Tenant-aware RBAC added weeks to the MVP; bolting it on later would have cost far more
- Agentic multi-step retrieval adds latency versus single-shot RAG, traded for accuracy that holds user trust
Enterprise Knowledge Assistant · Conversational RAG
interactive · production architectureproject page →The deployed architecture: a dockerized conversational RAG system over ~1,700 internal process documents sourced from Squidex CMS and Confluence, behind a load balancer and sized for a 20,000-concurrent-user design target. Hybrid semantic + keyword retrieval with re-ranking, evaluated against a held-out set.
Toggle between the presentation architecture render and an interactive explorer where you can hover any node for the design rationale. Click either to maximize.
> functional requirements
- Conversational Q&A over ~1,700 internal process documents with source citations
- Hybrid retrieval: semantic vectors + keyword (BM25) + metadata filtering for enterprise-jargon queries
- Continuous ingestion from Squidex CMS and Confluence with incremental re-indexing
- Session context so follow-up questions resolve against the running conversation
- Strict no-answer behavior when retrieval confidence is low, with escalation to human support
> non-functional requirements
- Designed for 20,000 concurrent users: stateless dockerized services autoscaled behind an ALB
- Response relevance improved 30-40% in pilot, measured on a held-out evaluation set
- Repeat escalations cut ~40% versus the rule-based predecessor
- Secrets in a managed secrets store; no credentials in images or env files
> scale + capacity
- ~1,700 documents chunked with overlap calibration: on the order of tens of thousands of indexed chunks
- Hot-question response cache to keep repeated queries off the LLM entirely
- Horizontal scaling on the API tier; the index and reranker scale independently
> key tradeoffs
- Hybrid search over pure vector: enterprise jargon breaks cosine similarity, keyword signals rescue it
- Re-ranking adds a hop of latency, traded for the 30-40% relevance lift that made the pilot
- Migrating from rule-based FAQ incrementally (not a rewrite) kept the escalation baseline measurable
The deployed Azure architecture for a civic-scale conversational assistant supporting India's census operations: RAG-grounded FAQ answering, plus deterministic transactional flows for NPR registration and birth/death reporting against central government data, every backend call behind API Management.
Toggle between the presentation architecture render and an interactive explorer where you can hover any node for the design rationale. Click either to maximize.
> functional requirements
- FAQ answering over census guidelines and procedures, grounded via RAG
- NPR (National Population Register) registration as a validated multi-step flow
- Birth and death reporting with strict field validation and receipts
- Centrally connected retrieval and submission against government registry APIs
- Multilingual interaction: intent detection and responses through a language layer
> non-functional requirements
- Burst tolerance for national census windows: edge WAF + autoscaling app tier
- Transactional integrity: the LLM assists with language but never writes records directly
- Full audit trail on every transactional step; scoped, throttled access to registry APIs via APIM
- Guardrails and refusal paths so the assistant never speculates on civic policy
> scale + capacity
- Session and case state in a distributed store so multi-step registrations survive disconnects
- Minimal PII retention: conversation state keyed to the case, purged on completion
- Generative load isolated to the FAQ path; transactional flows are cheap deterministic services
> key tradeoffs
- Deterministic state machines for registrations over end-to-end generative flows: civic records demand validation, not fluency
- APIM as a hard boundary adds a hop, but turns government data access into a managed, auditable contract
- Azure-native managed services over portability: the deployment context made the ecosystem the pragmatic call
The production-scale architecture Loop Copilot grows into as it scales past its Fortune 500 pilot: Azure-native because the product lives inside Microsoft tenants, sized for 150 concurrent users today with horizontal scale designed in for later releases. Event sourcing over vector RAG for chat context, and the three-tier D365 integration shell that lives within the customer's tenant trust model.
Toggle between the presentation architecture render and an interactive explorer where you can hover any node for the design rationale. Click either to maximize.
> functional requirements
- CRM activity logging from chat and voice in ~45 seconds (down from 4-6 minutes)
- Calendar integration, bulk activity upload with AI summarization, Telegram alerts, admin analytics
- Voice pipeline: call transcripts to structured PRD/onboarding docs, account resolution by MDM ID, auto-registration in the CRM
- Multi-CRM expansion shell: D365 today, Salesforce/HubSpot/Zoho slots architected
> non-functional requirements
- 150 concurrent users today with sub-second p95 on interactive paths; designed to scale horizontally
- All auth inside the customer's tenant trust model (Entra ID / MSAL); no external OAuth grants
- Secrets resolved at runtime from Key Vault via managed identity; zero credentials at rest in config
- Batch work (bulk uploads, transcription) isolated on queues so it never blocks interactive latency
> scale + capacity
- Autoscaled async FastAPI containers behind Front Door; Redis for session and rate-limit state
- Event store on Cosmos DB (Mongo API): append-only writes, request-time context assembly
- LLM behind an abstraction: Groq/Llama for speed, tenant-compliant Azure OpenAI swappable per customer
> key tradeoffs
- Event sourcing over vector RAG: more tokens per request, hallucinated memory eliminated entirely
- Three integration tiers cost complexity but bought cross-environment portability from day one
- MVP scoped to appointment logging only; the beta user requested expansion within two weeks, validating the cut
The piloted architecture: voice as the interaction layer atop a master orchestrator routing to specialist agents, a curated regulatory-safe knowledge base, and a multi-layer compliance posture (SEBI advisory principles, DPDP consent-first data) enforced in layers rather than model adjustment.
Toggle between the presentation architecture render and an interactive explorer where you can hover any node for the design rationale. Click either to maximize.
> functional requirements
- Voice-first interaction in vernacular languages (10-language architecture), STT in / TTS out
- Specialist agents: money logging, analysis, financial education, offer explanation
- Central memory layer with RAG: context, goals, and conversations persist across sessions and surfaces
- Offer explanation, never recommendation: explanation of terms in plain language
> non-functional requirements
- Compliance as architecture: curated KB, system-prompt guardrails, server-side governance, consent-first data
- Non-transactional by design: no money movement paths exist in the system
- One source of truth across web and mobile for a ~30-screen MVP
> scale + capacity
- Pilot scale: ~15 first-week users with ~55% repeat usage
- Voice pipeline costs bounded by routing short utterances through lightweight STT/TTS tiers
> key tradeoffs
- Curated regulatory-safe KB over open retrieval: smaller corpus, but every answer is defensible under SEBI advisory principles
- Compliance in layers over fine-tuning the model: auditable, swappable, and cheaper to certify
- Voice-first raises the floor on latency budgets; agents are modular so slow ones degrade to text gracefully
A 21-agent analyst council produces calibrated proposals through a devil's advocate stage and accuracy-weighted aggregation; a code-enforced veto gate with five concentric risk rings decides. The LLM layer has no write access to money paths. Toggle between the platform architecture and how the council actually reaches a decision.
Two architecture views: the layered platform, and the multi-agent council decision procedure. Click either to maximize.
> functional requirements
- Multi-asset analysis (stocks, mutual funds, ETFs, bonds, NPS) via a 21-agent analyst council
- Devil's advocate stage and accuracy-weighted aggregation before any proposal surfaces
- Recommendations only: human-in-the-loop approval on every action
- Live broker data via Model Context Protocol
> non-functional requirements
- Code-enforced veto gate: no money moves on LLM output alone
- Five-ring risk system: position, portfolio, drawdown, budget, connection-level broker locks
- Frozen-threshold evolution gauntlet: strategy changes must beat the incumbent on fixed statistical gates
> scale + capacity
- Sized for free-tier deployment today: single-node modular monolith with a database-backed event bus, no external queue infrastructure
- 21-agent fan-out per high-stakes decision cycle, with budget shedding that drops low-tier councils first
- Documented ports-and-adapters seams for horizontal scale: swap the event bus and split into role-scoped workers when volume demands it
> key tradeoffs
- Agent council costs tokens and latency versus a single model call, traded for calibrated, auditable proposals
- Frozen statistical gates slow strategy iteration, but rule out silent strategy drift
An orchestration layer I built runs a fleet of specialist agents across a codebase it has never seen, reconciles their findings into one prioritized picture, and files the approved ones into the customer's own Jira. I integrated a proven graph engine for parsing and built the audit, synthesis, and delivery layer on top, which is where the value sits. Nothing writes to the customer's tracker without a human approval.
Toggle between the presentation architecture render and an interactive explorer where you can hover any node for the design rationale. Click either to maximize.
> functional requirements
- Plan a full technical audit of an unseen codebase and spawn specialist agents per domain
- Four audit agents: dependency mapping, security, architecture review, and dead-code detection
- Synthesis reconciles conflicting findings, prioritizes them, and surfaces the highest-leverage non-obvious risk
- Route approved findings into the customer's Jira as prioritized tickets with evidence and a recommended fix
- Re-run reconciliation against a persistent knowledge bundle: update, close, or create only new tickets
> non-functional requirements
- A human approval gate before any write to the customer's tracker: nothing lands unreviewed
- Idempotency through stable finding fingerprints, so a re-run never duplicates tickets
- Least-privilege auth scoped only to the projects the delivery agent needs, no admin
- Open-source reuse disclosed openly; the persistence format kept swappable behind an interface
> scale + capacity
- The codebase does not fit in context, so adaptive hybrid retrieval feeds the agents rather than a single prompt
- Incremental dependency graph and an OKF bundle read first on re-run, so repeated audits update a living picture instead of starting cold
- Audit domains run with a defined order and parallelism: mapping first, security and architecture in parallel, dead-code last, then synthesis
> key tradeoffs
- Integrated a proven graph engine rather than rebuilding a solved layer, so the build goes into the audit and delivery, which is where the value sits
- Adaptive hybrid retrieval over a single strategy, because code is full of exact identifiers that dense retrieval alone misses
- Jira via MCP for agent-facing tool calls, with the direct REST API only where MCP does not expose a needed field
- A human approval gate costs a step, but it is the trust boundary that makes writing to a customer's production tracker acceptable
A single-tenant control plane for running agents against real work. Every model call goes through one function so it can be accounted for and capped, dispatch is a durable Postgres queue so work survives a crash, and the reporting graph is kept acyclic by the database inside the write transaction rather than by convention.
Hover any node for the design rationale. Click to maximize.
> functional requirements
- Register departments and employees, with the reporting graph rendered from the registry
- Dispatch agent work as durable jobs that survive a process crash
- Route every model call through one function, across seven providers with automatic failover
- Record a ledger row per model-call attempt, including attempts that fail
- Enforce a kill switch, a daily spend ceiling, and a per-model price ceiling
> non-functional requirements
- Failed calls are still accounted for, so cost data has no silent gaps
- Structure is enforced by the database: a recursive CTE inside the write transaction refuses a cycle in the reporting graph
- A per-attempt deadline on every provider call, so one hung provider cannot block the chain
- A CI check fails the build if any code bypasses the model-call gateway
- Idempotency keys and resumable checkpoints, so a retry does not duplicate work
> scale + capacity
- Claiming uses FOR UPDATE SKIP LOCKED, so workers take disjoint job sets without blocking each other
- Leases are reclaimed after a crash rather than leaving jobs stranded
- Exponential backoff with jitter on retries, with terminal failures routed to a dead-letter queue
- Verified at 100 concurrent ID issues with zero collisions
> key tradeoffs
- Postgres as the queue rather than a separate broker: one datastore to operate, and the queue shares transactions with the data it touches
- One mandatory call function is a constraint on every caller, but it is the only way the accounting and the ceilings hold
- Model IDs verified by live probing rather than vendor documentation, after probing found a model that hangs 194 seconds before dying and a free tier returning 403 while its dashboard still advertised it
- Free-first provider ordering trades predictable latency for cost, which the per-attempt deadline bounds
- 78 acceptance checks run against a live Postgres instance rather than mocks: slower to run, but they exercise the concurrency and transaction behaviour the design depends on