30 years in enterprise infrastructure · Cloud Advisory · Applied AI

I build AI systems.
I also sell the engagements
that pay for them.

My background is enterprise technology consulting — cloud migration strategy, infrastructure rationalization, post-M&A assessments, TCO modeling for Fortune 500 clients. That work funded the time to go deep on applied AI, and the two things feed each other now. The advisory work makes the AI more grounded. The AI work makes the advisory more defensible.

I don't just recommend things. I build them, deploy them, and operate them in production — mostly solo, on tight budgets, where the architecture has to be right because there's nobody else to fix it. That constraint is actually useful. It produces systems that are simpler, cheaper, and more maintainable than what you get from a team with unlimited scope.

What 30 years of infrastructure actually means

The 30 years covers the full arc: on-premises datacenters, storage area networks, VMware and Hyper-V virtualization, Windows and Linux server environments, enterprise networking, and the first wave of cloud migration starting in the mid-2010s. AI is the most recent chapter, not the whole story. That matters because most of the hard problems in enterprise AI aren't model problems — they're infrastructure and data problems, and I've been solving those for a long time.

The consulting piece ran in parallel. For several years at a global systems integrator, I led cloud advisory engagements across industries — insurance, banking, healthcare, retail, CPG, hospitality, government. The work was CRAs, TCO models, cloud business cases, application rationalization, post-M&A assessments. I've helped clients identify over $57M in infrastructure savings across 14 engagements, executed 10 SOWs, and scoped migration programs ranging from a 5-week banking CRA to a 5-month Fortune 500 DC exit with 60,000+ servers. The Selling section of this site documents those engagements in detail, all anonymized.

Since 2024 I've been building applied AI systems — not as a hobby project, but in production. Park Whisperer is my personal AI platform: real-time theme park intelligence running 24/7 across Azure, GCP, and AWS, processing satellite weather data, training ML models, running a multi-agent knowledge RAG, and publishing daily AI-generated content to social platforms. Solo, under $100/month. I use it to stress-test architectural patterns before recommending them to anyone else. The Portfolio and Clients pages document how those patterns translate into client work.

Applied AI & engineering work

Agentic AI Systems
Multi-agent · Tool-use · RAG
Multi-agent pipelines with tool libraries, retrieval-augmented generation over structured and unstructured data, SLM-based intent routing, and multi-model collaboration patterns (cheap model for synthesis, capable model for output). I've built agentic systems on AWS Bedrock, Azure AI Foundry, Azure Functions, and n8n.
Cloud migration intelligence Park Agent Chat Seller Intelligence Knowledge RAG
ML Pipelines & Forecasting
scikit-learn · Prophet · LightGBM · BigQuery
End-to-end ML systems: feature engineering, training pipelines on BigQuery data warehouses, model serialization to GCS, and inference services that serve predictions every 20 minutes. Time-series forecasting for operational systems where latency and cost matter more than marginal accuracy gains.
Weather ML (6 models, 44K obs) Ride Whisperer forecasting Venue impact prediction
AI-Generated IaC & Deployment
Kiro · Bicep · CloudFormation · Terraform
Using AI-powered development tools (Kiro, GitHub Copilot) to generate production-grade infrastructure from specification — Bicep modules, CloudFormation stacks, Cloud Run job definitions, Container App configurations. I've deployed the same application logic to AWS and Azure via AI-generated IaC with zero forked business code.
EARE AWS + Azure Advisory AI AWS + Azure Gov-Process SaaS
Data Engineering & ETL
PostgreSQL · BigQuery · Azure Cosmos DB · pgvector
Real-time data pipelines that run on tight cadences (5–10 minutes), upsert semantics with deduplication, event-driven processing, and warehouse-scale historical data for ML training. Experience across three cloud data platforms and a full cycle of architecture evolution — including the hard lesson of when not to use a NoSQL document store.
Park Data Ingest ETL GOES-18 Lightning Ingestion METAR/Radiosonde pipeline Data Pipeline Evolution
AI Content Operations
Automated content factory · Video · Multi-platform
Scheduled AI pipelines that produce and publish social media content, blog posts, and short-form video with no human touch. ElevenLabs TTS with per-character timestamp alignment, FFmpeg video encoding, word-sync caption generation, and direct API publishing to Instagram, TikTok, and YouTube Shorts.
SLM Content Pipeline AI Video Production Team Multi-Model Content
AI Governance & Compliance
ISO-42001 · NIST AI RMF · SDLC gates
Enterprise AI governance platforms that scan codebases, generate compliance artifacts across 10 regulatory frameworks, and enforce gate-based approval workflows. For clients in regulated industries (healthcare, financial services) where AI deployments require documented provenance and auditable decision chains.
Advisory AI Governance Platform Provenance-by-construction AI Gov-Process SaaS

What I've actually shipped it with

Cloud Platforms
Microsoft AzureFunctions · Container Apps · AI Foundry · Cosmos DB
Google Cloud (GCP)BigQuery · Cloud Run · GCS · Cloud Scheduler
Amazon Web ServicesBedrock · Lambda · DynamoDB · CloudFormation
AI / ML
Claude (Anthropic)Sonnet / Haiku · via Bedrock + Azure
OpenAI / GPT-4oEmbeddings · Assistants API · Azure OpenAI
Phi-3 / Phi-4 MiniSLM intent routing · fine-tuning
scikit-learnRandomForest · GradientBoosting · 6 models
LightGBM / ProphetTime-series forecasting
LangChainAgentic loops · tool orchestration
ElevenLabsTTS · timestamp-aligned audio
Data & Storage
PostgreSQL + pgvectorHNSW index · hybrid BM25+vector search
Google BigQueryData warehouse · ML training · ST_DISTANCE
Azure Cosmos DBNoSQL · vector search · Gremlin graph
RedisCaching · pub/sub · session state
Azure Blob / GCSML models · JSON API · video assets
Infrastructure & Deployment
Bicep / ARMAzure IaC — AI-generated via Kiro
CloudFormationAWS IaC — AI-generated via Kiro
TerraformGCP infrastructure · BigQuery · Cloud Run
Docker / Container AppsContainerized jobs · multi-stage builds
GitHub ActionsCI/CD · container build/push · deploy
n8n / CaddyWorkflow orchestration · reverse proxy
Languages & Frameworks
PythonPrimary — ML · pipelines · agents · ETL
TypeScript / Node.jsGovernance platform · SaaS API · Fastify
SQL (BigQuery + PG)Complex views · window functions · spatial
FFmpeg / PillowVideo encoding · image compositing
FastAPICustom microservices · agent backends
Data Sources & APIs
NOAA GOES-18 GLMSatellite lightning · NetCDF · L2 Flash
FAA METAR / aviationweather.govSurface weather obs · 17 stations
NWS / SPC APIsActive alerts · categorical outlook
UWyo Radiosonde ArchiveUpper-air soundings · CAPE/LI/K-Index
ThemeParks.wiki API286 WDW entities · live wait data

Numbers across the work

24+
Case studies documented
14
Advisory pursuits · 10 SOWs executed
$57M+
Infrastructure savings identified
44K+
ML training observations
1.6M+
RAG knowledge records
<$100
Monthly cloud spend · Park Whisperer platform
Token economics as a design constraint

Before a model is called, I've already decided: what context is strictly necessary, what can be cached or pre-computed, which model tier matches the actual reasoning demand, and what value the output delivers per dollar spent. That trade-off is explicit in the architecture — not discovered after the bill arrives.

Model selection — match reasoning tier to task complexityClaude Haiku vs. Sonnet vs. Opus is a cost decision
Context window discipline — minimal sufficient context, not maximum availableSmaller prompts = lower latency + lower cost
Caching & pre-computation — static reasoning done once, not per-requestRAG + Cosmos reduces repeated inference
Infrastructure right-sizing — measure utilization before scaling, retire before it accumulates$394/mo Cosmos → $0 after architecture review

What working with me actually looks like

How I actually think about this work

⚙️
Build for production, not demos
Every architecture decision gets evaluated against operational questions before I write code: who runs it when it breaks, what does it cost at steady state, what happens when a model call fails or latency spikes. I've operated these systems myself — that's not a hypothetical checklist.
📊
Numbers drive decisions
I don't migrate to a new technology without first measuring the cost of what's running. The Data Pipeline Evolution case study shows exactly how I concluded Cosmos DB was adding $394/month with zero benefit — and what migration back to PostgreSQL actually cost. Same discipline in advisory work: a recommendation without a financial model isn't a recommendation.
🔗
The model is 10% of the system
AI systems are icebergs. The model or agent is the visible piece. Everything else — the data pipeline feeding it, the infrastructure running it, the monitoring catching failures, the output schema downstream consumers depend on — is the 90% that actually determines whether it works. I build the whole thing.
🛡️
Governance is a design constraint, not a checkbox
In regulated industries — healthcare, financial services, government — governance shapes the architecture from day one. Provenance-by-construction, auditable reasoning chains, human approval gates at the right decision points. Not something you add at the end when legal asks for it.
💰
Cost discipline
Token economics is an architecture decision. I design prompts, context windows, caching layers, and model selection around an explicit cost-vs-value function — what does this token spend actually buy, and is it worth the margin? The same logic applies to infrastructure. Every cloud resource has a utilization curve and a point where it should be retired.
🔄
Ship it and find out
The spec is always wrong in some dimension. I build tight feedback loops with the people who will actually operate the system — not just review it. Requirements get revised in production, with real data, with the users whose workflow it's changing. That's not a methodology; it's just what happens when you stay close to the problem.