What I do
Four practices, one job
These are usually four 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.
Agentic AI platform
Model Context Protocol servers in production on Azure Container Apps — agent-callable tools over pricing, licensing, architecture, meeting intelligence, and a biomedical evidence layer bridging curated public sources into typed genes, variants, trials and biomarkers.
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
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: cross-tenant entity resolution, human confirmations that survive a full rebuild, and extracted decisions that require two independent sources before they are recorded.
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, at multi-million-row scale. 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.
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 twelve people 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 cheque, 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. Thirty years 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
- 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)
- Microsoft Ship-It awards, major product releases
- Microsoft Circle of Excellence
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.