A financial technology platform processes millions of dollars in transactions daily across credit cards, cryptocurrency, ACH, Interac, and a dozen other payment methods. The system that powers it has been in production for over two decades—the oldest code still in the repository targets .NET Framework 2.0, and the platform has been processing live transactions since before Entity Framework existed. Much of the critical business logic lives in over 5,500 stored procedures spread across two databases, routing decisions buried in nested T-SQL that no single person fully understands.
Modernizing this system is not optional. But doing it without breaking live payment processing requires a level of precision that makes most teams move slowly, cautiously, and expensively.
This is the story of how one engineer, armed with an agentic AI workflow built on Anthropic's Claude and the Model Context Protocol, went from onboarding to producing more merged code per month than anyone else on the team—while maintaining a 99.4% non-revert rate.
The challenge
The platform belongs to a North American enterprise in the regulated financial services sector. The numbers tell the story of complexity: over 7,300 C# source files comprising roughly 680,000 lines of code, spanning .NET Framework 2.0 through .NET 9.0 across sixteen solutions and 115 projects. The two primary databases contain over 1,100 tables and 5,500 stored procedures between them. Nearly 1,800 Entity Framework entity models map to those tables. The legacy WCF layer alone includes 48 distinct payment processor integrations—each one wired differently, documented inconsistently, and modified by different people over different years.
The payment processing pipeline implements 47 discrete business rules across 6,400 lines of code: BIN blocking, geographic restrictions, velocity limits, customer tenure checks, processor capacity balancing, cross-customer card validation, and more. A single misrouted transaction is a financial incident. The team needed to achieve bug-for-bug compatibility with legacy behavior while simultaneously improving the architecture.
The modernization goal was clear: migrate critical business logic from stored procedures and WCF services into Clean Architecture C# using Entity Framework Core. The motivation was equally clear—the stored procedures were undocumented, their interactions opaque, and the tribal knowledge required to maintain them was concentrated in a small number of long-tenured employees. When those people were unavailable, work stalled.
But this was not a greenfield effort with a dedicated migration team. It had to happen alongside ongoing feature development, production support, and regulatory compliance—carried out by engineers who also had other responsibilities.
The approach
Rather than treating AI as a coding autocomplete, the team built a comprehensive agentic workflow that gave Claude deep, contextual access to the entire development ecosystem. The architecture centered on three layers: structured project knowledge, custom skill automation, and a centralized MCP (Model Context Protocol) server for cross-system integration.
Structured Project Knowledge
At the foundation, detailed instruction files were maintained at multiple levels—global developer preferences, repository-wide conventions, and solution-specific context including database schemas, architectural standards, and anti-hallucination rules. These were not generic documentation; they encoded hard-won lessons like "the migrated C# pipeline is the source of truth, not the legacy SQL stored procedures" and "use SCOPE_IDENTITY() not OUTPUT INSERTED because of triggers on key tables." A persistent memory system tracked ongoing project state, skill gaps, and feedback corrections across sessions.
Custom Skill Automation
Seventeen purpose-built skills transformed repetitive multi-step workflows into single commands. /starttask 54321 would pull the latest code, fetch the work item from the project management system, extract a title, create a git worktree with a correctly formatted branch name, and push to establish remote tracking—all respecting Windows path length constraints that had burned the team before. A PR review command launched five parallel review agents (standards compliance, bug scan, git history context, test quality, and requirements gap analysis) that each independently analyzed a pull request diff against the project's specific coding standards, then aggregated findings with confidence scores. A finalize command handled the commit-squash-push-PR-creation pipeline end to end.
These skills were not generic templates. The PR review skill, for instance, knew to ignore EF model null! property initialization (a standard EF pattern that looks like a bug to a naive reviewer), knew that controllers are allowed top-level try-catch for API response formatting, and understood the project's specific test ordering requirements for integration tests that share database state.
The MCP Server Ecosystem
The centerpiece was an internally built MCP library—a .NET solution of eight projects hosted on ASP.NET Core with IIS and Windows Integrated Authentication. It comprised:
- A Discovery MCP that served as a self-service catalog of available AI tools with access control via Active Directory groups, plus a REST endpoint that returned merged context based on filesystem path pattern matching
- A Knowledge MCP that provided semantic search over the company's internal wiki (~2,000 pages) using Qdrant vector search with locally-hosted embeddings, with a background indexer on a fifteen-minute incremental cycle
- A DevOps MCP that exposed the on-premises Azure DevOps Server API as a structured reference, covering work items, pull requests, git operations, wiki pages, builds, and releases
- An AI Chat interface that integrated all of the above plus connections to CRM, ticketing, and payment APIs—giving non-technical staff access to the same corporate knowledge through a web frontend
- A Host Orchestrator that read MCP server configurations from the database and spawned each as an in-process web application, managing lifecycle, crash recovery, and graceful shutdown
When a developer opened a Claude session in the payment processing subdirectory, a SessionStart hook automatically called the Discovery MCP's context endpoint, which matched the working directory path against glob patterns and returned merged context organized by priority. This happened silently, without the developer doing anything. The result was that every session, across all 39 active worktrees, started with exactly the right context for the code being worked on.
Key technical decisions
MCP over alternatives
The team evaluated Azure API Center, open-source MCP gateways, and commercial platforms before building custom. The rationale was pragmatic: they were a .NET shop with ASP.NET Core expertise, needed tight integration with on-premises systems behind corporate firewalls, and required Windows Integrated Authentication—something no off-the-shelf solution handled natively. HTTP/SSE transport was chosen over stdio because the added latency was negligible compared to LLM inference time, while central hosting enabled unified authentication, logging, and updates without touching developer machines.
Safety and governance by design
The system enforced clear boundaries at multiple levels. Database queries defaulted to the staging environment, with explicit opt-in required for the shared dev server. The settings configuration whitelisted specific command patterns—database queries and API calls were permitted, but destructive operations required explicit approval. Anti-hallucination rules were embedded directly in the project context: "Never reshape evidence to fit earlier assumptions," "Avoid vague guesses; use 'Unclear; need to inspect X,'" and "Cross-reference constantly to maintain global coherence." The AI Chat interface restricted access to a named allowlist of users. Desktop notifications alerted the developer when long-running AI tasks completed, keeping the human in the loop without requiring active monitoring.
Feature flags for gradual migration
Each stored procedure migration was deployed behind a feature flag, allowing the legacy and modern paths to run side-by-side in production. This pattern let the team validate behavioral equivalence with real traffic before cutting over. The AI workflow understood this pattern and applied it consistently to each new migration.
Multi-agent review architecture
The PR review workflow split analysis across five specialized agents running in parallel, each focused on a different concern: standards compliance, bug detection, git history context, test quality, and requirements gap analysis against linked work items. This was a deliberate design choice to prevent context bleed where a model fixating on one issue class misses another. Each agent received the same diff but different instructions, and their findings were aggregated with confidence scores, filtered against known false-positive patterns, and presented with the option to post directly to the pull request as categorized review threads.
Results
The velocity numbers are unambiguous. The engineer adopting this workflow joined the project in August 2025 with 5 commits that month. After adopting the AI-augmented workflow in late October, output jumped to 82 commits in November—a twelve-fold increase. Over the following five months, they averaged 74 commits per month across all branches, with 55 pull requests merged to main. The overall team's merged throughput on the main branch increased approximately 48% in the post-adoption period compared to the prior year.
These were not trivial changes. The work included:
- The foundational EF migration—a single PR touching 1,973 files with 127,453 insertions, a complete structural migration of the payment processing service
- Thirteen payment callback migrations—each migrated from the legacy Payment API to the new EF-based service as individual, reviewable PRs. Each involved understanding the processor's specific protocol, mapping SP parameters to EF entities, writing integration tests, and deploying behind feature flags
- A complete ML-based payment routing system built from scratch—including selection strategy, training pipeline, QA endpoints, reporting dashboard, emergency shutoff, and iterative model retraining. Eleven commits delivered a wholly new capability
- Business rule migration—47 pipeline rules migrated from nested T-SQL to discrete, testable C# classes. The AI workflow read source SP definitions, cross-referenced with existing C# pipeline rules, and identified behavioral gaps
- Fraud Risk Management migration—a complex migration from stored procedures to a C# API with a new decline patterns UI, delivered as a single coherent PR spanning 46 files with 4,163 insertions
Quality did not suffer. Across the repository's 1,591 commits, only 9 were reverts—a 0.6% revert rate. Four of those were a single feature's revert chain, not a pattern of instability.
The 39 active git worktrees paint a picture of parallel development that would be unmanageable without automated context management. Each worktree had its own AI session with automatically injected project context, its own branch following strict naming conventions, and its own link back to the work item that justified its existence.
Organizational adoption
What began as one engineer's workflow became an organizational shift. After demonstrating the results, the approach was widely adopted across the engineering team. Developers now collaboratively maintain shared skill libraries, hook configurations, and project instruction files—treating AI workflow infrastructure as a shared codebase in its own right. Teams contribute domain-specific context for their areas of the platform, review and refine each other's automation, and build on the MCP server ecosystem for their own use cases. The methodology has changed how work gets done across the organization—not as a top-down mandate, but as a bottom-up adoption driven by visible results.
Lessons learned
Context is the product, not the model
The most impactful investment was not in prompt engineering or model selection but in building the infrastructure that gave AI accurate, comprehensive context about the codebase, the databases, the business rules, and the team's specific conventions. A model without context generates plausible but dangerous code in a legacy enterprise system. A model with deep context—the right instructions, the right database schemas, the right anti-patterns to avoid—generates code that experienced developers review and merge with confidence.
Encode corrections, not just instructions
The persistent memory system proved essential. When the AI made a mistake—using OUTPUT INSERTED instead of SCOPE_IDENTITY(), or catching exceptions it couldn't handle—the correction was saved as a durable memory with explicit reasoning. This meant the same mistake never happened twice, across sessions, across worktrees, across weeks of work. Traditional documentation tells you what to do; feedback memories tell the AI why not to do the thing it's about to do.
Invest in the seams, not the center
The highest-value automation was at the boundaries between systems—the skill that fetched a work item, created a branch, and set up a worktree; the hook that injected context at session start; the review workflow that pulled diffs, cross-referenced requirements, and posted findings back to the PR. The actual code generation was, in some sense, the easy part. What made the workflow sustainable was eliminating the friction of switching contexts, remembering conventions, and maintaining consistency across dozens of parallel workstreams. The model writes code; the infrastructure makes sure it writes the right code, in the right place, for the right reasons.