Architecture Portfolio

Case studies from real work — how the systems were shaped, not just what shipped. This portfolio collects an upstream contribution to the official Go implementation of the Microsoft Agent Framework and a set of original, interactive fintech architecture diagrams that document the ledger and payments patterns behind money movement. Each entry states the context, the architecture, and the key trade-offs, and links to the artifact you can inspect yourself.

202
Upstream PRs (99 merged)
10
Interactive Architecture Diagrams
2
Reference Implementations

Microsoft Agent Framework Go

Architecting and hardening an open-source contribution to microsoft/agent-framework-go — the official Go implementation of the Microsoft Agent Framework for building AI agents and multi-agent workflows.

Context

Two authored reference implementations built on this framework — Genie, a multi-agent financial assistant, and Bodh, a medical diagnostic panel — surfaced runtime issues that only appear under real parallel tool use. Rather than work around them locally, the fixes were driven upstream.

#Go #Open Source #Multi-Agent AI

Architecture

Work spans the full framework surface: the agent runtime and middleware (tool approval, agent mode, skills), the workflow routing engine, and the model providers — OpenAI, Anthropic, Azure AI Foundry, Gemini, Copilot, A2A, AG-UI, and MCP. The recurring theme is concurrency- and stream-sensitive code where a missing guard only fails in production.

#Runtime #Providers #Workflow Engine #Streaming

Key decisions & trade-offs

Every change targets runtime correctness — data-race and nil-safety fixes, streaming-protocol correctness, and request-path validation — and each lands with a regression test that fails before the change and passes after. Fixes are aligned to the .NET and Python SDKs so behavior stays consistent across languages rather than diverging in the Go port.

#Data Race #Nil-safety #Cross-SDK Parity #Regression Tests

Fintech Ledger & Payments Architecture

A set of original, self-contained interactive diagrams documenting the core patterns behind money movement — from how a rupee travels across a four-party payment network to how a ledger stays correct under contention. Each diagram is a working artifact: open it, step through the flow, and read the design decisions inline. Together they form a reference for building payment and ledger systems that are exact, auditable, and safe under failure.

UPI Money Flow (India)

Context: A single UPI payment touches four parties and multiple hops before money actually moves. Architecture: The diagram traces the 4-party PAY (push) flow — VPA resolution, PIN authorization, the debit and credit legs, and deferred net settlement between banks — showing where authorization ends and settlement begins.

#Payments #UPI #Settlement

Double-Entry Postings

Context: A ledger that can silently lose money is worse than no ledger. Architecture: Every transaction fans out into balanced postings that net to zero, then updates derived balances — the double-entry invariant that makes the books provably consistent and every movement traceable to its offsetting leg.

#Ledger #Double-Entry #Invariants

Event Sourcing: Fold Over an Append-Only Log

Context: Financial state needs a defensible history, not just a current value. Architecture: State is modeled as a fold over an immutable event log; corrections are new compensating events, never edits or deletes — so the audit trail is the source of truth and any past state can be reconstructed.

#Event Sourcing #Append-Only #Auditability

Transactional Outbox & Reconciliation

Context: Writing to a database and publishing an event are two operations that can't share one transaction. Architecture: An atomic dual-write via an outbox table gives at-least-once delivery, and the books are periodically reconciled against the outside world to catch anything the delivery path missed.

#Outbox #Reconciliation #At-Least-Once

Maker-Checker Approval

Context: High-value money movements need control, not just correctness. Architecture: A four-eyes segregation of duties where the maker of a money movement can never approve it — the request and the approval are separate authenticated actions, enforcing control that a single compromised actor cannot bypass.

#Maker-Checker #Segregation of Duties #Controls

Idempotency Keys

Context: Networks retry, and a retried payment must not move money twice. Architecture: The first request with a given key performs the effect exactly once; any replay of the same key returns the stored result with no new side effect — making the money-movement path safe to retry end to end.

#Idempotency #Exactly-Once #Retries

Hotspot / High-Contention Accounts

Context: A single hot balance row — a merchant float or fee account — becomes the bottleneck under load. Architecture: The diagram contrasts two fates for the same posting load: one contended balance row versus sharded sub-accounts with buffered posting and periodic roll-up, trading immediate balance precision for throughput.

#Contention #Sharding #Throughput

Money Transfer Lifecycle

Context: A transfer is rarely a single instant — it moves through reservation, posting, and settlement. Architecture: The transfer is modeled as an explicit state machine — reserve, post, clear, settle — with first-class handling for settlement failure and reversal, so no state transition is implicit or unrecoverable.

#State Machine #Transfers #Reversal

Representing Money

Context: Floating-point money is a bug waiting to happen. Architecture: Money is represented as integer minor units paired with currency and scale, kept exact and auditable end to end — so rounding, currency mismatches, and precision loss are structurally impossible rather than caught by review.

#Money Representation #Precision #Currency

Handling Webhooks Safely

Context: An inbound payment webhook is untrusted input that also drives money movement. Architecture: Treat every webhook as hostile — verify the signature, dedupe by event ID, acknowledge fast, process asynchronously, and re-read the truth from the provider rather than trusting the payload — so a spoofed or replayed callback can't corrupt state.

#Webhooks #Security #Async Processing

Cross-cutting principles

  • Correctness is structural — money is exact by representation, and the ledger nets to zero by construction, not by convention
  • Every money-movement path is safe to retry and safe to fail — idempotency keys, state machines, and reconciliation assume the network and the outside world will misbehave
  • The history is the source of truth — append-only events and double-entry postings mean nothing is edited in place and everything is auditable
  • Controls are designed in — segregation of duties and hostile-input handling are part of the architecture, not a later hardening pass

Selected Projects

Beyond these case studies, the project portfolio collects the reference implementations and delivered systems behind the architecture work — from open-source multi-agent platforms to production systems shipped for enterprise and consumer markets.

Reference Implementations

Genie is a Go-based multi-agent financial assistant with role-specialized agents, JWT + RBAC, AES-256-GCM encryption, and OpenTelemetry tracing. Bodh is a virtual physician panel on the Microsoft Agent Framework, FHIR R4 and HL7 v2 aware. Both are the codebases that surfaced the upstream framework work above.

#Go #Microsoft Agent Framework #Multi-Agent AI

Cloud & Data Infrastructure

Core contributor to HarbourBridge, Google's open-source Spanner migration tool — backend APIs, CDC pipelines, and query optimization. Alongside it, delivered systems spanning BigQuery FinOps, high-throughput transaction engines, and open-banking platforms.

#Cloud Spanner #CDC #Distributed Systems

Explore Further

Dive into the upstream contribution log, the full project portfolio, or get in touch about architecture work.

Microsoft Agent Framework Go All Projects Contact Me