Pioneer, the summit where CX leaders redefine what’s possible, is on October 7th.

Join leaders from Fin, Anthropic, Clay, and Kalshi for an insightful conversation on the state of AI transformation.

You’ll discover how some of the most innovative minds in CX have transformed their organizations, learn how they think about CX, and hear how they're planning for what's next.

Join the conversation in San Francisco, or tune in virtually.

Reserve your spot

Twenty-five issues of AI news and analysis. You opened them at 78%, which is generous. You clicked almost nothing, which is honest feedback, and I heard it.

Here's what I think happened. The analysis was fine — and it was also finished the moment you finished reading it. There was nowhere to go and nothing to do. Meanwhile I've shipped 45+ production systems this year, for CHROs, PE funds, a yeshiva, and my own companies, and I've written about almost none of them.

So the Brief changes today. From now on this is a build desk. Every Sunday: what I actually built, what broke, what it cost, and what you can take from it. Daily AI news moves to The Leverage Signal — five minutes, Monday to Friday.

I'm not going to open the new format with one build when I have forty-five. I'm going to open it with the thing all forty-five taught me — the pattern that decides which builds ship and which ones die in a sandbox nobody opens again.

I kept a mental tally across every build this year — an HR policy engine for a Fortune 500 CHRO, a 26-category due diligence platform for a VC fund, a 398-donor fundraising CRM, a RAG coach trained on a four-volume book, a career-diagnostic SaaS, an LP-operations platform. Different stacks, different domains, wildly different clients.

The successful ones had almost nothing technical in common. Flask here, FastAPI there, no-code somewhere else. But five things showed up in every build that shipped, and were missing from every one that stalled. None of them is about the model.

1. The bottleneck is never the model. It's the corpus and the routing.

On the HR policy engine, the actual work wasn't the AI — it was deciding which policy sections mapped to which question types, and what the classifier did when confidence was low. On the due diligence platform, the intelligence wasn't one big model call; it was 26 separate scored categories, each with its own data sources, synthesized at the end with contradiction-detection across them. On the donor CRM, the value wasn't "AI writes emails" — it was 398 records structured well enough that the right donor context reached the draft.

The model is a commodity you rent by the token. The corpus you feed it and the logic that routes questions to the right slice of that corpus — that's the entire build. Anyone can call an API. Almost nobody structures the corpus properly, which is why most "AI initiatives" produce a chatbot that hallucinates policy and gets switched off in a month.

2. Build it to run in mock mode before it touches a real API.

The due diligence platform booted from day one with MOCK_MODE=true — the whole system ran, returned realistic reports, and could be tested end-to-end before a single paid data source was wired in. That one decision is why it went from architecture to working in days instead of stalling in integration hell.

Most enterprise AI dies here. The team wires ten live APIs first, nothing works together, nobody can tell which integration broke, and six months later the budget's gone with nothing to show. Build the skeleton so it runs on fake data first. Prove the logic. Then swap in the real feeds one at a time, where a failure is obvious and isolated.

3. Draft-only is a feature, not a limitation.

The donor CRM does not send email. It writes the draft, saves it to Gmail, and stops. A human reads it and hits send. On the HR engine, anything legally sensitive — terminations, accommodations, leave conflicts — hard-routes to a person no matter how confident the model is.

Clients think they want full automation. What actually survives contact with a real organization is a system that does 90% of the work and hands a human the last 10% with a draft already attached. The judgment stays human, the drudgery goes to the machine, and — this is the part that matters — nobody gets fired because the AI sent something insane at 2am. That confidence gate, written down once and enforced every time, is the difference between a tool people trust and one they quietly kill.

4. The prompt is the product. Everything else is plumbing.

On the HR engine, the backend took a weekend. Getting the model to reliably cite the specific policy section and honestly flag its own uncertainty took longer than everything else combined. The instruction that did the work was one paragraph: use only the text provided, do not use outside knowledge even if you think it's standard, and if the text doesn't answer the question, say so — don't extrapolate.

That paragraph is what stops the system from confidently inventing a parental-leave policy that merely sounds right. The stack is interchangeable. The prompt that encodes your actual judgment about how to answer is the irreplaceable part, and it's the part a dev shop with no domain expertise cannot write for you — because they don't know what "wrong" looks like in your domain.

5. Boring stack, cheap to run, or it dies in procurement.

The HR engine runs on about $40/month. No vector database, no fine-tuning, no agent framework — the corpus was small and bounded, so adding those would have bought latency and failure modes to solve a problem that didn't exist. At $40/month the ROI conversation lasts thirty seconds and nobody has to defend a line item. The same system at $2,000/month would still pencil out on paper and would have died in the budget review.

The instinct to reach for the most sophisticated architecture is the enemy. The build that ships is the simplest thing that solves the actual problem and costs little enough that no one has to fight for it.

If you keep one thing: the constraint is never AI capability. It's whether someone with real domain judgment sat down and decided what the system should and shouldn't do — before any code got written.

A Claude Code SDR stack made the rounds this month running a full sales pipeline at four cents a lead. Real, public, itemized. Execution is now effectively free. That fight is over and everyone won.

What is not free, and what almost nobody ships, is the judgment layer: which questions auto-answer and which route to a human, what the corpus contains and how it's sliced, where the machine explicitly does not get a vote. Four cents buys the execution. It has never once bought the judgment about what that execution is allowed to do.

That's why a 3x CHRO who builds beats a dev shop that codes. Not because the CHRO writes better Python — they don't. Because they know, before the first line, which HR questions are dangerous to get wrong. That knowledge is the build. The code is just how you write it down.

The five rules aren't HR-specific. They're a template. Point them at any repetitive, judgment-heavy process:

Same five rules every time: corpus over model, mock-mode first, draft-only handoff, the prompt is the product, boring and cheap.

Two doors this week. Pick the one that fits how you work.

Do it yourself → The Build Teardown, $197.
One full build from the 45, documented end to end: the architecture, the actual prompts, the corpus structure, the routing logic, the hard-route rules, and where it broke the first time. Enough to build your own version. Reply TEARDOWN and tell me which problem you're solving — I'll point you at the closest build and send the link.

Have me build it → Scoping call.
Custom builds run $5K for a focused single-workflow tool up to $50K for a full multi-workflow system, 2–3 weeks to delivery, built with your team so the capability stays when I leave. Reply BUILD with one line on the problem and I'll send a scoping link.

I'm deliberately not putting five other offers here. One DIY, one done-with-you. If neither fits, the newsletter's still free and so is the reply.

Everything else is in the daily. Three that matter if you build:

Cloudflare shipped native agent wallets — per-agent spend caps, merchant allowlists, transaction logs. If you're building anything that transacts, this is your default containment layer now. (late Aug)

The UK AI Security Institute logged 10 confirmed cases of production agents exceeding scope — unauthorized calls, unapproved resource acquisition. Common cause across all ten: nobody wrote down what "done" meant. Seven were caught only after the damage. (late Aug)

DeepSeek V4-Flash matched its own flagship across agent benchmarks at a fraction of the token cost. Price has stopped being a proxy for capability. Audit your model spend against actual task performance. (late Aug)

Find your 200-times-a-week question.

Every organization has one: the request that arrives constantly, is structurally identical each time, and quietly eats senior judgment that should be pointed at something harder. In HR it's policy. In legal it's contract triage. In finance it's spend approvals. In a fund it's first-pass diligence.

Write down three things:

Number three is the one that matters — it's your hard-route list, the cases where the machine drafts but never sends. Skipping it is exactly why seven of those ten agent failures got caught only after the fact.

Then hit reply and tell me your 200-times question. One line. I read every one, I answer the ones I can, and the most interesting become future issues of this desk.

Yuri Kruman
Founder, Portfolio Leverage Co. · 3x CHRO · AI Trainer: OpenAI, Meta, Microsoft
45+ builds shipped, not advised · PortLev.com · LinkedIn

© 2026 Portfolio Leverage Company. You're getting this because you subscribed to The Leverage Brief.