Predictable is the good news: it means findable. Eleven years building high-scale infrastructure — three years on AWS's credential layer, multi-terabyte data platforms at Amazon, production RAG pipelines today. I help engineering teams scale what they've built, get an honest read on their architecture, and ship AI features that hold up in front of real customers.
A RAG system is a data pipeline with a model on the end of it. When one starts producing bad answers, the cause is usually upstream of the model: documents chunked badly at ingestion, an index that's gone quietly stale, a retrieval step returning plausible-but-wrong context, a permissions boundary surfacing the wrong tenant's data. Those are infrastructure problems wearing an AI costume.
That's the practical difference. If your consultant's depth stops at the model layer, they'll spend six weeks tuning prompts on a problem that lives in your ingestion job. I start where the failure usually is — the pipeline, the data model, the access boundaries — and work forward to the model, rather than starting at the model and hoping.
I spent three years at AWS on the Security Token Service, which issues credentials for effectively every AWS API call. I built it out across three regions, including GovCloud under FIPS 140-2 — the layer everything else authenticates against, so delivering it is what lets the rest of a region come online. Then three years at Amazon on service migrations, multi-terabyte data stores, and security review for applications handling customer data.
Most recently I was a Principal Engineer and manager at Unwrap.ai, leading a team of five on RAG infrastructure, analytics, and the multi-tenant access control that made enterprise sales possible. I left in March 2026 to consult full time.
Throughput, latency, and cost at the point where the easy fixes are gone. I've built real-time pipelines on Kafka, Debezium CDC, and ClickHouse that cut p99 query latency by 80%, and re-architected write paths to drop user-perceived latency by 90%. Usually the answer isn't a rewrite — it's finding the three decisions that are actually costing you.
A senior outside read on what you've built: where it breaks at 10x, what's load-bearing that shouldn't be, what to fix first, and what to leave alone. You get a written assessment with a prioritized sequence and effort estimates — something you can hand to your team or take to your board.
If the answer is “you're fine, don't spend money on this,” that's what the assessment will say.
Retrieval that worked on a demo corpus fails on a real one in specific, diagnosable ways — how documents get chunked, which embedding model you chose, how results are ranked, or a permissions boundary quietly surfacing the wrong tenant's data. I've led a team building a high-throughput RAG pipeline, productized an LLM assistant, and shipped MCP integrations with OAuth and permission scoping.
The deeper problem is that most teams have no way to tell whether a change helped. They adjust the chunk size, swap the embedding model, rewrite the prompt — then judge it by spot-checking a handful of queries. So the first thing I build is a scored test set: real questions from your users, the answers they should have gotten, and an automated way to grade every change against them. After that, “did this help?” is a number instead of an argument.
Customers were making decisions on data up to a day old, and the largest prospects wouldn't buy without live insight. I replaced batch reporting with a streaming pipeline on Debezium CDC, Kafka, and ClickHouse — cutting p99 query latency by 80% and turning a stale daily report into a real-time product. Seven-figure contracts followed.
Unwrap.ai · Real-time analytics pipelineEnterprise buyers wouldn't approve the platform without provable separation between tenants' data, and deals stalled there. I designed and built role-based access control across the customer-facing APIs, which cleared the objection and unlocked six-figure contracts.
Unwrap.ai · Multi-tenant RBACStanding up a region is a collaborative effort across many organizations at AWS; my piece was the Security Token Service. STS issues the credentials every other service authenticates with, so delivering it is what lets the rest of a region come online — other AWS teams could then launch their services there, and customers working under government data regulations could run on them. I built out STS across three regions, including OSU under FIPS 140-2.
AWS · Security Token ServiceAlexa's question-answering degraded every time its underlying data was redeployed — a routine internal operation that users experienced as the product failing. I designed the deployment algorithm that eliminated it, holding availability through every push.
Amazon · Alexa QnAWrites that users had to sit and wait through were doing expensive work inline. I designed an async mapping engine that moved that work off the critical path, cutting the delay users actually experience by 90%.
Unwrap.ai · Async mapping engineYou describe the problem. I tell you whether I'm the right person. Free, and I'll say no if the answer is no.
Fixed scope, fixed fee, usually one to two weeks. You get a written diagnosis and a prioritized plan. Many engagements end here, on purpose — you have what you need and your team executes it.
I build alongside your team, not around them. Fixed scope, milestone-billed.
You keep the keys. Everything I build is documented, tested, and handed over as we go. I'm not interested in being a dependency, and you shouldn't be interested in having one.
It's fifteen minutes, and I'll tell you honestly if you don't need me. I consult full time and take on a small number of clients at once.