Fractional AI Lead · Los Angeles

I own AI operations for the function bleeding the most time, and I build the verification layer that makes the output trustworthy enough to run the business on.

Getting AI to work is easy now.
Getting to stop watching it is the job.

Eighteen years operating a business I co-founded. The last three rebuilding its actual workflows on AI infrastructure I write myself, and then handing them to the people who run them daily. Not a strategy deck. The systems the business runs on.

18yr
operator, not advisor
4
MCP servers in production
3yr
production AI, running daily
0
engineers hired to build any of it
01 The Gap

Your team can already build it. Nobody can sign off on it.

It shows up two ways. Either almost nothing is running and the same low-hanging fruit somebody named a year ago is still hanging, or plenty is running and nobody quite trusts what it produces. Opposite symptoms, same missing function: nobody whose actual job is deciding what good looks like, building the check that enforces it, and staying accountable when it drifts. That is the short straw nobody wanted.

Engineers use AI in roughly 60% of their work, and fully hand off only 0 to 20% of tasks.
Anthropic, 2026 Agentic Coding Trends
/ 01

Capability isn't authority

Building an agent is the floor, and the floor is collapsing. Anyone can do it now. What stays hard is the ceiling: what the system may do unsupervised, what routes to a human, what gets validated before it ships. Constraint architecture and eval design are judgment skills, not coding skills.

/ 02

Eval before optimize

Loose generator, tight judge. If I can't tell whether a change improved or regressed quality, I haven't built a product, I've built a vibe. The checking layer is the deliverable. Everything else is a demo with good lighting.

/ 03

Half the value is deciding what not to build

Every activity gets triaged: stays human, is plain deterministic code, or is genuinely agent-shaped. Ruling something human-only or just-write-the-script is a real answer and often the right one. This is where I separate from a consultant who agent-ifies everything and leaves you maintaining a pile of internal tools.

/ 04

Cost is a product surface

Most AI automation overpays on intelligence, running frontier models on cheap-model work. Routing tiers, prompt caching, context hygiene. Sloppy and clean usage on the same task vary many times over in cost, and those are product decisions, not engineering ones.

/ 05

Get people out of the prompt box

Most of a team will never live in a chat window, and asking them to is why adoption stalls with the people who happen to enjoy it. The work belongs in the surface they already use, one click inside the tool their job actually runs on, so nobody has to change the shape of how they work to get the benefit. That narrower surface is also the safer one: a button you designed has a defined blast radius, and an open prompt has none. Same reason it runs on systems you already own, under accounts in your name. Almost nobody has the spare capacity to absorb a transformation, and the ones who try end up with two broken processes instead of one.

02 Method

Each stage earns the right to the next one.

I land in one function, the one bleeding the most time, and expand only when the people inside the company start asking for it. No transformation programs. No twelve-month roadmaps that nobody reads past month two.

/ 01

The work-map

Week one. Every activity in the target function, mapped and triaged: human-only, deterministic code, agent-shaped, or already shipped. It is the diagnostic, the expectation-setter, and the boundary that makes the scope legible. The human-only column is the part I put in writing first, because it is the promise about what stays yours.

/ 02

Build to 95

One workflow, built to the point where it is right almost every time and the remaining cases escalate instead of guessing. Evals across four axes: right data, required steps, matches an expert, safe to act. Escalating a hard case counts as a pass, because a system that knows when to stop is the one you can leave alone.

/ 03

Hand it to a champion

Someone inside the company owns the running system, with protected time and my architecture behind them. The best engagements start with people who are already good at this and have never been handed the architecture, the authority, or the hours to go further. They run the show-and-tells, not me. If the engagement never transfers, the only argument for keeping me is that things break without me, and that argues for hiring someone instead.

/ 04

Expand by internal demand

One function proves it, then the next function asks. That pull is the only expansion signal I trust, because it means the first one actually worked. Every session logs what was built and what it returns per week, so the renewal conversation happens against a ledger instead of a feeling.

03 Proof

I did this to my own company first.

Four layers, all running in production inside a business where real revenue rides on the output. None of these are demos. They handle real data, absorb real failure, and are operated daily by people who are not engineers.

Before this I ran product and technology inside agencies and enterprises: a 70-person organization with full P&L, and $12M of delivery on a single enterprise client. Different scale, same job.

i.

Memory. Four MCP servers, all live.

Cloudflare Workers · D1 · Model Context Protocol

Four Model Context Protocol servers I built and run in production. Institutional knowledge and project state for the business. Personal context. A chat surface over email analytics so editorial decisions can be informed by subscriber behavior without anyone opening a dashboard. And the analytics layer spanning web, search, ad revenue, and affiliate commerce across five sources, where you ask in English and get the answer. Three-layer tiered retrieval underneath all of them.

TypeScript Cloudflare Workers D1 / SQLite MCP spec
Status All four live Lesson The first server stored too much and surfaced too little. Memory is a retrieval design problem, not a storage one.
ii.

Behavior. The standards, encoded as rules.

Skills · Versioned contracts · Two operators

More than a dozen custom skills covering editorial, sales, analytics, and operating rituals, each a versioned contract that encodes our standards as enforced rules rather than documented hopes. Built in parallel for a technical operator and a non-technical one. Same architecture, different surface area, different vocabulary. That second build is the one that taught me the most.

Claude Skills Versioned contracts Multi-surface deployment
Status In daily use Lesson A non-technical user is the best stress test any AI system gets. If she can't get a clean answer, the system is broken, not the user.
iii.

Application. Multi-agent content pipeline.

n8n · Multi-model routing · Human gates

A nine-agent, five-phase orchestration that audits legacy editorial against current voice and standards, rewrites it, and ships through a sandwich pattern: human-authored spec on top, autonomous build with an evaluator subagent in the middle, human review on flagged items only at the bottom. Strict prompt caching, model routing per phase, credential isolation per node. Built so the editorial director never reviews a draft she doesn't trust. For a team publishing 50+ pieces a month, it cut our own editorial production time by about 40%.

n8n Multi-model routing Eval gates Human-in-the-loop
Status Shipping Lesson The bread is human judgment. The filling is the agent doing what agents do best. Editorial voice, curation, and the publish decision never entered the automation.
iv.

Verification. The layer that made the failure visible.

Eval harness · Its own repo · Multi-turn tool-use tests

A commission figure in my own weekly business reporting sat frozen at one value for nine weeks, a stale upstream read, and the AI layer on top narrated confidently past it every single week. Building the eval harness is what made the frozen number visible. Then the harness turned up its own silent-pass bug: crashed runs were being scored as passes. The checking layer needed a checking layer. That is the whole job in one story.

Eval harness Multi-turn tool-use Mocked fixtures Pre-commit gates
Status Live, gating releases Lesson Nothing was auto-caught. Building the check is what surfaced it, and I still had to go do the sleuthing. That distinction is the entire pitch.
04 Essay

The part that doesn't transfer.

I started calling what I built an operating system about six months in, when I noticed I had stopped thinking in terms of individual prompts and started thinking in terms of layers. Memory below. Behavior above. Applications on top. Observability through all of it. The vocabulary sounded grandiose at first. It stopped sounding grandiose when I realized that is what I was actually building. The context window is the program. The model is the interpreter. The architecture is the source code, and someone has to write it deliberately.

The first thing I learned shipping production AI is that the model is almost never the hard part. The hard part is deciding what the model should do, when it should refuse, what to show someone when it failed, how to budget tokens against a real cost ceiling, and how to make the whole thing legible to a team that does not read code.

Each of those is a product decision. Not an engineering decision and not a research decision. A product decision, dressed up in technical clothes.

I don't just build agents. I make a thousand editorial decisions about how agents should behave in production.

The agentic era inverts a lot of what operators thought they knew. Speed-to-ship is no longer a differentiator when anyone with a credit card can stand up a working prototype in an afternoon. Domain depth still matters, but it has to be encoded explicitly now, into prompts, constraints, evals, routing logic. You cannot carry it implicitly in your team's heads anymore, because the system needs to read it.

What is left is judgment. Specifically, the judgment to know which decisions are reversible and which are not, which experiences degrade gracefully and which fail catastrophically, which prompts survive a model upgrade and which were exploiting a quirk of the current weights. That does not come from reading papers and it does not come from shipping features. It comes from running production systems where being wrong is paid for in real revenue, real customers, and real time.

This is also why I am not trying to make anyone depend on me. I hand off the floors and keep architecting the ceiling. The engagement that never transfers gets cut, because the only answer to "why are we still paying him" is "things break without him," and that is an argument for hiring someone. The one that transfers gets extended, because trust earned by handing something over buys the next piece of scope.

The teams I have watched get the most out of this are not the ones with the best tools. They are the ones where somebody made the standards explicit, put a check around them, and then let people actually stop watching. That is the difference between a few people out ahead of everyone else and a whole team moving up the same curve.

05 Fit

I take a small number of engagements, and part of the first conversation is figuring out whether we're right for each other.

Good fit

  • You know AI matters and you have the will to move, but nobody's actual job is owning it, so it keeps routing back through you.
  • A few people are well out ahead of the rest, and you want the whole team on the same curve rather than a handful carrying it.
  • You want ownership rather than dependency: evals, review gates, and your own people running it at the end.
  • You respect the human-only column. The work is meant to lift what your team can do, not hollow it out.

Not a fit

  • "Just build us some agents." That is a pair of hands, and you can hire those more cheaply than me.
  • Someone senior already owns AI operations as their actual job, with the time to do it. Then you don't need me, and I'll say so on the first call.
  • Appetite for delegation with no appetite for verification. That combination is how people get burned.
  • You're price-shopping consultants. I flex scope, not rate.

Let's find out where the time is going.

If any of this sounds like your situation, the first conversation is a diagnosis, not a pitch. Architecture, code, and specifics available on request.

Email ↗ LinkedIn ↗