What I do
Five practices, one job
These are usually five different people. Keeping them in one head is the point — a platform decision that ignores its own cost model gets rebuilt, and a cost model written by someone who has not built the platform gets ignored. The first two are what I build; the last three are what gets them funded. Most readers care about one half, and the argument only works with both.
Agentic AI platform
A fleet of Model Context Protocol servers in production on Azure Container Apps, each one tailored to the workflow it serves rather than to a generic integration — pricing, licensing, architecture, meeting intelligence, biomedical evidence. The server goes to where the work already happens.
The work is the pattern, not the instances: identity, secret handling, retrieval, extraction, evaluation and telemetry are structural decisions made once, so the next server is configuration rather than a project.
Retrieval & knowledge systems
Getting an agent to find the right passage in a corpus nobody has curated, and to know when it has not. Hybrid retrieval — dense vectors and full-text, fused by rank rather than score, with authority-tier boosting and structure-aware chunking. pgvector with HNSW and DiskANN, on benchmarked recall rather than assumed recall.
Above it, an evidence-first knowledge graph across three Microsoft 365 tenants, where an extracted decision is only recorded if two independent sources agree. 25,000 verbatim source turns yielded 842 decisions — and that ratio is the point. Cross-tenant entity resolution, with human corrections that survive a full rebuild.
Cloud economics & FinOps
Built the cloud economics practice at Microsoft that seeded its FinOps Foundation participation, and authored the five-hour required course delivered to 18,000 field personnel.
A single FOCUS-schema catalog across AWS, Azure and GCP prices a workload before it moves and tracks what it actually costs once it has — projection and reconciliation as two ends of the same problem, across tens of millions of rows. The same rate-versus-usage discipline now applies to token spend, model routing and AI platform TCO.
Enterprise architecture & migration
Target-state architecture and migration sequencing derived from process- and network-dependency-level estate analysis: datacenter exit, VMware renewal, post-reorganization consolidation — programs where a fixed contractual date and a cost delta decide whether anything is funded at all.
The output is not a diagram. It is an approved capital plan, signed by a CIO and a CFO who each had to believe a different half of it.
Reducing technical debt
Most AI programs are not short of budget — they are short of budget that is not already committed. The work is finding run-rate funding workloads nobody would provision that way today: entitlement value already bought under Software Assurance, constrained-instance sizing for memory-bound databases, hyperthreading disabled to cut billable vCPU, and 6R disposition set against measured utilization rather than a CMDB — and in the estates I have seen, a CMDB is about 70% accurate.
Recovering the money is the easy half. It does not become a modernization budget on its own — finance reclaims it unless the reinvestment is approved in the same decision that approved the cut. So the deliverable is one funding case carrying both halves, not a savings report followed by a separate ask six months later.
Then there is the double mortgage: for the length of a migration you are paying for the current state, the end state, and the program moving between them. It is the objection that stalls more transformations than any technical risk, and it is a sequencing problem, not a negotiation. Shorten the overlap per workload instead of per program; make decommission a funded deliverable of each wave rather than a follow-up nobody owns; put the highest run-rate workloads in wave one so early savings pay for later waves; and time commitment purchases to steady state, not to the ramp. Track double-run days as a number someone is accountable for and it stops being a surprise in month seven.
A worked example
Taking the platform to where the expertise already is
The pattern above is only worth anything if an instance of it survives contact with someone who actually knows the domain. This one did.
I deployed a biomedical Model Context Protocol server on Azure for a researcher working in gene therapy — curated public evidence (PubMed, ClinicalTrials.gov, ClinVar, OncoKB) exposed as typed genes, variants, trials and biomarkers rather than as pages to read. Over 100,000 abstracts behind a tool call that answers in the shape the question was asked in.
It was not built for her use case. Adapting it — the sources that mattered, the shape of the answers, what the tools had to refuse to guess at — was the entire job, and it is the part that does not appear in any architecture diagram. A practitioner now depends on it in her day-to-day work, which is a far harder test than any evaluation harness I could write.
That is the argument for putting the engineer next to the expert instead of behind a requirements document. The platform pattern makes the second deployment cheap; the time spent in someone else's problem is what makes it correct.
How I build
Opinions, held for reasons
Every one of these is a position I changed my mind into. The reasoning matters more than the rule.
The model is a pipeline stage, never a source of truth
Deterministic joins execute first; the model receives resolved facts and emits assertions about them. It is not asked to remember, look up, or do arithmetic. Source validation refuses to emit a value it cannot verify — an empty field with its evidence attached is worth more than a confident wrong number.
Fuse by rank, never by score
Different query framings have different mean similarity to a corpus and different spread. Fusing raw cosine elects whichever framing sits highest in the space; fusing z-scores elects whichever has the tightest distribution. Neither elects the best match. Reciprocal Rank Fusion uses only position, so no distributional quirk can dominate and agreement across framings is what gets rewarded.
Provenance in the schema, not in the documentation
Every model-derived record carries the prompt version and model id that produced it, so an extraction run is diffable rather than silently replaced. Provenance added after the fact is a document; provenance in the schema is enforcement — and it is the control posture regulated model-risk functions ask for anyway.
Measure the thing, then believe the number
A four-axis LLM-as-judge harness scores correctness, authority, evidence and defensibility across a versioned question suite, and separates engine defect from source coverage gap. A system that cannot tell "we answered badly" from "we do not hold the answer" will optimize the wrong half. The corollary is unglamorous: most of my worst bugs raised no error at all, and were found by reading the artifact rather than the report.
Cost is a design constraint, beside latency and reliability
Tiered model selection with documented rate-limit and cost rationale; a smaller model as the extraction default with a defined escalation path; forced tool-use for schema-valid output, because a retry on malformed JSON is a bill as well as a delay. Reconciling this after the invoice arrives is too late to change the architecture.
The long-form version of this — the standardized server pattern, the retrieval and guardrail decisions, and a candid section on what it does not do — is written up as an architecture specification.
How I got here
Five problems, in the order the industry handed them to me
The dated version of this is on LinkedIn. What follows is the part a job history leaves out — what each of these actually taught, and why the next one followed from it.
Making the internet something a company could sell
I started at MCI on the first release of InternetMCI — public internet access, at a point when most of the argument was still about whether anyone would want it. I had arrived there partly by way of reverse-engineering early networks to build a multiplayer game, which was an unserious motive for learning a very serious skill.
The formal work was technology evaluation: VoIP over H.323 and SIP, video on demand, and the risk and benefit analysis behind them — delivered to a CTO and a CFO who needed the same facts framed two different ways. That is the oldest habit I have, and it turns out to be the whole job three decades later.
Learning that architecture ends where the pager begins
At the Microsoft Partner Solutions Center I built a multi-tenant facility of twelve independent customer lab environments, each emulating a large-scale datacenter, and led the eight-person staff that ran the whole thing. I was lead architect for its network, security and application services, and later owned Windows Core Networking security services — RADIUS/IAS, 802.1x, DHCP.
Then Xbox Live Operations, and a team carrying real consumer load. We replaced manual monitoring with programmatic tooling because the alternative was asking humans to be reliable at 3am, which is not a design. Everything I now believe about observability and about guardrails came from operating something, not from drawing it.
The hard part stopped being technical
Cloud made capacity easy and made money the binding constraint — and almost nobody was equipped to reason about it. So I built the cloud economics practice inside Microsoft: the commercial models, the governance constructs, the optimization methodology. It became the company's FinOps Foundation involvement, and I wrote the five-hour course that 18,000 field personnel were required to take.
Consumption pricing models, fiduciary frameworks that let enterprises experiment without writing a blank check, licensing constructs piloted and then scaled across industries. Also a great deal of buy-versus-build analysis, which is mostly the discipline of talking people out of building things.
Sitting between a CIO and a CFO, who need different things to be true
Years of engagements across financial services, public sector, retail, manufacturing and healthcare — turning an ambiguous infrastructure inventory into a migration plan that is architecturally sound and gets funded. Scenario models for IaaS and PaaS investment. FinOps frameworks joining procurement, engineering, security and finance through cost-accountability measures they could all actually agree on.
The recurring lesson: a technically correct plan that nobody will pay for is not a plan. The economics are not a wrapper around the architecture — they are part of it, and the architect who cannot speak both is going to lose arguments they should win.
Agent infrastructure, with the same discipline pointed at inference
Model Context Protocol servers in production, hybrid retrieval, typed extraction, an evaluation harness that separates a bad answer from a missing source. A standardized server pattern rather than a pile of integrations, because I have maintained the pile version and it does not end well.
And the economics come along: tiered model selection with an actual rationale, forced tool-use so a malformed response is not billed twice, cost sitting beside latency and reliability where it belongs. Three decades of the layer underneath is why the new layer looks familiar rather than magical.
Range
Where this has been applied
Breadth matters more than any single engagement — most of what I know about a pattern came from watching it fail in an industry it was not designed for.
Industries
- Financial services & insurance
- Healthcare and life sciences
- Public sector
- Manufacturing
- Retail
- Telco, cable & service providers
- Gaming and consumer services
Problems I get called for
- Datacenter exit against a fixed contractual date
- VMware / Broadcom renewal decisions
- Post-reorganization and post-merger consolidation
- Enterprise agreement and licensing renewal
- Regulated-environment architecture and compliance
- Buy-versus-build, before the build starts
- Modernization funded from run-rate, not new budget
- AI platform standardization and governance
Who I work with
- CIO and CTO organizations
- CFO and finance, on capital planning
- Procurement and vendor management
- Security and risk functions
- Delivery and platform engineering teams
- Partner and channel ecosystems
Recognition
- FinOps Certified Practitioner (FOCP), The Linux Foundation
- Collaborator, Cloud Adoption Framework for Azure
- Disaster Response Team MVP — Haiti earthquake, H1N1, Cyclone Nargis (Microsoft & United Nations)
Teams
Architecture is not the only thing that has to be built
Direct management
Twelve-person Xbox Live Operations team, an eight-person datacenter staff operating the Partner Solutions Center, and a four-FTE global business intelligence group.
Mentoring
More than thirty formal mentoring engagements with incoming senior staff, across two decades — most of them people who now do this better than I do.
Practice building
Repeatable assessment patterns and architecture standards adopted across a U.S. delivery practice and its partner ecosystem; a governance discipline adopted company-wide at Microsoft.
The through line
Thirty-three years of automation, aimed at a new substrate
Agentic AI is not a field I arrived at last year. It is the current form of the work I have been doing since InternetMCI: take something people do by hand, understand it well enough to encode it, and make it survive production.
The substrate keeps changing. The discipline does not. The operations tooling that replaced people watching dashboards at 3am, the pricing models that turned a spreadsheet argument into a funded decision, the estate analysis that made a datacenter exit achievable — same problem, different decade. Some of it worked on the first attempt. Some of it failed in ways that took months to understand, and those are the ones I still design around.
Provenance carried in the schema. Evaluation that separates a bad answer from a missing source. Cost sitting beside latency and reliability. None of those are AI ideas — they are what three decades of shipping systems that had to keep working after I left the room actually taught. The models are new. Knowing what to demand of them is not.
I compose hosted models and I am opinionated about everything around them. That is the work I want, and it is the work I have been training for since before it had a name.