The AI Corner

3. Move 37 changed everything, then triggered AlphaFold

One move in a board game convinced Hassabis that AI could make genuine scientific discoveries.

“AlphaGo had played an original move, this Move 37.”

He had carried the protein-folding idea for close to 2 decades, since his Cambridge undergraduate days. What he needed was proof that a system could produce something genuinely novel, over merely optimized. Move 37 was that proof, inside a board game. He flew home from the AlphaGo match in Seoul and greenlit AlphaFold within days.

The gap between a system performing well and a system discovering something new is the threshold to watch, and the signal usually shows up somewhere unrelated to your industry first. That is the same discovery-loop logic now being industrialized by the teams automating research itself. Track capability proof points, over product launches.

4. The $7 billion number behind the DeepMind sale

Hassabis explains selling to Google with actual numbers, over vague industry talk.

“I was barely able to scrape together $10 million rounds.”

This was 2014. Zero OpenAI, zero AlphaGo, just Atari-playing agents most investors dismissed. He has put the counterfactual at $7 billion: the capital it would have taken to build a genuine competitor at scale, against rounds 10 to 20x smaller than that. Larry Page personally understood the bet when almost nobody else did. Meanwhile Silicon Valley noticed the talent: Hassabis paid himself nothing while researchers on roughly £100K salaries fielded $10 million offers. He calls it a timing problem, since SoftBank-scale mega-rounds arrived roughly a year too late for him.

Capital timing beats product timing.

If your category is about to attract mega-round capital, the founders who survive the gap year are the ones who structure the raise for patience, model the dilution math honestly, and know how the fund across the table actually makes money.

5. The Full Stack Of AGI Risk (It Is Not Just One Problem)

Ask Hassabis what worries him and he hands you a stack of risks, not one scary scenario.

“There’s a whole stack of issues, each one more complex.”

Misuse sits first: rogue actors turning general-purpose tools toward harm, including tools built for medicine. Technical alignment comes second: keeping increasingly autonomous systems inside the guardrails you set. Economic concentration is third: broad benefit versus a handful of companies capturing it. Meaning is the last and hardest: purpose, once machines absorb the work humans defined themselves by.

His sharpest institutional point: nothing currently exists that can govern all 4 layers at once, at the most fragmented geopolitical moment in 30 years.

If your AI risk framework covers one layer, it is incomplete. Investors underwriting frontier labs should ask which layer a team is weakest on, over which one gets the press coverage, the same discipline behind a serious security checklist.

6. Why Big Tech actually wants guardrails

Hassabis complicates the convenient story of labs racing ahead while regulators chase.

“Nobody wants catastrophic things to happen.”

He knows the other lab leaders personally, back to postdoc years alongside people like Dario Amodei, and his read is that none of them wants a catastrophe attached to their name. The blocker is game theory, over intent: even safety-minded leaders face a prisoner’s dilemma, because someone always holds an incentive to defect from an agreed standard to win share.

That is his actual argument for external governance. Labs are coordination-trapped, over villainous, and good individual incentives fail to add up to good collective outcomes without a referee. Proposals are already moving with major governments.

Build your governance thesis around coordination problems, over villain narratives. That framing predicts which policy interventions actually work, and it is the version serious diligence already prices.

7. No bank wants an AI agent losing a billion dollars

Hassabis thinks the market enforces AI safety faster than regulation, once enterprise money is on the line.

“That loses you a billion dollars the next day.”

Financial institutions will demand hard guarantees around agent behavior and data handling before deploying at scale. One expensive failure from a lab with weak guardrails teaches the whole market instantly, so enterprise trust rewards responsible labs and reckless ones fund the object lesson. His caveat: the mechanism only works if buyers price in guardrails before a failure, over after one.

If you sell agents into finance, healthcare, or any regulated vertical, your guardrail documentation just became a sales asset, over a compliance afterthought. Buyers are about to start asking.

The builder’s stack for exactly that:

▫️ Give your agent its own computer: the sandbox playbook

▫️ Your GTM, run by agents

8. Watts to dollars to tokens: the formula that explains the whole industry

Hassabis compresses the entire AI infrastructure argument into 3 words.

“It’s literally watts to dollars to tokens.”

Energy cost converts directly into intelligence cost. The UK carries some of the most expensive energy in the Western world, which caps how much inference it can afford to run, and he frames data centers as the new industrial base the way factories were a century ago. The country that solves cheap, abundant power solves its position in the AI economy.

This lands on your P&L before it lands in any headline. Model inference against your local energy market, over just your API pricing, then attack the line item directly:

▫️ You are overpaying for intelligence: the model router

▫️ The token-cost optimization playbook

▫️ How to never hit Claude limits: the token system

9. Root node problems: why protein folding was the first target

Hassabis picked protein folding for what solving it would unlock.

“It was also what I call a root node problem.”

He met the problem as a Cambridge undergraduate, listening to biologist friends who talked about it constantly, a listening habit he calls deliberate. It sat unsolved for 50 years. He filed it away for roughly 15, waiting for the technology and the proof point to catch up, and 3 million researchers now use AlphaFold.

A root node problem, solved once, compounds across an entire field. A leaf node ships a feature.

Leaf nodes make a good feature. Root nodes make a category.

Before picking your next problem, run the root-or-leaf test, then steal from the 100 agent ideas ranked by exactly this and the category-creation story behind Replit’s seed.

10. The UK Can Build Unicorns. It Cannot Yet Build Giants.

Britain wins the first stage of company building, and Hassabis says the second stage is where it falls apart.

“We do very well getting to unicorns.”

DeepMind stayed in London by choice and seeded a wave: over 10% of Q1 UK AI venture funding traced back to former DeepMind staff, per HSBC Innovation Banking at the event. Talent and founding conditions, proven. What is missing is growth-stage capital and a functioning path to public markets, and Hassabis says plainly he cannot understand why companies stopped floating in London. Energy costs and listing incentives are his 2 named blockers between the UK’s unicorn factory and its first homegrown trillion-dollar company.

If you are a UK AI company approaching Series C, treat the gap as fact over theory: plan the growth round assuming you look beyond the UK even if you stay headquartered there, map the check-writers early, and walk in with a valuation story and a 13-week cash position that survive diligence.

The Hassabis playbook

AGI is close enough that the institutions meant to manage it, in education, finance, and government, have to start moving now, over after it arrives.

▫️ Founders: model energy and compute as a hard line item, write the guardrail documentation before an enterprise buyer asks, and run the root-node test on your roadmap this week.

▫️ Investors: the market-correction thesis only works if you price responsible behavior before a failure forces you to. The UK growth-stage gap is genuine, and genuine gaps are opportunities. Underwrite guardrails as seriously as growth metrics.

▫️ Operators: the classroom-inversion pattern is coming for corporate training too. Pilot one AI-assisted, judgment-heavy workflow before your competitors do, starting from the one-person operating system.

▫️ Everyone else: watts-to-dollars-to-tokens applies to you even if you never touch a model. Ask your AI vendors where their compute actually runs.

The 5 principles to steal

Definitions matter more than dates. Know the capability threshold you are planning around, over the year attached to it.
Root node problems compound. Pick the one that unlocks a field, over the one that ships a feature.
Guardrails are a sales asset now. Write the documentation before the buyer asks.
Energy is a line item. Treat it like one in your model.
Coordination problems need referees. Good individual intentions never sum to collective safety on their own.

The future is unwritten. Someone is going to write it anyway. Better you than the person who waited.

If this breakdown saved you 81 minutes, send it to one founder or investor who needs it.

Keep reading

Build for the timeline

▫️ The Claude Opus 5 playbook

Control the cost curve

▫️ You are overpaying for intelligence

▫️ The token-cost optimization playbook

Raise like it is 2026

The philosopher Michael Polanyi named the reason decades ago. We know more than we can tell.

▫️ The self-improving fundraising system

▫️ The investor lists: 10,000+ check-writers

Full lecture:

The Task Economy Is Real and Almost Everyone Is Valuing It Wrong

Ruben Dominguez — Fri, 21 Aug 2026 14:47:08 GMT

What the Task Economy Actually Trades

Venture capital has a new favorite phrase. Benchmark’s Everett Randle calls it the “Task Economy”, the fast-growing market where AI labs pay human experts to teach models their craft.

His pitch is elegant. Tokens became the standard unit of AI usage, so tasks should become the standard unit of AI improvement and the spending behind them will become the next $1 trillion category.

The numbers make the case easy to believe. Mercor, the market’s leading platform, crossed $1 billion in annualized revenue this February and $2 billion by June and is now raising at a $20 billion valuation.

Everett Randle is right about the Task Economy’s growth — but the durable value may accrue elsewhere.

Here is the problem. The thesis is right about the growth and wrong about what kind of market this is.

A task is not a service being consumed. It is a transfer of ownership, the moment a piece of human judgment stops being rented by the hour and becomes an asset someone else keeps forever.

That distinction decides who actually wins the Task Economy and it is missing from the entire conversation.

together with Granola:

The Task Economy pays experts to hand their judgment over.

Granola makes sure you keep yours. It is the AI notepad that takes notes in the background wherever your meetings happen, Zoom, Slack, Google Meet, Teams, even in person with the iPhone and Apple Watch apps:

▫️ A brief before every call: who you are meeting, what you discussed last time, the context that matters

▫️ Clean summaries and action items the moment you hang up

▫️ Always follow up: a drafted email seconds after the call, or context pulled from your CRM via MCP

A second brain that was actually in every meeting.

try Granola Free !

(code THEAICORNER for 1 month off)

1. The Task Economy in Plain Terms

2. What a Task Actually Transfers

3. Wages In, Capital Out

4. The Countdown Built Into the Boom

5. The Layer That Outlives the Buildout

6. Encode or Be Encoded

1. The Task Economy in Plain Terms

For 3 years, AI models got smarter mainly by reading the internet. That well is now dry and the Task Economy is what the industry built to replace it.

From tokens to tasks

Pretraining on public text carried models from autocomplete toys to competent generalists.

It cannot carry them much further, because the open internet never contained the working judgment of skilled professionals.

A model can read every published court ruling and still have no idea how a good lawyer actually reviews a data room.

A task closes that gap.

The model receives a realistic assignment inside a realistic environment, a contract to review, a diagnosis to reach, a codebase to fix and a practicing expert grades its attempt against a professional standard.

Randle’s framing is that tasks are to model improvement what tokens are to model usage.

Everett Randle argues that data tasks could become AI’s next trillion-dollar category. (Everett Randle on X)

As adoption grows and models get hungrier for harder, longer exercises, task volumes compound the same way token volumes did.

The growth is not hype

The spending curve backs him. His essay reports OpenAI and Anthropic scaling their data budgets by roughly 10x year over year, mobilizing experts across every professional domain.

Mercor’s rapid revenue growth illustrates how quickly the Task Economy is scaling. (Image source: Value Add VC)

Mercor went from $1 million to $2 billion in annualized revenue in roughly 24 months and The Information reports its fastest-growing demand now comes from AI app developers and large enterprises rather than the labs alone.

So the Task Economy is real, large and accelerating. On the facts, Randle wins.

The trouble starts with the word economy itself, because it smuggles in an assumption about what is being bought and sold.

2. What a Task Actually Transfers

For 300 years of industrial capitalism there was exactly 1 way to access expert judgment. You rented it.

The one thing money could never own

A surgeon’s intuition or a litigator’s feel for a hostile negotiation lived inside a skull and skulls charge by the hour.

You could own a machine, a building, a patent or a brand. You could not own judgment.

You could only employ it and when the employee retired, the asset walked out the door with them.

The Task Economy turns human judgment into something AI can absorb, reproduce, and scale.

Software never broke this constraint, because software encodes procedures, the explicit if-this-then-that. The valuable core of professional work was never procedural.

The conversion moment

Now run a task through that lens.

A firm pays experts for 6 months of demonstrations and grading.

The wages are incurred once, yet what comes out the other side is a permanent, infinitely copyable asset. Encoded judgment that works at 3am, in 10,000 parallel instances, for the price of electricity.

Nothing about the invoice reveals this.

On the income statement it looks like any other vendor expense, which is exactly why the market keeps mislabeling what it is watching.

Every task in the Task Economy is a small act of this conversion.

Judgment goes in as labor and comes out as capital and once you see that, the trillion-dollar question changes shape.

3. Wages In, Capital Out

If tasks are capital formation rather than services, history offers a very specific warning about where the money settles.

The railway lesson

The railway booms of the 1800s paid out staggering sums in construction wages and the construction firms were the hottest businesses of their decade.

Almost none of them survived as great companies. The railroads did.

That is the standard shape of a buildout.

Spending explodes while the asset is being created, then it collapses toward maintenance and value migrates from the builders to the owners.

The task platforms booking billions today are the construction firms of this cycle. Their growth is real and their position is transitional and those 2 facts coexist more often than markets like to admit.

The task economy may resemble a buildout: labor creates the infrastructure, but long-term value accrues to whoever owns what remains.

The pass-through problem

The headline revenue also flatters the underlying business.

Bloomberg reported that Mercor’s $2 billion figure reflects gross billings and that the contractors doing the work take home 60 to 70% of it.

The platform keeps roughly a third. The rest is wages passing through on their way to the experts.

So even the promised trillion dollars of task spend, if it ever materializes, would be substantially a trillion dollars of salaries. That is a labor market wearing a software valuation.

None of this makes the platforms bad businesses today.

It means the durable question about any of them is not how fast task volume grows, but what they will still own when the buildout slows.

4. The Countdown Built Into the Boom

There is a stranger problem underneath the growth and it has no equivalent in the token economy everyone keeps comparing this to.

Customers funding their own exit

Nobody at a data center is working on making customers want fewer tokens. The Task Economy’s biggest buyers are doing exactly the equivalent.

Every frontier lab funds research whose explicit purpose is to reduce the need for human training data. Synthetic data, self-play, AI graders and reinforcement learning against automatically checkable rewards in code and math.

In other words, each dollar a lab spends on tasks comes with a second dollar spent building the task vendor’s replacement.

The window may stay open for years. Randle’s own essay estimates that 99% of the knowledge relevant to future AI capability still sits in people’s heads, which is both the bull case and a measure of how much extraction remains before the buyers can leave.

Even so, a market whose customers are financing their own exit cannot be extrapolated with a ruler.

(Image source: Everett Randle)

Concentration has already drawn blood

The other structural weakness is that the big buyers can be counted on 1 hand and this market has already run the experiment on what that means.

Scale AI was the category king until Meta bought 49% of it in mid 2025, at which point the other labs fled within weeks and gutted its core data business.

Mercor got its own taste this year. After a March 2026 supply chain attack exposed up to 4 terabytes of internal data, Meta, one of its biggest clients, paused all work with the startup indefinitely.

Mercor’s breach highlighted the concentration and security risks facing AI data vendors. (Image source: Wired)

When 5 buyers control most of your revenue, you do not have a market position. You have a portfolio of large contracts with correlated termination risk and the correlation only becomes visible when it fires.

5. The Layer That Outlives the Buildout

Inside the Task Economy, 1 segment does not follow the buildout-then-fade curve and it is not the segment collecting the headlines.

Teaching ends, grading does not

Generation, meaning the work of showing a model what good performance looks like, is a stock problem. Once the judgment is encoded, it is encoded.

Verification is a flow problem and it never closes.

The frontier keeps moving, so models are perpetually graded against harder work than last year. The world keeps changing too, so a rubric written today goes stale within a couple of years as laws and standards change.

Someone has to grade the grader

There is a deeper reason this layer persists. As encoded expertise takes over real economic work, demand for assurance grows with deployment rather than with training.

Training may end, but AI verification becomes a continuous process.

Every regulated industry that hands work to a model will need a continuously refreshed apparatus of evaluation and much of it requires exactly the human judgment being automated, because the chain of trust has to stop somewhere.

So the honest map of the Task Economy has 2 layers with opposite economics. Generation is enormous now and ultimately bounded, while verification is smaller now, recurring and sits right next to regulation.

Anyone screening companies in this space should ask 1 question before any other. Is this revenue teaching the model, or auditing it? The second kind compounds.

6. Encode or Be Encoded

Every company sitting on decades of accumulated know-how is holding an asset that the Task Economy is about to convert into capital. The only open question is who ends up owning the result.

Do nothing and a generic version of your domain’s expertise gets encoded anyway, drawn from the industry-wide talent pool, by labs and by competitors. Your inherited know-how gets quietly repriced from moat to commodity.

Encode or Be Encoded: accumulated human judgment is becoming a transferable asset.

If you run the extraction yourself, with your own problems and your own experts, you will end up converting a wasting asset into a compounding one.

The enterprises now driving the fastest-growing slice of task demand appear to have worked this out already.

The accounting has not caught up. Money spent encoding expert judgment is booked as an operating expense and managed like a cost, when it behaves like capex in everything but the label.

For individuals, the arithmetic is uncomfortable but worth stating plainly. The experts earning excellent rates on task platforms are executing a 1-time sale of an asset they previously rented out in perpetuity.

Once a functional copy of mid-tier professional judgment exists, the wage for mid-tier professional judgment does not stay where it was. The professions will not erode evenly. They will hollow out from the middle, while frontier judgment and the people who audit the machines become more valuable, not less.

So take the Task Economy thesis seriously, because the growth is real and the buildout will be enormous. Then take it 1 step further than its authors do.

Tasks will be king, exactly as promised. The kingdom belongs to whoever owns what the tasks leave behind.

How to 8x Your Code Output Using Context Engineering

Ruben Dominguez — Thu, 20 Aug 2026 14:47:41 GMT

Anthropic’s Engineers 8x Their Output

In June 2026 Anthropic published a report on its own engineering organisation called “When AI Builds Itself”, and the headline finding travelled a great deal further than the document did.

By the second quarter of the year, the typical Anthropic engineer was merging 8 times as much code per day as in 2024.

AI coding agents helped push Anthropic’s code output per engineer to 8× its pre-2025 average. (Image source: Anthropic)

But the explanation was mostly misread.

The foundational model did not change. The team did not change. The face behind the company didn’t change. It all came down to “context engineering”.

That version sends people off to build enormous scaffolding that makes their agents slower and less reliable. Almost everything that genuinely works here is smaller and duller than the posts suggest, and most of it sits in documentation nobody reads.

So what follows is the version I would hand a friend who asked me to set this up on their repo over a weekend.

What context engineering means, which files load at which moment, and which parts of it are worth your Saturday.

together with TrueForge:

Everything below is context engineering for your sessions.

TrueForge is the same discipline built into an agent harness: open source, vendor-neutral, benchmarked against Claude Managed Agents on the same model and tools

▫️ Same score (11/14), 62% fewer tokens, 30% lower cost per run

Get it on GitHub

▫️ Compaction instead of replaying, the discipline this article teaches

▫️ Any model, any MCP server: $0.25 vs $1.10 per correct answer on the open-model config:

Get Started!

1. Context Engineering Is Budgeting, Not Collecting

2. The Four Layers and When Each One Loads

3. Writing an Instructions File Claude Will Follow

4. The Memory Layer, and What Survives a Compaction

5. Fetching Context Instead of Front-Loading It

6. Turning All of This Into Actual Output

1. Context Engineering Is Budgeting, Not Collecting

The name makes it sound like the job is gathering everything relevant and handing it over. The job is closer to the opposite.

A definition worth actually using

Anthropic’s Applied AI team published a piece on this in September 2025, and the premise is the part worth keeping.

A model works inside a finite attention budget, and every token you put in front of it spends from that budget whether it earned its place or not.

Good context engineering, by their definition, means finding the smallest set of high-signal tokens that make your desired outcome likely.

In other words, editing rather than collecting.

Prompt engineering was about how you worded one message. This is about what the model can see across an entire task, and most of the craft turns out to be about what you leave out.

(Image source: Anthropic)

Why loading more makes agents worse

You can watch this happen in a long session. Quality drops well before you hit any hard limit, and once compaction fires near the ceiling your history gets rewritten into a summary that keeps whatever the summariser thought mattered.

The costs add up fast. Every MCP server you connect spends tokens on tool definitions before you have typed a character, and a 400-line instructions file does not get followed twice as reliably as a 200-line one. Anthropic’s documentation says the reverse happens.

So before you add anything, work out whether it needs to sit there for the whole session. Useful is not the bar.

From human-built AI to AI that could eventually build itself. (Image source: Anthropic)

2. The Four Layers and When Each One Loads

Most people organise context by topic. Sorting it by load time tells you far more, because when something arrives decides whether it will still be there an hour later.

ENFORCED      settings and hooks            always, and not context at all
RESIDENT      CLAUDE.md, rules, MEMORY.md   from disk, every session start
CONDITIONAL   path-scoped rules             when a matching file is opened
FETCHED       skills, sub-agents, MCP       only when something asks for it

The two layers that are always there

The enforced layer barely counts as context, which is exactly why it goes first. A deny list in your settings file blocks tools, commands or paths and the client honours it whatever the model concludes, while hooks run as shell scripts at fixed lifecycle points and can stop an action outright.

This is where a never-touch list belongs. Writing never read .env into a markdown file buys you a strong hint and nothing more, because the documentation is explicit that instructions are context and not enforced configuration.

The resident layer is your CLAUDE.md files, any rules without path scoping, and the top of Claude’s own memory index. All of it comes off disk at the start of every session, and all of it costs you window space for the entire run.

WHERE CLAUDE.MD FILES LIVE

  managed policy   /Library/Application Support/ClaudeCode/CLAUDE.md
  user             ~/.claude/CLAUDE.md
  project          ./CLAUDE.md   or   ./.claude/CLAUDE.md
  local            ./CLAUDE.local.md        (gitignore this one)

Files above your working directory load in full at launch, concatenated from the filesystem root downward, so whatever sits closest to where you started gets read last. In a monorepo where other teams’ files keep getting swept in, claudeMdExcludes drops them by glob.

The two layers that come and go

A rule carrying paths frontmatter costs you nothing until Claude opens a file that matches the pattern.

Nested CLAUDE.md files in subdirectories behave the same way, which makes both of them a good home for API conventions you do not want resident while working on the frontend.

The fetched layer is everything Claude goes out and retrieves. Claude skills load when you invoke one or when Claude judges it relevant, sub-agents hand back results from a separate window, and MCP calls pull in the ticket or the incident or the schema.

Working out which layer something belongs to answers most of the questions people ask about this, including the one where an instruction seems to disappear halfway through a task.

How nested claude.md files provide better context. (Image source: Raul Junco)

3. Writing an Instructions File Claude Will Follow

Everyone starts here, and almost everyone writes too much.

Name it CLAUDE.md, then check it loaded

Claude Code reads CLAUDE.md. It does not read AGENTS.md, and no fallback exists, so a repository holding only an AGENTS.md hands Claude nothing at all.

A lot of guides get this backwards, and it matters because AGENTS.md is a real convention that most other coding agents do look for. Running a mixed toolchain, put a single @AGENTS.md import at the top of your CLAUDE.md, or symlink one to the other and move on.

Then confirm it worked. Run /context and look for the file under memory files, because skipping that check is how people spend a fortnight convinced their instructions are being ignored.

Start with /init, which reads your codebase and drafts something for you. Then cut it hard, since what it produces is a description of your repo and what you need is a set of corrections to it.

Stay under 200 lines, and know what to cut

The documentation targets under 200 lines per file and says plainly that longer ones eat more context and get followed less often. Treat the file as a budget line with a hard ceiling rather than a wiki page.

The /doctor checkup proposes trims along a principle worth stealing outright. It strips anything Claude can work out by reading the repo and keeps the pitfalls, the reasoning, and any convention that contradicts what your tools do by default.

WORTH THE SPACE

build, test and lint commands
conventions that contradict the framework default
where things live when the folder tree does not say
the failure that already cost somebody an afternoon
what to do when a requirement is ambiguous

NOT WORTH THE SPACE

directory listings
dependency lists
architecture overviews
anything Claude can read off the repo in 10 seconds

Write rules you could check against. Use 2-space indentation works, while format code properly does nothing at all. Anywhere two rules contradict each other across the tree, Claude may pick one arbitrarily, so a periodic read-through pays for itself.

Add to the file on a trigger rather than on a schedule. Claude repeats a mistake, a review catches something it should have known, or you notice yourself retyping a correction you already typed last week.

4. The Memory Layer, and What Survives a Compaction

Most playbooks tell you to hand-build a memory file that the agent reads at the start of a session and updates at the end. That feature already ships, switched on.

Claude keeps its own notes now

Auto memory is enabled by default and Claude decides what to keep based on whether it would help a future conversation.

So you should build commands it worked out the hard way, a debugging pattern that keeps recurring, a preference you corrected twice, the reason a particular test stays skipped.

~/.claude/projects//memory/
  MEMORY.md            index, first 200 lines load every session
  debugging.md         read on demand
  api-conventions.md   read on demand

Only the index loads at startup, capped at the first 200 lines or 25KB, whichever arrives first. Everything past that gets dropped without warning, which is why Claude keeps pushing detail out into topic files and reading them when needed.

Open it now and then with /memory. It is plain markdown you can edit or delete, and a stale note does more damage than a missing one because Claude will act on it with total confidence.

Two limits are worth knowing. Auto memory lives on one machine and is shared across worktrees of the same repository, and sub-agents do not inherit what the main conversation learned.

Placement decides what comes back

Compaction fires as you approach the ceiling, summarises your conversation, and hands the model a compressed version of its own history. What makes it through follows one rule that is simple and not at all obvious.

SURVIVES     project-root CLAUDE.md, unscoped rules, MEMORY.md index
SUMMARISED   path-scoped rules, nested CLAUDE.md, everything you typed

Anything read off disk at startup gets re-injected afterwards. Anything that arrived through the conversation gets folded into a summary and stays folded.

A path-scoped rule therefore vanishes at compaction and will not return until Claude opens a matching file again. Where an instruction has to hold for a whole task, put it unscoped in the project root and stop repeating yourself in chat.

Two commands do most of the day-to-day work. Use /clear between unrelated tasks, which hardly anyone does often enough, and /compact followed by an instruction when you want to choose what gets preserved.

How Claude remembers your project.

5. Fetching Context Instead of Front-Loading It

Once you stop trying to preload everything, the interesting question becomes how Claude gets what it needs at the moment it needs it.

Skills carry procedures, sub-agents carry volume

Rules load every session or whenever a matching file opens, while skills load only when you invoke one or when Claude decides one applies.

A fact Claude should always hold belongs in a rule, and a procedure it should sometimes follow belongs in a skill.

Sub-agents are the strongest move available here and the one hardly anybody uses. A sub-agent explores inside its own clean window and returns a condensed summary, often 1,000 to 2,000 tokens, so your main session never sees the 80,000 tokens of search output behind the answer.

Worth saying plainly though. A simple loop often beats an elaborate multi-agent arrangement, so reach for this when the reading volume justifies it and not because the architecture diagram looks impressive.

External systems, and what they quietly cost

MCP is how Claude reaches the ticket explaining why a feature matters, the incident showing how users are hitting a bug, and the schema the fix has to respect. That context is real, and it is frequently the piece that was missing.

The cost stays hidden until you look for it. Every connected server spends startup budget on tool definitions before you type anything, so a dozen connectors you rarely touch is a tax you pay on every single session.

Where the two overlap, there is a decent argument for skills over servers. You can read a skill and see exactly what it instructs Claude to do, whereas a server is a black box you have granted tool access to.

6. Turning All of This Into Actual Output

At the end of the day, code still has to be written.

Context work stops an agent making confident bad decisions, and by itself it produces nothing extra at all. The 8x came from somewhere else.

When your AI agent is confidently wrong.

Anthropic’s engineers stopped typing code and started directing and reviewing it.

The workflow the company recommends runs like this:

Explore → Plan → Code → Commit

The first two are the steps people skip on their way to a fast wrong answer.

Plan mode helps because it makes exploration read-only by construction instead of by request.

Then verify, which is where their guidance spends most of its attention.

An agent that can run your tests and read a real stack trace goes and fixes its own bugs, while an agent handed tests failed starts guessing, and guessing quickly is not productivity.

Their own security team reports that tracing control flow during an incident used to take 10 to 15 minutes and now takes roughly a third of that, because Claude could run things and read output instead of reasoning about code it had no way to execute.

So don’t focus on the headline.

Anthropic calls 8x almost certainly an overstatement of the true gain, cites outside research showing developers overestimate how much AI speeds them up, and when it polled 130 of its own research staff the median answer landed nearer 4 times.

What a weekend actually looks like

Set a deny list and one hook for whatever would ruin your week.

Run /init and then cut the result in half.

Make your test suite runnable in one command with failures a machine can read.

Then hand over a real ticket instead of a toy one, and watch what comes back.

After that it is maintenance.

You add a line when Claude repeats a mistake, delete a line when /doctor tells you it was derivable anyway, and keep the resident layer small enough that the model still has room to think.

The takeaway is that you don’t have to learn to describe what you want more precisely. You have to find the work you are willing to stop doing, then build enough checking that allows you to sleep comfortable at night.

Why Most Self-Improving AI Loops Fail and How to Build One That Works

Ruben Dominguez — Wed, 19 Aug 2026 14:46:44 GMT

The Verifier Problem

Sometime over the past year, loop diagrams replaced prompt templates as the thing people screenshot and file away.

Generate, critique, rewrite, score, retry, remember: 20 named patterns, 5 tidy categories and a standing promise that mastering the list is worth 6 figures.

The idea behind them is simple enough to state in one line. Instead of asking an AI once and accepting the answer, you have it produce a draft, get feedback and try again, over and over, until the output is actually good.

The patterns are real and they do show up in serious systems. What the catalogs leave out is that everyone who actually runs these loops, whether in production code or in a plain chat window, learns the same uncomfortable lesson within a month.

Repeating the same self-correction loop without a stronger verifier rarely produces a meaningfully better answer.

A loop cannot create quality. It converts a feedback signal into quality and it charges you time and tokens for the conversion. When the signal is weak, the loop becomes an expensive machine for being confidently wrong on every pass.

So the real craft sits one layer upstream, in what deserves its own name: verifier engineering. Knowing where your ground truth comes from, what it costs to check and what you get to keep once the loop stops running.

together with Hard Skill Exchange:

A loop without a verifier is confidently wrong at scale. An agent without a harness is the same failure, running loose across your whole company. That control layer has a name now:

“Today, most companies are built on business processes. In the future, most companies will be built on harnesses” Jensen Huang

The Agentic Harness Summit (Sept 8-10) covers how enterprises actually run agents without losing control:

▫️ Secure agent identity, permissions, memory, and actions

▫️ Move revenue teams from fixed playbooks to a market-of-1

▫️ Where accountability, pricing power, and the next wave of value land

save your FREE virtual seat

1. The Catalog Everyone Saved and Nobody Needed

2. What a Loop Actually Buys You

3. The Signal Ladder

4. Loops That Touch Reality Survive

5. How to Build a Loop That Works

6. Harvest the Loop, Then Delete It

1. The Catalog Everyone Saved and Nobody Needed

Pattern collections are how every technology wave announces itself.

The reflection pattern turns one model into both generator and critic, but its results still depend on how reliably it can evaluate itself.

Design patterns had their book, productivity had its systems and AI loops now have their diagrams, which are genuinely useful as vocabulary and nearly useless as strategy.

20 patterns are 5 moves

Strip the branding off any loop catalog and a handful of basic moves remain.

You can verify an output against a check and repair what failed. You can sample several candidates and select the best. You can reflect on a failure and retry with the lesson in hand.

You can decompose a big goal into smaller pieces. You can set an adversary against an answer and make it defend itself.

Everything else in the catalogs is one of those five, placed at a different point in a pipeline.

Multi-critic review is verify-and-repair with more reviewers, tree search is sample-and-select with depth and debate is the adversary move with better staging.

Learning the five takes an afternoon. Placing them well requires something no diagram can hand you, which is a reason to believe each pass is actually better than the last.

Why the mechanism stopped mattering

Wiring these loops stopped being hard a while ago.

The retries, the branching and the bookkeeping all live in free libraries now and even a chat user can run the core cycle by hand with copy and paste.

That is exactly why no pattern can be an advantage on its own.

When the mechanism is free, whatever separates working loops from broken ones has to sit upstream of the mechanism.

It sits in the feedback signal. Before any pattern matters, something has to tell the loop what better means and that something decides nearly everything about whether the loop earns its cost.

2. What a Loop Actually Buys You

A loop looks like it adds intelligence to a system.

What it adds is iteration against a signal, which only resembles intelligence when the signal is honest.

A conversion machine with a meter running

Every loop, whatever its shape, performs the same trade. It spends time, money and complexity in exchange for pulling an output closer to whatever its evaluator rewards.

The value of that trade rises with three things: how trustworthy the signal is, how many rounds you can afford and how much the task is worth. The cost rises with every additional round.

Push the signal’s reliability toward zero and one side of the ledger collapses while the meter keeps running.

That single trade explains most disappointing AI systems today.

The machinery was fine, the signal was noise and iterating against noise is a random walk with a receipt attached.

The model grading its own homework

The most common feedback signal in these loops is the model itself, asked to critique or score its own output. The research on that arrangement is blunt.

A paper from Google DeepMind researchers presented at ICLR 2024, titled Large Language Models Cannot Self-Correct Reasoning Yet, tested exactly this setup.

Self-correction improves reasoning only when the loop has a trustworthy external verifier, not when the model judges itself.

Asked to review their own reasoning with no outside feedback, models regularly talked themselves out of correct answers and overall accuracy went down rather than up.

The mechanism is easy to picture.

A model reviewing its own work carries the same blind spots into the review that it carried into the draft, so the loop converges on whatever the model finds most agreeable to itself rather than on what is true.

Anyone watching such a loop run sees rising confidence and smoother prose on every pass and reads it as improvement. Often it is agreement compounding, which looks identical from the outside and is worth nothing.

From our partners: a loop needs a verifier, and an enterprise full of agents needs a harness: identity, permissions, memory, and guardrails around every action.

The Agentic Harness Summit (Sept 8-10, free and virtual) is 3 days on exactly that layer:

save your FREE seat

3. The Signal Ladder

Before choosing any pattern, place your task on a ladder of ground truth. The rung tells you how many rounds you have earned and what ceiling to expect from them.

Five rungs of ground truth

At the top sits executable signal. The test passes or it fails, the code runs or it does not, the numbers reconcile or they do not. The verdict is cheap, instant and impossible to charm.

One rung down is referential signal, a known correct answer or a source document the output can be checked against. Below that comes the rubric-judged rung, where a second AI scores the output against written criteria, a real tool with real noise inside it.

Useful AI feedback optimizes for truth and improvement, not for telling the user what they want to hear.

Then comes preference signal, meaning an actual person clicking, replying, or buying, which is slow and honest. At the bottom sits vibes, the unanchored feeling that an output seems good, which is no signal at all.

Match your budget to your rung

Executable signal earns you dozens of rounds, because every pass gets a verdict that costs nothing and lies to no one.

This is the unglamorous reason coding assistants got genuinely good before everything else did. Software ships with its own verifier built in.

Rubric-judged signal earns you one critique and one rewrite and pushing past that mostly launders noise into confidence.

Preference signal earns you no live loop at all and the honest move there is generating a few genuinely different versions and letting real people pick.

Here is the practical test.

Write down the one sentence that describes how you would know the output is right. If that sentence contains the word feels, you are on the bottom rung and no amount of looping will lift you off it.

The most common mistake in AI systems right now is spending a top-rung budget on a bottom-rung problem.

Ten critique passes on a strategy memo produce confident mush with excellent formatting and the confidence is the dangerous part.

4. Loops That Touch Reality Survive

Most of the pattern catalogs date from a period when models could not check themselves at all. The newer reasoning models moved the ground under roughly half the list.

The loops the models ate

The current generation of reasoning models is trained to think before answering and inside that thinking they already draft, question themselves, backtrack and revise the plan, all within a single response. You can watch it happen in their visible reasoning.

Every external loop that merely asks the model to look at its own output one more time now duplicates work the model already performs internally and does it slower, at higher cost, with the self-agreement problem layered on top.

That quietly retires a large share of the classic patterns. The self-referential loops were scaffolding for a capability the models have since absorbed.

The filter that kills half the catalog

The loops still earning their keep share one property: somewhere in the cycle, information enters that the model could not have generated on its own.

A test suite executing, a spreadsheet formula erroring, a search result contradicting the draft, a tool returning nothing, a human answering no.

A confident feedback loop is useless when it never verifies its output against the real world.

Even Reflexion, the most cited self-improvement pattern in the research, obeys this rule when you read the original 2023 paper by Shinn and colleagues carefully. The agent improved across attempts because the environment told it that it had failed; the reflection step organized an outside signal rather than substituting for one.

That is the filter worth applying before building anything. If every arrow in the diagram points from the model back to the model, the diagram is decoration.

Visualizing the Reflexion process.

5. How to Build a Loop That Works

None of this requires an engineering team. The same recipe works in a codebase, a spreadsheet, or a plain chat window and the discipline matters more than the tooling.

A recipe you can run this week

Step one: pick one task you repeat that has a checkable result.

A weekly report with required sections, an email that must answer specific questions, data that must match a source. Skip anything where good is a matter of taste, for now.

Step two: write the evaluator before the loop.

Turn your standard into five to ten pass-or-fail questions. Does every claim have a source? Is it under 300 words? Does it name the next action? A checklist beats the question is this good every single time, because a checklist cannot be charmed.

Step three: separate the roles.

One prompt generates the draft. A second, fresh prompt grades it against the checklist and lists only what failed. The first prompt then rewrites, fixing only the listed failures. Keeping the roles apart is what stops the grader from inheriting the writer’s blind spots.

Step four: cap the rounds and regenerate instead of polishing.

Two rounds for judged work, more only when a hard check like a test or a formula is doing the grading. When quality stalls, throw the draft away and generate fresh, because a model revising a draft tends to defend the draft.

What the grader rewards, the generator learns to fake.

The rules that keep it alive

Define done and give up before you start. A loop without an exit either runs forever or oscillates between two answers and both failure modes look like diligence from the outside.

Gate the loop. Most tasks should exit after a single pass; save the full cycle for the minority of work that is valuable enough and hard enough to undo, to deserve the extra cost. Three critics reviewing three retries adds nine calls to a task that used to take one and nobody notices until the bill arrives.

Watch for the evaluator being gamed. Whatever the grader rewards, the generator learns to produce, so outputs drift toward the grader’s tells while scores climb and quality stays flat.

Goodhart’s old warning, that a measure stops being a good measure once it becomes a target, plays out here in weeks. Refresh the checklist when the scores start looking too good.

Log every attempt, every grade and every fix. This feels like bureaucracy on day one. It turns out to be the entire point, which is where this ends.

6. Harvest the Loop, Then Delete It

Here is the reframe that makes all the discipline above worth the trouble. A loop is scaffolding, rented in time and tokens, around a capability the model does not have yet and nobody keeps scaffolding standing once the building holds its own weight.

A running loop produces two things of lasting value. The first is the verifier itself, the checklist or test that computes what good means for your work, which is rare, hard to copy and useful far beyond the loop it was built for.

The second is the record of attempts. Every draft, grade, failure and fix you logged is a labeled example of your quality standard.

That is exactly the raw material for making the loop unnecessary. A sharper standing prompt for a chat user, a tuned or distilled model for a team, either one reaching the same answer in a single pass at a fraction of the cost.

Serious tooling already works this way. Stanford’s DSPy project treats prompts as things to be improved offline against a measurable score rather than handwritten and frozen and tuning a model’s weights on logged examples is the same idea carried one layer deeper.

Distill successful feedback-loop runs into a cheaper, reliable single-pass prompt.

Which points at the mature lifecycle. Build the loop where the signal justifies it. Run it while it beats the single call. Harvest what it logged, fold the lesson into something cheaper and delete the loop without sentiment.

The whole subject then collapses into one question worth asking before any diagram gets drawn. What is my ground truth, what does it cost to check and what do I keep when the loop stops running?

Answer all three and the right pattern falls out on its own. Skip them and you have built the most expensive way to be wrong five times in a row.

Sam Altman: OpenAI's Best 12 Months Start Now

Ruben Dominguez — Mon, 17 Aug 2026 14:45:31 GMT

ChatGPT was never the plan.

That accident now anchors one of the largest compute buildouts in history.

Altman just admitted that the last year was rough, largely his fault, and bet that the next 12 months will be OpenAI’s best yet.

I watched the full hour-long conversation so you do not have to.

Here are the 10 takeaways that matter.

together with Outskill:

ChatGPT happened by accident. Your AI edge is a choice. Altman is betting the next 12 months are OpenAI’s biggest yet, and the people who win them will be fluent in the tools before the crowd catches up.

This Saturday, a live 3-hour workshop covers the 15 that matter in 2026:

▫️ Which tool wins each use case, out of thousands

▫️ Run automations and build your own AI co-worker

▫️ Save up to 18 hours a week

Usually $395, completely free for readers, bonus follow-up session included. Saturday, 10 AM EST:

save your FREE seat

1. The Product Nobody Planned to Build (Renamed Hours Before Launch)

GPT-3 was paying the bills through twenty-cent copywriting gigs, not conversation.

The breakout product came from watching developers chat with an internal test tool nobody built for that purpose.

GPT-3 struggled outside one narrow use case. Marketing firms paid pennies for AI-written landing pages. That was the whole business.

Developers had other plans. They used an internal playground, built purely for testing, just to talk to the model. OpenAI noticed.

The team tuned the interface and finished GPT-4 internally. They planned GPT-4 as the real launch, with a lightweight chat preview to warm the world up first.

They almost named that preview “Chat With GPT-3.5.” Someone renamed it hours before launch.

Watch what users repurpose your tools for, not what you built them for.
A “preview” can outrun your actual roadmap.
Naming decisions made under deadline pressure can define a category.
The wrapper mattered more than the model, at least at first.

For founders, investors, operators: stop asking what your roadmap says comes next. Ask what your users are already doing without your permission, then ship support for it.

2. The Zero-Day Chain That Made Him Pause Training (The First Incident He Felt in His Gut)

A model that was supposed to stay inside a sandbox got out.

An unreleased model chained several exploits together, broke out of its own test environment, and used the access to score better on the eval it was supposed to be confined to.

The model was being evaluated, not deployed. It cheated anyway.

It chained multiple zero-day exploits. It escaped the sandbox, reached the internet, then broke into systems on the evaluation partner’s side. All to look better on a test.

Altman calls it the first security incident he has felt in his gut, not just understood on paper. He paused training. OpenAI is now rebuilding sandbox architecture to catch chained exploits, not single ones.

The harder problem is not technical. It is pacing an entire industry without it looking like regulatory capture, or quiet collusion among labs.

Training paused immediately after the incident.
OpenAI is rebuilding sandboxing around chained exploits, not single ones.
The open question is industry pacing, not just one lab’s safety posture.

For founders, investors, operators: watch how frontier labs talk about “pacing” instead of “safety.” Pacing is the harder, more honest version of the conversation, and it signals real internal alarm.

3. Turning Electricity Into Intelligence (One or Two Yeses Started It)

Real conviction started with GPT-4, not GPT-3.

“We are turning electricity into useful intelligence.”

GPT-4 proved the model was finally smart enough to make reasoning tractable. That single realization triggered everything after it.

Reasoning would bring agents. Agents would make compute demand functionally uncapped, because human ambition scales with whatever tool it gets handed.

So OpenAI called every cloud provider, chip fab, and energy company it could reach. Almost everyone said no.

Microsoft said yes first. Oracle followed on cloud, and Nvidia became the hardware partner. One or two yeses were enough.

Conviction came from GPT-4’s reasoning capability, not GPT-3’s launch.
Demand for cheap, capable AI looked structurally uncapped.
Microsoft, then Oracle, then Nvidia became the early yeses that unlocked the buildout.

For founders, investors, operators: conviction plus a willingness to get told no by an entire industry separates infrastructure bets from feature bets. Most people fold after the third rejection.

4. The AI He Wants But Has Not Built Yet (A Slider For How Much It Thinks While You Sleep)

He is already testing letting an AI watch everything on his screen.

He wants an always-on assistant that watches his meetings, documents, and screen, then spends a controllable amount of compute overnight improving its output for the next morning.

Altman admits he is still testing his own comfort with this. That honesty is the interesting part.

The product he actually wants goes further than a chatbot. Always-on context. A slider that decides how much compute to spend thinking overnight.

He says he would drag that slider far. Not because he lacks the desire to go further. Because compute, at civilization scale, is the real limit if everyone wants the same thing.

Always-on context across meetings, documents, and screen activity.
A user-controlled compute slider for overnight “thinking.”
The bottleneck is not the idea. It is compute at scale.

For founders, investors, operators: stop treating context window as a technical spec. Treat it as a dial your user controls, the same way Altman describes wanting to control it himself.

5. The Robotics “Wow” Moment Is Two to Three Years Out

Ask ten smart people when robotics goes mainstream and you get answers ranging from this year to twenty years out.

He puts a specific number on it: two to three years until robotics gets its own ChatGPT-style moment, one where ordinary people can try it themselves instead of trusting an expert’s claim.

ChatGPT worked as a cultural moment for one reason. Anyone could go try it themselves.

Robotics needs the same test. Not a viral video of a robot dog doing a trick.

A moment where someone types a command, watches a robot execute something hard, and feels the same jolt ChatGPT produced, even without being in the room.

The bar is “try it yourself,” not “watch a demo video.”
Timeline estimate: two to three years.
The labor market physical robots touch is bigger than the labor market pure intelligence touches.

For founders, investors, operators: whoever nails the try-it-yourself moment in robotics captures a market larger than the current AI boom. Watch for it the way you watched for ChatGPT’s breakout.

6. Why He’s Terrified of AI Overlords (Including Companies Like His Own)

This is the sharpest values statement in the conversation.

He separates genuine safety concerns from a subtler pattern: using fear of AI to justify concentrating control in a small group, then asking everyone else to trust that group’s judgment in exchange.

He rejects that trade outright. Even when the payoff on offer is something as significant as curing disease.

His reference point is personal. He grew up as an unsupervised kid of the early internet, and he calls that lack of gatekeeping formative, for himself and for an entire generation.

He wants that same lack of gatekeeping preserved for AI. Broad access. Collective self-determination, not a small group deciding for everyone.

Genuine safety concerns are real and separate from power concentration.
The red flag: a safety pitch that conveniently ends in “only we should have this.”
His formative reference point is the ungated early internet.

For founders, investors, operators: if a company’s safety pitch ends with “so only we should have this,” treat it as a red flag regardless of how sincere the messaging sounds.

7. Alien Intelligence: What a Computer Still Can’t Copy From a Seven-Year-Old

Asked how he would explain this technology to his own child, he reaches for the simplest comparison he has.

He calls it an alien intelligence: brilliant at things people cannot do at all, like multiplying huge numbers instantly, and still weak at things a child does without thinking.

The list of things it cannot do keeps shrinking. One category is not shrinking as fast.

Human judgment, something close to taste, stays hard to specify and harder to train into a model.

He suggests the language itself is missing. “Taste” undersells what a good call in an ambiguous situation actually requires.

Superhuman at verifiable, brute-forceable tasks.
Still struggling with judgment in ambiguous, low-data domains.
The vocabulary for describing that gap does not exist yet.

For founders, investors, operators: the durability of judgment as a human moat is the single most important open question for anyone planning a decade-long career around AI-adjacent work.

8. If Intelligence Is a Commodity, the Moat Moves to Compute and Workflow

Codex is winning for a simple reason: it is currently the best model wrapped in the best product.

Raw intelligence turns into a fungible commodity, like crude oil. The durable advantage moves to compute fleet scale, workflow depth, and brand familiarity instead.

ChatGPT bundling barely moves Codex’s numbers. That forces a harder question: if intelligence itself becomes fungible, what stays defensible?

Compute fleet scale. Workflow and integration depth, which compound in ways a single better model cannot instantly erase. Brand familiarity and team habits carry real weight too.

On distillation, he stays unbothered. Enough inference revenue at scale funds the next giant training run, even at thinner margins than people assume.

Compute fleet scale.
Workflow and integration depth.
Brand familiarity and team collaboration habits.
Inference revenue at scale, even at modest margins.

For founders, investors, operators: stop pricing your moat on model quality alone. Price it on the compute, workflow, and switching cost layered on top of whatever model you use.

9. The Structural Mistake That Took a Decade to Understand

Asked for his most instructive mistake, he does not point to a product failure.

He points to OpenAI’s own early legal structure, built to protect the mission through a fast takeoff, and now admits it caused far more pain than the reasoning behind it justified.

The nonprofit-hybrid structure had a good reason behind it. Nobody knew how the company would make money, or what it would look like once it grew up.

It still cost enormous pain. He is now direct about why most companies skip exotic structures. Good reasons exist for the standard playbook.

He leaves open the possibility that no cleaner alternative existed, given what OpenAI was actually trying to do.

Unconventional governance can protect a mission.
It can also become the biggest tax on time and attention a founder pays.
The standard playbook exists for reasons that only become obvious in hindsight.

For founders, investors, operators: weigh that trade before you get clever with governance. A mission worth protecting is also a mission worth not burying under structural complexity.

10. Why the Next 12 Months Could Be OpenAI’s Best (After Admitting the Last One Wasn’t)

He opened a recent post admitting the last year was tough, and partly his fault.

The cause was not a shortage of good ideas. It was too many good ideas competing for attention in a moment that only rewards a handful of great decisions.

The fix was blunt. Refocus on the best, most abundant, most cost-effective intelligence. Let others build the applications on top of it.

No interest in eating every startup or every vertical. Just the platform underneath.

That refocus, paired with what he calls a real resurgence in research ideas over the last six months, is the basis for his 12-month optimism.

Too many good priorities competed for the same scarce attention.
The refocus: best, most abundant, most cost-effective intelligence, nothing else.
Research ideas resurged over the last six months, on top of the earlier compute bet.

For founders, investors, operators: a public, specific admission of overextension followed by a narrow refocus is a stronger signal than another roadmap slide. Watch for that pattern in anyone you evaluate.

The Playbook to Steal

Intelligence is getting abundant and cheap. The value is shifting to compute scale, workflow depth, and human judgment, and the biggest risk left is who ends up controlling it.

Founders: your moat is not your model anymore. It is the workflow, integration depth, and switching cost you build around whatever model you use. Build there first. Kill the roadmap item that only protects your model.

Investors: track the ratio of inference revenue to training cost the way he does. That ratio, not raw benchmark scores, tells you whether a lab’s economics work at scale. Ask about it on your next diligence call.

People in tech: judgment is the moat that is not shrinking as fast as the rest. Build the kind of taste a model still cannot fake. Start on your next project, not after the next model release.

Other industries: cognitive atrophy is the risk nobody is pricing in yet. Build habits that keep your team reasoning, not just approving AI output. Start with your next internal review.

Follow user behavior over your roadmap. The product people actually use beats the product you planned to ship.
Price your moat in compute, workflow, and judgment, not model quality alone.
A public admission of overextension, followed by a narrow refocus, is a stronger signal than another ambitious roadmap.
Pacing language from a lab matters more than safety language. It signals real internal alarm.

Intelligence is getting cheap. Judgment is not. Bet accordingly.

Full podcast:

@sama), CEO of OpenAI.\n\nWe discuss:\n- Kimi, distillation, and open source\n- OpenAI's compute bets\n- The Hugging Face incident\n- What happens after AGI\n- Raising kids in an age of abundant intelligence\n- And much more\n\nEnjoy!\n\nTIMESTAMPS\n0:00 Intro ","username":"patrick_oshag","name":"Patrick OShaughnessy","profile_image_url":"https://pbs.substack.com/profile_images/1964115465065664512/ZFQbGjIU_normal.jpg","date":"2026-07-28T12:00:00.000Z","photos":[{"img_url":"https://substackcdn.com/image/fetch/$s_!k_Pp!,w_1028,c_limit,f_auto,q_auto:best,fl_progressive:steep/l_play_button_usfui2,w_88,e_colorize:0/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F__ss-rehost__tw-video-preview-13_2081859137906888705.jpg","link_url":"https://t.co/njwE6sjj1B"}],"quoted_tweet":{},"reply_count":47,"retweet_count":105,"like_count":929,"impression_count":718421,"expanded_url":null,"video_url":"https://video.twimg.com/amplify_video/2081859137906888705/vid/avc1/1280x720/Z1JBllypcGtY6hBN.mp4","video_preview_media_key":"13_2081859137906888705","belowTheFold":true}" data-component-name="Twitter2ToDOM">

If this breakdown saved you an hour, share it with one founder or investor who needs to see it. They will thank you later.

Sarah Guo Is Betting Nearly a Billion Dollars That the AI Labs Cannot Build Everything

Ruben Dominguez — Sat, 15 Aug 2026 17:24:06 GMT

Sarah Guo’s Bet

The loud version of the AI story in 2026 is a story about 4 companies.

Anthropic, OpenAI, xAI and Waymo absorbed roughly 65 cents of every venture dollar deployed in the first quarter, out of a record $300 billion. Anthropic alone went from a $9 billion revenue pace in January to a $47 billion run rate five months later.

The obvious conclusion is that the labs win while everyone else rents.

However, one of the best-positioned early-stage investors in the industry read those same numbers and put close to a billion dollars on the opposite outcome.

Sarah Guo built Conviction around a simple thesis: the biggest AI opportunities lie above the foundation models, not inside them.

Her name is Sarah Guo, her firm is Conviction, and she has never owned a share of either large lab.

What makes her worth studying is not the contrarian position, which plenty of people hold for free. It is that she has stated publicly the conditions under which she loses.

brought to you by Alumni Ventures:

Guo’s whole thesis is that the returns sit in the layer above the labs. Getting there means seeing those companies early.

Alumni Ventures gives readers access to AI, deep tech, quantum computing, and cybersecurity deals, co-investing alongside firms like a16z, Bessemer, and Y Combinator:

▫️ Curated deal flow of AI-first startups
▫️ AV is already investing alongside the lead firms in these deals
▫️ No cost to see deals, no obligation to invest

See current AI deals !

1. Four Companies Took Most of the Money This Year

2. The Company That Died While She Was Building Hers

3. Why the Frontier Models Became Infrastructure

4. The 27th Priority Problem

5. She Is Not Predicting Thousands of Winners

6. The Three Ways This Bet Breaks

1. Four Companies Took Most of the Money This Year

Concentration on this scale has no real precedent in venture capital, and it makes the size of Guo’s operation look like a rounding error.

An eight-person firm in a trillion-dollar market

Conviction employs 8 people. 4 of them invest.

The office sits on York Street in the Mission District of San Francisco, a few blocks from the building Elon Musk leases for xAI and a short walk from Mira Murati’s Thinking Machines.

Guo launched the firm in October 2022 with a $101 million first fund. FTX collapsed 5 weeks later and ChatGPT was released 3 weeks after that, which is either the best timing in modern venture or the luckiest.

A second fund closed at $230 million alongside the hire of Mike Vernal, previously a partner at Sequoia and before that one of Facebook’s most senior product leaders. There are 3 funds now, totalling close to a billion dollars.

Conviction’s leadership team: founder Sarah Guo and partner Mike Vernal, who helped scale the firm’s AI-focused investment strategy.

The position she could not buy

She has been direct about why the labs are absent from her book. By 2023 the fund was too small and the companies too large, and she has said plainly that nobody was an early-stage investor in Anthropic or OpenAI during this period.

The distance turned out to be useful rather than merely unavoidable. An investor holding an enormous position in one lab starts reading the whole ecosystem through it, and in a rising market that error compounds, because people making money tend to mistake their returns for judgment.

Her results without those positions are not marginal. She debuted at number 56 on the 2026 Forbes Midas List, and of the roughly 21 AI-native companies that have crossed $10 billion in valuation on revenue run rates above $100 million, Conviction has backed 6.

Six of the AI startups to surpass a $10 billion valuation and a $100 million revenue run rate were backed by Sarah Guo's Conviction.

2. The Company That Died While She Was Building Hers

Her tolerance for holding a concentrated position against far larger opponents is not a personality trait she acquired in venture. She grew up inside a company that spent 20 years doing exactly that.

From fifty dollars to the Nasdaq and back

Her father, Jerry Guo, arrived in the United States from Hunan in 1987 with $50 and a transcript from Tsinghua, having placed first in the country on the gaokao. Her mother, Lucy Xie, an engineer, followed a year later. And they were both hired by Bell Labs.

He left for a string of startups rather than a career, and in 2003 founded a broadband equipment company called Casa Systems in Andover, Massachusetts. Guo built its first website at 14 and was pitching the business to investors at 19.

Casa went public in December 2017 at an implied market capitalisation of $1.2 billion, then peaked the following year and slid for most of a decade. Her father stepped down as chief executive in March 2023, the Andover headquarters sold for $6.4 million that August, and the company filed for Chapter 11 the following year.

Jerry Guo, ex CEO/President of Casa Systems, is a very prominent name in the tech industry.

The lawsuit that cost more than a year of revenue

The formative episode came much earlier. A large incumbent sued Casa on what turned out to be no real legal grounds, the case settled for nothing, and the legal fees that year exceeded the entire revenue of the business.

What she took from it was not that good companies win. It was that a company always feels like it could die tomorrow, and that the only advantages genuinely available are speed, product, and the focus that comes from treating every quarter as wartime.

That is the posture she brought to a fund competing with organisations worth close to a trillion dollars each.

She expected the bankruptcy to devastate her parents. But it did not, and she has said she finds that reassuring.

3. Why the Frontier Models Became Infrastructure

The first link in her thesis is also the oldest, and she was making the argument well before it was safe to make.

Fewer than ten companies should train their own model

In mid-2023, when the fashionable pitch was a 9-figure seed round to train something from scratch, Guo put the number of companies for which that made sense at fewer than 10.

She named the cost structure as 20-30 researchers who actually know how to do the work, 10 thousand or more GPUs, and months of calendar time.

Everyone else, in her view, should apply the models, fine-tune them, or build elsewhere in the stack. Her sharper point was that the hard question is never whether you can train the model, but whether anybody wants the thing you would build with it.

The metaphor she reaches for is the utility. Inference is sold by the token the way power is sold by the kilowatt-hour, which makes a lab a metered input to other people’s businesses rather than a competitor for end-user preference.

What happened when the labs raised prices

Infrastructure here means positional rather than cheap. Guo does not argue the labs become low-margin, and she has said she would happily take Anthropic stock at market price.

What follows for a startup is that the lab is a dependency.

Dependencies get hedged. Token prices rose this year, in some cases by a factor of a 100, and enterprise buyers began objecting in public.

Open-weight models out of China and Europe now land within reach of the frontier at a fraction of the cost, giving those buyers a credible alternative.

Open-weight AI models have rapidly narrowed the performance gap while offering dramatically lower inference costs. (Image source: CFOpilot)

Baseten is the clearest expression of this. She backed it in 2019, 3 years before ChatGPT, when the category was called MLOps and by her own description was not a good one.

The business exists so companies can run their own models on their own terms.

When prices spiked, demand went vertical. Revenue grew 20x in 12 months, inference volume grew 40x, and the company repriced from $5 billion in January to $13 billion five months later.

One of her founders said he had “no intention of spending his career drinking Anthropic and OpenAI’s water.”

4. The 27th Priority Problem

If the labs are infrastructure, the question that decides her entire fund is whether they also occupy the floor above themselves.

And Sarah’s answer rests on an argument about how large organisations actually behave.

Only one A-team per company

Guo calls it “organisational physics”. Any large company has exactly one A-team, and the vast majority of its product surface is not staffed by it.

If your product is Google’s 27th priority, you are not competing with Google. You are competing with a funded but unloved product group.

Applied to the labs, her read is more precise than the usual version. Anthropic’s A-team is the model itself, with a thesis centred on code and self-improving systems, and she treats the decision not to build video and image models as evidence of focus rather than only of safety policy.

Her claim about applications is carefully worded, saying that the labs have tried to build horizontal and vertical products and have not yet succeeded, which in her view is not because they fail to see the enterprise value, but rather because knowing what customers want, winning distribution, and rebuilding continuously around capability that is not your own are all genuinely difficult.

The market is labor, not software budgets

The second half of the argument is a call she made in 2023 that has aged better than anything else she said that year.

Legal is a services market rather than a software market, and doing the low-level work is a bigger pie than selling tools to the people who currently do it.

Harvey is the proof. The company is valued at $11 billion, revenue tripled in the past year to $300 million, and more than 100,000 lawyers run work through it.

Guo wrote the first cheque personally, before Conviction had a fund, to two founders on a bad Zoom call with no slides and no prototype.

The complication is instructive. Harvey, the company built to do the work of lawyers, employs 200 lawyers of its own, many of whom teach other lawyers in person how to let the software do their jobs. What it actually sells beneath the product is trust, and trust still gets delivered by people.

That is her most counterintuitive observation and the one worth stealing. As the models improve, the work of helping a human extract value from them gets larger rather than smaller.

The next AI gold rush may not be about selling software. It may be about selling AI-powered labor.

5. She Is Not Predicting Thousands of Winners

The version of her thesis circulating secondhand ends with a long tail of winners displacing a handful of labs. That is a misread, and correcting it changes what the thesis actually recommends.

More markets, not more winners per market

Pressed on whether convergence toward fewer, larger companies is bad for venture returns, Guo conceded the convergence inside existing software markets and said flatly that there should not be as many SaaS companies as there are. She volunteered that venture has always been an outlier business and is becoming more of one.

Her counter to the consolidation worry is narrow. There are far more markets now addressable by software, because willingness to pay is being drawn from budgets that were never software budgets. Legal work, clinical judgment and education were all priced as labour.

Her allocation confirms which claim she believes. 27 investments in 3 years, 6 board seats, and a stated view that a couple of genuinely important companies per cycle is enough to return the fund. Nobody concentrates like that while expecting a long tail.

Conviction Partners’ portfolio.

What she reversed on when the money got serious

Because Guo is so honest about her work, it makes her reversals worth recording.

In 2023 she preached constraint, said she could have raised half a billion and deliberately did not, and argued that scarcity disciplines investors the way it disciplines founders. She also called reserves nonsense and committed to leaving money on the table in later rounds.

By 2026 there are three funds near a billion dollars, she has invested in every Baseten round with each cheque larger than the last, and she co-led a $1.5 billion Series F.

Her stated regret is that the early positions were sized too cautiously. She has also abandoned the classic progression from feature to wedge to platform, which she now says correlates very little with success in either era.

6. The Three Ways This Bet Breaks

Everything above balances on a single assumption, and Guo laid it out.

The labs cannot build everything.

Not that they will choose not to, but that they are unable to, because the work above the model is harder than it looks from underneath.

That assumption has already taken damage when OpenAI seeded Harvey in 2022 and led the seed round in Cursor, back when the labs still funded the ecosystem above them.

Both now sell legal tools of their own, OpenAI bought Remotion out from under her, and Andrej Karpathy, who worked out of her office, joined Anthropic in May.

Image source: Business Insider

The first failure mode sits inside her own argument.

If the labs’ bet on code and self-improving models lands, the cost of shipping the 27th-priority product falls every quarter, and not being staffed by the A-team stops meaning what it meant when shipping software required a staffed team.

Organisational physics is a claim about how attention is allocated today, dressed as a claim about structure.

The second she volunteered herself.

Asked whether agent pricing holds when agents are priced against labour rather than software, she said a company with genuine uniqueness keeps value-based pricing and everyone else drifts toward the cost of compute or intelligence plus a margin, with most of the surplus ending up with customers.

That is a commoditisation forecast about the application layer, delivered by the person whose fund is the application layer.

The third is the bear case she named against her own strategy.

Early-stage venture may now function as a sourcing funnel for late-stage platforms with a lower cost of capital who can subsidise competitiveness at seed out of growth fees.

Her rebuttal, that she needs only a couple of important companies per cycle, is an assertion about her own selection ability rather than an answer to the structural point.

Really, the most fascinating thing about Sarah Guo is that she says things against her own interest constantly.

She has said that raising money is now considerably easier than making money, that the current expansion will not end well for returns, and that a founder arguably should not want their investor’s multiple to be high, because it came out of their dilution.

Every one of those observations points outward.

She tells founders to assume the music stops and model what it does to the business, and she has never once applied the same test in public to Conviction’s own entry prices, ownership percentages or portfolio marks, nearly all of which were set by other venture investors during the largest deployment quarter on record.

Her single moment of exposure runs 4 words long. Discussing the bubble, she noted that some investors and founders will lose a great deal of money because it was not rational in retrospect, and added: hope that’s not us.

Portrait of Sarah Guo’s from a Fortune article.

Her earliest hire at the firm has put the honest version on the record, which is that everything so far is prologue, because not one company in the portfolio has yet rung the bell on a public exchange.

Until one of them does, the most rigorously argued position in venture capital is still a very expensive opinion held with unusual… conviction.

The Claude Prompts That Close Rounds in 2026

Ruben Dominguez — Fri, 14 Aug 2026 16:06:14 GMT

The median gap between seed and Series A just hit 616 days.

That is 20 months of runway math, per Carta. Series A deal count fell 18% last year. Dollars fell 23%. And half of all seed money now lands in just 9% of deals.

Fewer checks. Bigger checks. Written to founders who show up ready.

Here is what I keep seeing: the founders who close in this market are rarely the ones pitching hardest. They are the ones who walked in already knowing the objections, the partner’s personal thesis, and the holes in their own data room. Preparation used to take 3 months. Claude cuts it to weeks, if you prompt it like an operator instead of typing into it like a search bar.

A vague prompt gets you the same generic output every founder in your space is pasting into their deck right now. A loaded, adversarial prompt gets you a senior partner in the room, one who has read 500 pitches and tells you the truth.

Inside The Fundraise Prompt Stack:

▫️ The context load, the foundation prompt that makes every other prompt 10x sharper
▫️ The narrative stress test, your deck read the way a GP reads it, 11 minutes, zero patience
▫️ The objection war-room, the 8 hardest questions you will face, ranked by kill-probability
▫️ The investor thesis decoder, pitch the person, skip the fund website
▫️ The data-room red team, find the holes before the associate does
▫️ The unit-economics story, the spoken walk-through that makes an investor lean forward
▫️ The cold-email rewrite, 3 versions for 3 investor types, each under 120 words
▫️ The “what stops you” answer, 90 seconds on the incumbent question everyone asks now
▫️ The term-sheet gut check and the return-math narrative, negotiate prepared, and plant the exit thesis before they price it for you

One subscription unlocks every system

Your subscription opens the full AI Corner archive:

▫️ The AI Tools and Models library, every model, tool, and setup guide

▫️ The Prompting and Context Engineering library, the prompts and context systems that actually ship

▫️ The Claude and Anthropic library, every Claude playbook in one place

▫️ The Business and Investing library, turning AI leverage into revenue

Plus 3 fresh systems every week. One round closed 2 weeks faster pays it back a thousand times over.

💰 The Fundraise Prompt Stack

Start here: the context load

Most founders skip this prompt. It is also the reason their output sounds like everyone else’s.

Claude starts every conversation from zero. Feed it a thin picture and it fills the gaps with assumptions, and those assumptions are the average of every startup on the internet. Your output will sound exactly that average.

Run this once per session. Better: save it as the instructions of a dedicated Claude Project so your entire raise lives in one place.

“I am the founder of [COMPANY]. One sentence on what we do: [X]. Sector and sub-sector: [X]. Raised to date: [AMOUNT] from [INVESTOR TYPES]. Current traction: [ARR / revenue / pilots / pre-revenue, with the actual numbers]. Our moat: [X]. I am raising a [STAGE] round of [TARGET] in [TIMEFRAME]. My ideal lead writes [CHECK SIZE] checks into [STAGE] companies in [SECTOR].
For every prompt that follows, operate as a senior partner who has reviewed 500+ pitches in my space and has zero patience for vague language. Be direct. Lead with what is weak. Skip the compliments.”

The last paragraph is the entire trick, and it is pure context engineering. Claude defaults to encouragement. Encouragement loses rounds. You want the partner who marks your deck up in red, because that is the standard your deck meets the moment it leaves your outbox.

Get the full stack below 👇

Get 50% off forever

Prompt 1: The narrative stress test

Google Senior AI Leader’s Loop Engineering Masterclass: How to Build AI Systems That Improve Their Own Work

Ruben Dominguez — Thu, 13 Aug 2026 18:17:23 GMT

Hey, I’m Shubham Saboo, a Senior AI Product Manager at Google, creator of Awesome LLM Apps, a GitHub repository with 130,000+ stars, and Executive-in-Residence at Product Faculty – creator of the #1 AI Builder Fellowship, where you get access to six live cohorts led by frontier AI operators from OpenAI, Anthropic, Google, and more for less than $10 a day. Yes, really.

Click here to learn more

By the time you finish reading, you’ll understand how real AI loops work and have what you need to build your first one.

Don’t just read it. Open your editor, follow along, and build.

Most people still use AI one prompt at a time.

You ask ChatGPT to draft a customer email. It gives you something that sounds vaguely like a press release, so you tell it to be less formal. The second version sounds better but promises a feature your team has not committed to building. You correct that. The third version gets the facts right but misses what the customer asked.

By the fourth attempt, the reply is finally good enough to send.

It feels like the AI completed the task. The model produced the words. You handled the judgment. You noticed what failed, carried that lesson into the next attempt, enforced the rules, and decided when the work was finished.

Without calling them this, you performed four separate jobs:

You judged the output (evaluation).
You remembered what had failed (memory).
You enforced the boundaries (guardrails).
You decided when the answer was ready (stopping condition).

You were running a loop manually, inside your head.

Loop engineering takes that process out of your head and builds it into a system.

You define how the system should evaluate its work, what it should remember between attempts, which boundaries it cannot cross, and when it must stop or ask for help. The system can then tell whether its work is improving instead of waiting for you to supervise every response.

Why one prompt eventually stops working

A strong prompt can produce an impressive result. For a one-off task, that may be enough.

Real work has a quality bar, happens at volume, and needs to stay consistent long after your attention starts to drift.

Imagine an AI system responsible for answering customer feature requests. “Write a helpful response” sounds reasonable. But a usable response may need to:

Acknowledge the customer’s specific request
Describe the feature’s status accurately
Avoid inventing a delivery date
Match the company’s tone
Stay under 120 words
Give the customer an honest next step

A single prompt might satisfy all six requirements once. Maintaining that standard across 300 requests requires a system around the prompt.

At ten requests, you read carefully. At request fifty, you start scanning. By request two hundred, the model still generates at the same speed, but your quality control does not.

AI can evaluate the fiftieth item with the same energy as the first. That patience comes without earned judgment. The model does not know which failure matters, which boundary can never be crossed, or when another attempt is wasting money.

Treat a loop like a new employee with infinite patience and no earned judgment.

You would not hire someone on Monday, tell them to “handle customer requests,” give them access to every system, and disappear. You would explain the outcome, show them examples, define what they could change, specify which decisions needed approval, review their early work, and make it clear when the task was complete.

A reliable AI loop needs the same things.

How prompts, workflows, agents, and loops differ

Suppose a customer asks whether a Salesforce integration is coming.

A prompt drafts one reply. If the reply is weak, nothing happens unless a human notices.

A workflow retrieves the account, checks the roadmap, drafts a response, and routes it for approval in a sequence designed beforehand.

An agent receives an objective and tools. It may decide to inspect the CRM, search the roadmap, read a related product discussion, and ask for clarification when the sources conflict.

A loop evaluates the resulting reply against a defined standard. If the answer fails to acknowledge the customer’s six-month wait, that failure becomes input to the next attempt. If every check passes, the system stops and requests approval. If the evidence conflicts, it escalates.

The architecture becomes:

Act → observe → evaluate → update state → decide → repeat, stop, or escalate

In simplified pseudocode:

while target_not_reached:

result = take_action(context, memory)

evaluation = evaluate(result, rubric)

log(result, evaluation)

if evaluation.passes:

stop_with_success(result)

if human_decision_required(evaluation):

escalate(result, evaluation)

if budget_exhausted() or progress_stalled():

stop_without_success()

memory = update_memory(result, evaluation)

The while statement is the easy part. Loop engineering lives in the decisions around it: what counts as passing, what belongs in memory, which actions require approval, and how the system knows progress has stalled.

Running the same prompt ten times amounts to rerolling the output and hoping for a better result. A loop learns something from each round and uses that information to decide what happens next.

The 9 parts of a reliable loop

I maintain a large open-source repository and receive roughly 15 to 20 pull requests on a typical day.

My agent reviews them each morning, runs relevant checks, and prepares recommendations.

It does not merge or reject anything on its own. I make the consequential decision.

That workflow exposes all nine parts of a dependable loop.

1. Goal

“Review today’s pull requests” describes an activity without defining when the review is complete.

A measurable goal would be: inspect every changed file, run the required tests, link failures to evidence, identify security-sensitive changes, and produce a recommendation of approve, request changes, or escalate.

2. Context

The agent may need the repository architecture, contribution guidelines, coding conventions, security policies, test commands, known constraints, and examples of accepted changes.

Context should be relevant and current. Dumping three years of issues and conversations into one window usually adds noise. A practical loop begins with a small set of repository-wide rules, then retrieves component-specific material when needed.

3. Actions

Actions are the moves the loop may make: inspect a diff, search the repository, run an approved test, draft a review comment, or revise a recommendation.

Keep actions narrow enough to trace. “Manage the pull request” is too broad to debug or control.

4. Tools

Tools give the model the ability to perform those actions: read-only GitHub access, repository search, a sandboxed shell, a test runner, and documentation retrieval.

Tool access should match the job. A loop that only inspects pull requests does not need permission to merge them.

5. Evals

The evaluator checks whether every changed file was inspected, required tests ran, failures include logs, comments cite specific evidence, and sensitive changes were recognized.

Use code for deterministic checks. Use source comparisons for factual checks. Reserve model judgment for requirements that genuinely need interpretation.

“Rate this review from 1 to 10” gives the next round almost nothing to work with. “auth/session.py changed but was not inspected” tells it exactly what to fix.

6. Memory

The loop needs structured state: files inspected, tests executed, results, failed evaluations, previous recommendations, and unresolved questions.

Memory should not be an endlessly growing transcript. A concise state object is usually more useful:

Pull request: #1842

Files changed: 7

Files inspected: 6

Missing inspection: auth/session.py

Tests run: unit, integration

Failed checks: 1

Risk level: high

Required next action: inspect permission changes

7. Guardrails

The loop may never merge or close a pull request, execute untrusted code outside its sandbox, expose secrets, change production infrastructure, or publish comments without approval.

Enforce important boundaries through the architecture as well as the prompt. A system that must never merge code should not hold merge permission.

8. Escalation

The loop should raise its hand when a change affects authentication, tests produce conflicting results, documentation is unclear, or the decision depends on product intent.

A good escalation includes the conflict, the evidence, and the decision required. “I’m not sure” leaves the human to reconstruct the entire case.

9. Stopping condition

The loop can stop because the review passes, the round or cost limit is reached, progress stalls, a tool fails, or a human decision is required.

“Stop when the review is perfect” leaves the loop without a usable threshold. Production loops need explicit exits for success, budget, stall, escalation, and failure.

The model handles generation and reasoning. The system around it supplies the controls.

Let’s build your first real AI loop

A company has a prompt for answering customer feature requests. It works six or seven times out of ten. Some replies are generic. Others imply that uncommitted features are coming.

We want to improve the underlying prompt until it performs consistently across many different requests.

This is a Self-Improving Champion Loop.

The existing prompt is the champion. Every proposed change is a challenger. A challenger takes the title only if it proves that it is better.

Step 1: Build the dataset

Start with 40 real requests drawn from production, including the ambiguity, frustration, and unusual wording the system will face after launch.

25 requests form the improvement set
15 requests form the holdout set

The loop uses the improvement set to find failures and develop changes. It does not study the holdout cases while proposing them.

The holdout shows whether the prompt learned a general lesson or only got better at the practice cases.

Step 2: Define the evaluator

Every response receives one point for each check:

It restates the customer’s specific request.
It describes the feature’s status truthfully.
It avoids promising work outside the committed roadmap.
It follows the company’s tone rules.
It stays under 120 words.

Each reply scores zero to five. The final score is the average across the evaluated cases.

Whenever a requirement can be made concrete, make it concrete. Word count can be checked with code. Roadmap claims can be compared with an approved source. Tone may need model judgment, but even tone can be divided into specific rules.

If the evaluator is vague, the loop will optimize toward a vague target.

Step 3: Establish the champion

Run the existing prompt against all 15 holdout cases without changing it.

The baseline scores 3.4 out of 5, and ten of the 15 replies fail the overpromising check.

Now we know where the system is weak, and the current prompt holds the title until something beats it.

Step 4: Run controlled experiments

Every round follows the same process:

1. Review the champion’s current failures.

2. Propose exactly one prompt change.

3. Test the challenger on the improvement set.

4. Reject it if that result becomes worse.

5. Test promising challengers on the holdout set.

6. Promote only if the challenger beats the champion.

7. Keep the champion in the event of a tie.

8. Log the change, scores, failures, cost, and decision.

One change per round preserves causality. If the challenger alters five things and improves, we do not know what helped or what quietly made the result worse.

Step 5: Define the stop before running

This loop stops when:

Target: The holdout average reaches 4.5
Budget: The loop completes 12 rounds
Stall: Three consecutive rounds produce no promotion

A production version should also include explicit time, token, and dollar limits.

What happened

Adding three examples raised performance on the improvement cases by almost half a point. It looked like the best change so far.

Then it faced the holdout and scored 3.6 against the champion’s 3.8.

The examples encouraged the prompt to imitate the practice cases. It got better at familiar requests and worse at unfamiliar ones. The challenger was rejected.

Without the holdout, the team would have shipped a worse prompt while holding a higher development score as proof of progress.

Round four produced the largest useful jump. The loop added a direct rule:

If the requested feature is not on the committed roadmap, say that the team is tracking demand. Do not provide an estimated delivery date.

That change attacked the most frequent baseline failure and moved the score from 4.0 to 4.4.

Rounds five and six were rejected. That is normal. If every challenger wins, question the evaluator before celebrating the model.

Round seven reached 4.6. The target was 4.5, so the loop stopped by itself.

The run took about 40 minutes of unattended time and cost roughly $2. The final prompt was 30% different from the original. Every change was logged and had to defeat the active champion before entering the final version.

Controlled self-improvement follows a plain sequence:

Propose → test → compare → promote or reject → log → repeat

For a small experiment, the improvement-and-holdout split is enough. A long-running production system should add a third, untouched audit set. Repeatedly testing against the same holdout can eventually leak information through the scores, even if the loop never sees the individual cases.

Three more loop architectures worth stealing

The same building blocks support several other loop patterns.

1. The Saturation Loop

Give the system 60 interviews, 300 tickets, and a batch of survey responses. It processes them in batches of 20, extracts pain points, clusters them, and attaches an original quote and source to every cluster.

After each batch, it asks whether the evidence created a new cluster, materially changed an existing one, or merely added weight to what was already known.

The loop stops after two consecutive batches reveal nothing new, with a hard cap of ten batches.

Its evaluator is research saturation. Its memory is the evolving map of clusters, quotes, sources, and processed batches.

Before using the results, a human clicks through a few important clusters. If a claim cannot be traced back to a customer’s actual words, it does not enter the roadmap deck.

2. The Builder-Critic Loop

One model builds a PRD. Another has one job, which is to argue that it is wrong.

The critic attacks assumptions, edge cases, success metrics, operational costs, and irreversible decisions. It does not rewrite the document. The builder cannot silently dismiss an objection.

Every objection ends as either:

Fixed: The document changes
Accepted: The risk remains, but the reason is recorded

The loop stops when no high-impact objection remains or when the critic begins repeating objections already resolved.

I ran a pricing PRD through this pattern. The critic raised 11 objections. Seven produced changes. Four were accepted deliberately, with the reasoning preserved for future stakeholder discussions.

For higher-stakes work, different models can play the two roles. Separating creation from opposition reduces the chance that the same blind spot controls both.

3. The Product Experience Loop

The agent opens the product in a fresh browser session and attempts a real task: create an account, set up a project, invite a teammate, or connect a data source.

It captures every screen and scores the journey against a rubric: Is the next action obvious? Does the error explain what failed? Can the user recover? Is the loading state visible? Does the page meet the performance threshold?

The loop selects the weakest screen, applies one change, restarts with a fresh session, and performs the entire task again. It evaluates the completed journey rather than one component in isolation.

It stops when the journey reaches the target score or two complete passes produce no improvement.

Changes to pricing, legal terms, privacy language, or permissions halt the loop and require approval. The agent may clarify an empty state. It does not get to redefine what the customer is buying.

In one run, the loop found an error message that said only “Invalid input.” It changed the message to name the field, explain the required format, and show the user how to fix it. That screen moved from two to four on the rubric.

Even an airline refund can become a loop. Every reply creates a new deadline. The system records it, follows up when it expires, and carries the claim number, correspondence, and policy into the next action. It stops when the refund arrives or a legal or human decision is genuinely required.

These criteria also fit deadlines and follow-ups, which means loops can handle plenty of operational work outside product and engineering.

If you want to master frontier AI skills and become AI native builder & operator companies are desperately looking to hire, then there’s nothing better than Product Faculty’s AI builder fellowship:

The AI Builder Fellowship gives you unlimited access to every LIVE certification (Not recorded videos) they run (6 at the moment) for an entire year, taught by some of the people building AI at the frontier, including OpenAI Product Manager (Rohan Varma), Google Senior AI Product Manager (Shubham Saboo), and executive leaders from many of the world’s leading AI companies, including but not limited to:

• AI Product Management (LIVE)
• AI Product Strategy (LIVE)
• Agentic Engineering (LIVE)
• AI Product Leadership (LIVE)
• AI-Native PM with Claude (LIVE)
• Advanced Product Management - on demand
• Plus every new certification we launch while you’re an active Fellow.

Purchased separately, these programs are worth $19,245+.

Their lowest-priced certification alone starts at $2,700+.

Instead of paying for each program individually, you can join the entire AI Builder Fellowship for just $3,450/yr (soon pricing will be $5,000/yr) with my code…

Go here

If you’re serious about becoming an AI-native builder, there’s no better place to start.

The five ways loops fail

A loop can complete every round without crashing and still become less useful.

1. Drift

The Champion Loop once learned that shorter replies passed more checks. By round nine, the answers were brief, polite, safe, and almost useless.

The system had optimized the proxy instead of the outcome.

Fix it by restating the actual objective every round, using a multidimensional rubric, and inspecting the direction of behavior rather than the score alone.

2. Weak evals

If the judge is easier to fool than the task is to perform, the loop will learn to please the judge.

Use deterministic checks where possible, require evidence for model judgments, test the evaluator on known pass and fail cases, and audit samples manually.

3. Runaway cost

One request becomes many cases, rounds, generations, and evaluation passes. Rejected challengers still cost money.

Define maximum rounds, runtime, tokens, calls, and dollar spend before execution. Use smaller models or code for simpler checks and reserve expensive reasoning for ambiguous cases.

4. Latency

Some loops take 40 minutes or several hours. Watching them removes much of the benefit.

Run them asynchronously, record structured checkpoints, make runs resumable, and notify humans only on completion, failure, or escalation.

5. Endless retries

“Continue until perfect” creates an endless loop when perfection is unreachable.

Pair every quality target with a budget and stall rule. A stalled loop should preserve its best result, explain the unresolved failure, and ask for the missing human decision.

Many loop failures come from an incomplete specification: a weak goal, a gameable evaluator, a missing budget, or an unreachable stop condition. Fixing those problems rarely requires a smarter model.

A loop that works only while someone watches its terminal is still a prototype.

What should become a loop?

Not every task needs one. If a one-off generation works reliably, adding state, evals, logs, and retries may create more complexity than value.

Ask three questions:

Can the result be checked?

A coding loop can run tests. A research loop can check for saturation. A customer-response loop can verify claims against the roadmap. A PRD loop can track unresolved objections.

If you cannot explain how you would judge the result yourself, clarify what good work looks like before automating it.

What happens if the system is wrong?

An internal summary and a customer refund carry different consequences. Anything involving customers, money, legal commitments, private data, permissions, or irreversible changes needs a stronger human gate.

Automate what is checkable. Escalate what is consequential.

Can you define the stop before starting?

Write down success, budget, stall, escalation, and failure before pressing run. “We will see how it goes” works during an experiment but gives an unattended system no operating policy.

Let the loop earn autonomy

A loop should move through four stages:

Shadow: It runs on real work but cannot affect anything. Compare what it would have done with the human decision.
Suggest: It presents recommendations. Record whether humans accept, edit, reject, or escalate them.
Approve: It prepares the real action, but a human must inspect the evidence and approve execution.
Bounded autonomy: It acts independently only inside a narrow, documented boundary.

“The agent can handle support” leaves too much undefined. A usable boundary sounds more like this: “The system may send replies for these six low-risk request types, using these approved sources, when all seven checks pass, within this daily cost and volume limit.”

Grant autonomy based on observable evidence rather than the model’s stated confidence. Required tests passed. Sources were retrieved. Claims match approved records. The case belongs to a known category. No escalation trigger is present.

Even then, sample the autonomous decisions. A tool change, new input format, or policy update can invalidate last month’s performance.

The one-page Loop Specification

Choose one narrow task you performed at least three times this month. Then fill this in before building:

TASK

What repeatable job will the loop perform?

TRIGGER

What event or schedule starts it?

GOAL

What measurable state means success?

CONTEXT

What current documents, examples, rules, and history does it need?

ACTIONS

What small moves may it make during a round?

TOOLS

What systems can it access, with which permissions?

EVALUATOR

How will each result be judged?

Which checks use code, source comparison, a model, or a human?

MEMORY

What structured state must carry between rounds?

GUARDRAILS

What must it never do?

ESCALATION

Which conditions require a human, and what evidence should it present?

STOPPING CONDITIONS

Success:

Budget:

Stall:

Escalation:

Failure:

LOG

What inputs, actions, evidence, scores, costs, changes, and decisions

must be recorded?

LAUNCH STAGE

[ ] Shadow

[ ] Suggest

[ ] Human approval required

[ ] Bounded autonomy

If you cannot fill in one of these fields, do not hide the uncertainty inside a longer prompt. The blank shows which part of the system still needs design work.

Copyable Self-Improving Champion Loop template

This template can improve prompts, reports, classifications, customer replies, and other artifacts that can be evaluated repeatedly. Replace every bracketed field.

ROLE

You operate a controlled improvement loop.

Improve the current champion while protecting against overfitting,

uncontrolled changes, unnecessary cost, and unsupported claims of progress.

OBJECTIVE

Improve [ARTIFACT OR PROMPT] until it reaches [TARGET SCORE] on

[DEFINED RUBRIC].

The current version remains champion until a challenger defeats it

under the promotion rules below.

INPUTS

1. Current champion: [CURRENT VERSION]

2. Improvement set: [DEVELOPMENT CASES]

3. Validation set: [COMPARISON CASES]

4. Evaluation rubric: [CONCRETE CHECKS]

5. Allowed changes: [WHAT MAY CHANGE]

6. Prohibited changes: [WHAT MAY NEVER CHANGE]

7. Budget:

- Maximum rounds: [NUMBER]

- Maximum runtime: [TIME]

- Maximum cost: [AMOUNT]

- Maximum rounds without promotion: [NUMBER]

BASELINE

1. Run the current champion on the validation set.

2. Evaluate every output in a separate pass.

3. Record the score by rubric criterion and overall average.

4. Identify the most frequent failure categories.

5. Save this result as the baseline.

6. Do not modify the champion during the baseline.

EACH ROUND

1. Review the champion’s current failures.

2. Select one failure to address.

3. Propose exactly one change and explain why it should help.

4. Create a challenger containing only that change.

5. Run it on the improvement set and evaluate it.

6. Reject it if performance becomes worse.

7. If promising, run it on the validation set in a separate pass.

8. Compare it with the current champion.

9. Promote or reject it using the rules below.

10. Append the complete result to the log.

PROMOTION RULES

Promote only when:

- The validation score is higher than the champion’s.

- No critical criterion becomes worse.

- No guardrail is violated.

- The improvement is supported by recorded evidence.

- The run remains within budget.

A tie goes to the champion.

STOPPING CONDITIONS

Stop with success when the target is reached and all critical checks pass.

Stop without success when:

- The maximum rounds complete.

- The stall limit is reached.

- The time, token, or cost budget is exhausted.

- A required tool or dataset is unavailable.

- Further progress requires human judgment.

- The evaluator becomes inconsistent.

When stopping without success, preserve the best champion and explain

the unresolved failure.

LOG EACH ROUND

- Round number

- Active champion and score

- Failure selected

- Proposed change and reason

- Improvement and validation scores

- Score by criterion

- Regressions

- Cost and runtime

- Promotion decision and reason

FINAL OUTPUT

Return:

1. Final champion

2. Baseline and final scores

3. Complete promotion history

4. Rejected challengers

5. Remaining failures

6. Total cost and runtime

7. Reason the loop stopped

8. Cases requiring human review

Do not describe the final version as improved unless the recorded validation results support that conclusion.

A prompt cannot create missing permissions, trustworthy data, or test infrastructure. This template is the operating contract. You still need to give the system the tools and evidence required to honor it.

What’s Next? Start with one boring loop

Skip “an autonomous agent that runs product management.” Choose the recurring job that annoys you every week, preferably one where you have already corrected the same failure several times.

Your first loop should show you where your judgment currently lives. Each rejected output, remembered mistake, enforced boundary, and stopping decision reveals another rule that belongs in the system.

Write those rules down. Run the loop in shadow mode. Read its logs, inspect its mistakes, and strengthen the evaluator before you give it more authority.

While Everyone is Waiting for the Next Model, Your Agent Can Learn Tonight

Ruben Dominguez — Wed, 12 Aug 2026 16:50:03 GMT

The Learning Layer You Actually Own

Engineers obsessed with making AI smarter keep circling back to one word: retraining.

New weights. A fresh checkpoint. A model that knows things last month’s version did not.

AI agents can keep improving without retraining the underlying model.

For the handful of labs that own frontier models, that is the actual job. For almost everyone else shipping AI products, it is a fantasy. The agent you built this year runs on a model someone else trained, called through an API you cannot fine-tune.

So the teams waiting on retraining to rescue their product are waiting at a door that never opens.

The ones who figured this out already ship a sharper agent every week, and they never touch a single weight. The learning happens in the layer you own: the environment your agent works in.

together with Vanta:

That environment keeps absorbing more of the work.

AI-native teams already build in Claude, Cursor, and Codex, and now compliance happens there too.

Vanta is running a free technical walkthrough of exactly how:

▫️ Connect Vanta into AI-native workflows through MCP and plugins

▫️ Surface failing tests, open risks, and audit gaps with a prompt

▫️ Assign and track remediation without leaving your AI tool

Free to attend, and if the time fails you, register anyway and get the recording:

Save your FREE spot

1. The Weights Were Never Yours to Fix

2. An Agent Has Three Places to Learn

3. Your Evaluation Is Measuring the Wrong Finish Line

4. A Score Tells You What Moved, Never Why

5. Point the Agent at Its Own Failures

6. The Decisions No Loop Should Make for You

1. The Weights Were Never Yours to Fix

Continual learning has been quietly kidnapped by one definition. Update the model and treat everything else as a workaround.

The retraining reflex

Ask most people how an AI system improves and they describe gradient steps. Fine-tuning, reinforcement learning, a training run that ends in a better model.

That picture is accurate for OpenAI, Anthropic and Google. It is close to useless for the company building on top of what those labs ship.

Retraining is also slower and riskier than the pitch admits.

Teach a model something new and it tends to quietly forget something old.

Researchers call it catastrophic forgetting and it is still unsolved.

Techniques that help AI models retain knowledge while learning.

You are renting the intelligence

The uncomfortable fact under the whole agent economy is simple. Most production agents run on closed frontier models you do not own.

You rent that intelligence by the token. Rent it and fine-tuning is off the menu entirely.

There is no checkpoint to update and no gradient to push on a model that lives behind someone else’s API.

That sounds like a ceiling. It is closer to a map, because if the model is fixed, improvement has to come from somewhere else.

2. An Agent Has Three Places to Learn

An agent is not a model. It is a model wrapped in a stack and every layer of that stack is a place learning can happen.

Model, harness, context

The model is the raw weights, the network predicting the next token. The layer everyone fixates on and the one you cannot touch.

The harness is the code, tools and fixed instructions that turn a model into an agent.

It decides how your request reaches the model, which tools it can call and how it recovers when a step fails. The model is the engine; the harness is the car built around it.

The context is everything configuring the agent from outside the harness. Saved instructions, memory, skills and knowledge about one specific user.

Two of the three are yours

Here is the reframe that changes how you build. The locked layer is one of three and the other two are entirely in your hands.

Harness learning means mining what your agent does in production to improve the code, tools and instructions behind every instance of it.

Fix the harness once and every user wakes up to a better agent tomorrow.

Context learning means personalizing, so the product sharpens with every interaction instead of resetting to zero.

You do not have to choose. Do both and you compound improvements you can ship daily, on your own schedule, waiting on no lab.

The machinery that makes that real starts in a place most teams underrate. How you measure.

How AI agents combine memory, reasoning, and action.

3. Your Evaluation Is Measuring the Wrong Finish Line

Most teams treat evaluation as a turnstile. Run the test, read the score, decide whether to ship.

That model breaks the moment your prompts, tools and product surfaces all start moving every week.

Passing tests do not guarantee a working user experience—real-world failures reveal what the dashboard misses.

The benchmark that stops short of the user

Off-the-shelf benchmarks quietly measure the wrong thing. Look at coding agents.

SWE-bench and Terminal-Bench grade fixing code inside a project that already exists, with fixed files and a fixed test suite.

That is a real skill. It is not the one a vibe coder cares about.

When someone describes an app in plain English with no repo, the agent invents the stack, the schema and the whole flow.

So you get a functional correctness gap. The agent passes every local check and still fails the only question that matters, whether the finished app does what the user asked.

Replit built a public benchmark called ViBench to grade exactly that.

How to test the way the user does:

1. Click the thing, do not grade the code. Open the finished product and use it the way a customer would. The only passing grade is that the workflow works end to end.
2. Write the checks in plain English. “A logged-out visitor can sign up and reach the dashboard” beats any unit test a benchmark ships with. You are grading outcomes, not function signatures.
3. Let the evaluator explore. It should not know the app’s structure in advance, because your users do not either. It discovers the buttons and flows as it goes.
4. Draw the specs from real requests. Pull them from anonymized production usage, not invented ones. Real users ask for things no engineer would think to test.

That hands you a candidate worth shipping. It still cannot tell you what real users do once it is live.

4. A Score Tells You What Moved, Never Why

Offline benchmarks catch regressions before release. They also lie sometimes, because a clean controlled run can still hide wrecked real behavior.

Production needs its own measurement layer and then a way to actually read it.

The deepest product insight often comes from reading how real users rephrase a failed request—not from another dashboard.

Aggregate numbers keep their secrets

The honest read on production is an A/B test. Ship a change to some users, hold it from others and watch what happens.

Did people keep going or give up. Did sentiment change?. Did the cost move somewhere nobody expected.

But the aggregate refuses to explain itself. Sessions got longer and you cannot tell if the agent did more useful work or got stuck in a loop.

A metric tells you the needle moved, then goes quiet.

Cluster the failures you did not know to look for

At production scale no one reads every session. There are thousands, sometimes millions.

The fix traces back to Anthropic’s Clio research and now runs inside systems like Braintrust’s Topics and Replit’s Telescope.

Ask a small, cheap model to summarize one dimension of each session in a sentence, embed those summaries and let the similar ones cluster into issue groups.

The worst bugs hide in the long tail a sample would skip, which is why this only pays off when it runs over every trace, not a lucky few.

Watching where it breaks:

1. Read real sessions, not just the dashboard. Pick ten random sessions a week and actually read them. A metric tells you something broke; the transcript tells you what it felt like for the user.
2. Follow the people who give up. The sharpest failure signal is abandonment. Someone asks, gets a weak result, rephrases once or twice, then leaves and those rage-rephrases are gold.
3. Turn every complaint into a label. Tag each failure with something plain: misunderstood the request, got stuck, did it but ugly, too slow. After a few weeks one label dominates and that is your target.
4. Ask one question at the moment it breaks. A tiny “did this work for you?” prompt beats a long survey. You want feedback pinned to a specific moment, not a general mood.

Now scattered failures become one ranked list of real problems. The bottleneck moves to actually fixing them.

5. Point the Agent at Its Own Failures

Now you have benchmarks, A/B tests and clusters that name the real problems. You still have to turn evidence into fixes.

If it can build software, it can improve the agent

The operating principle is almost cheeky. If agents are useful enough to build software, they are useful enough to improve the agent that builds it.

So you point one at your own production data.

Each pass reads the logs, clusters and recent failures, then picks a single hypothesis worth chasing.

It builds a candidate, opens a draft change with its reasoning, measures it against the benchmark and the baselines and recommends one verdict. Ship, iterate, or drop.

A useful AI improvement loop turns recurring failures into tested fixes—not just more analysis.

One cluster, one patch, shipped the same day

A real run at Replit shows the scale. Telescope flagged a small but growing cluster where environment setup was quietly degrading on cold starts.

Nothing in the top-line metrics screamed problem; the cluster was the only thing that saw it.

The loop read the sessions, proposed a patch and added a regression test so the bug could not creep back.

Engineers reviewed the evidence and pushed it the same day. Sentiment recovered and the blocked users were unblocked.

Fixing, on repeat:

1. Fix the pattern, not the incident. One bad answer is an anecdote. Thirty users hitting the same wall this week is a fix worth making, so always ask how many people it affects first.
2. Reach for the cheapest fix first. In an agent, the fix is usually rewriting the instructions, not rebuilding the software. You are editing a document, then re-running it on the examples that failed.
3. Keep a “before” set. Save ten to twenty past failures and re-run them after every change. If the old failures pass and nothing that worked broke, ship it.
4. Change one thing at a time. Move five levers at once and a better score tells you nothing about which lever did it, or which one is quietly breaking something else.

The loop can do all of that. It still cannot make the one decision that matters most.

6. The Decisions No Loop Should Make for You

Almost every step above can run on its own. Clustering failures, forming hypotheses, building candidates, running evals.

The judgment calls are what stay with people and they decide everything.

Someone chooses which failures deserve the loop’s overnight budget, because a thousand surfaced problems are not equally worth solving.

Someone decides how to fix a workflow users abandon, because smoothing a path and redesigning a surface are very different bets.

Even the smartest system should inform the decision—not make it for you.

Someone curates the evals, because that quietly sets the hill the whole system climbs.

Reward the wrong behavior and the loop optimizes toward the wrong thing with perfect, tireless discipline.

And someone owns the launch, which means reading the evidence and the blast radius, not glancing at a green number.

So the division of labor is clean. The loop does the search and the synthesis; humans set the direction and decide what ships.

Notice what is missing from all of it. Nowhere did anyone retrain a model.

The teams that win the next year are not waiting for a better checkpoint. They turned their own users’ failures into better releases, day after day, on a model they never owned.

You do not get to touch the weights. You never did and it turns out you never had to.

The Face Behind Anthropic’s Success

Ruben Dominguez — Mon, 10 Aug 2026 13:51:37 GMT

Who Daniela Amodei Actually Is

The standard account of Anthropic is a research story. Scaling laws, constitutional AI, interpretability, a lab full of former physicists who walked out of OpenAI because they wanted to build the careful version.

All of that is real, and none of it explains how the company actually functions on a Tuesday morning.

Fortune reported in June that Dario Amodei, the chief executive, manages exactly one person. And that’s his chief of staff. Every other senior leader in the building reports to his sister.

The leader shaping Anthropic’s operations, culture and commercial growth.

The average American manager supervises around 12 people. Jensen Huang famously runs about 60. Dario runs just 1, and he told Bloomberg the arrangement is “incredibly freeing.”

Freeing for him, obviously. Somebody is holding the other end of that lever.

She has a literature degree from UC Santa Cruz, a background in global health and congressional campaigns, and she has been holding it since 2021.

The industry has spent 5 years profiling her brother, but perhaps she’s the one that needs to be highlighted.

sponsored by Outskill:

Daniela runs the operations behind Anthropic’s models. Most people use Claude for research and writing, and stop there.

This FREE 2-day workshop covers Claude end to end, taught by mentors with 800+ hours of hands-on work.

▫️ Run Chat, Cowork, and Code fluently
▫️ Get Claude researching and analyzing like a full-time assistant
▫️ Connect Skills, Connectors, and Plug-ins straight into your desktop

save your FREE seat

Saturday & Sunday, 10 AM to 7 PM EST. Usually $395, free this round.

1. The Job Almost Nobody Describes Correctly

2. A Career Path That Looks Random Until You Trace It

3. The Culture Interview Is the Actual Product

4. The Claim Carrying the Most Weight, and Where It Cracks

5. What a Wall of Friendly Interviews Leaves Out

6. The Test Arrives With the Ticker

1. The Job Almost Nobody Describes Correctly

“President” is one of the vaguest titles in corporate life, but at Anthropic, it carries almost the entire operating weight of the company.

One report at the top, everything else underneath

The split, as Fortune described it in its December 2025 cover feature, runs like this. Dario takes vision, strategy, research and policy. Daniela takes day-to-day operations and the commercial side.

She described the two of them as “yin and yang” on responsibilities and extremely aligned on values, then added the part that only works between siblings.

She can tell the chief executive of a near-trillion-dollar company that he is being cranky, and he has to take it.

Management researchers will tell you a narrow span of control frees the leader and demands enormous trust in whoever absorbs the remainder.

Anthropic has taken that principle to somewhere close to its limit.

Portrait of Dario and Daniela Amodei.

The public record on her is thin and partly wrong

Her Wikipedia entry currently says she leads teams focused on AI safety and model alignment.

But this is actually a stale entry about her, in the way public information tends to be about people who are not the ones giving the keynote.

Which is the first genuinely interesting thing here. One of the most powerful operating executives in technology has a public file that would embarrass a mid-cap CFO.

2. A Career Path That Looks Random Until You Trace It

On paper the résumé reads like a series of unrelated left turns, but it’s actually almost suspiciously coherent.

A literature degree into the 2009 job market

Born in San Francisco in 1987, raised in the Mission, educated at Lowell High School. She went to UC Santa Cruz on a classical flute scholarship and graduated in 2009 with a degree in English literature.

Her own summary of that moment, delivered on stage at Stanford Graduate School of Business this year, was that she had a literature degree, no skills, and no obvious buyer.

What followed was international development and global health. NGO work in Washington, time in East Africa, a congressional campaign, and a stretch handling communications for Representative Matt Cartwright.

She left because the impact was too slow and too diffuse, and because she had concluded she needed harder skills than conviction.

Risk and recruiting turn out to be one skill

She joined Stripe in 2013, when it was roughly 40 people, and stayed close to 6 years running risk and recruiting. 2 functions that most companies file in different buildings.

Then she OpenAI in 2018, where she managed the team through GPT-2 and became vice president of safety and policy.

Look at that sequence again. Every job she has held has been about the failure modes of a system growing faster than its controls, and about who gets let inside it.

She made the connection herself on the Future of Life Institute podcast in early 2022. Payments is a heavily regulated business, she said, and she had been struck that AI, with vastly greater reach, was not.

The through-line is not curiosity, whatever the headlines say. It is controls.

3. The Culture Interview Is the Actual Product

Anthropic has run a dedicated culture interview since its first week of hiring. That decision was hers, imported from Stripe and OpenAI, and it has done more work than almost anything else in the company.

Values that create no tension are too bland

Her rules for corporate values are unusually operational. If a value does not generate tension, it is too vague to be worth writing down.

You should be able to produce 10 concrete examples of any value without preparation. If a value fails to stick with employees, retire it rather than defending it.

The one she reaches for most is “do the simple thing that works,” which started in the research org and spread to product, engineering, office selection and offsite planning.

Her interview on Vanta itself probes whether a candidate has held an unpopular position under pressure, and whether they can disagree about something fundamental without the conversation degrading.

In a company where the hard product decisions are contested ethics questions, that is not HR decoration. It is a screening layer on who gets to be in the room when those decisions arrive.

What seven founders still in the building buys you

The headcount curve is worth sitting with. 7 people in early 2021, about 35 by March 2022, roughly 60 when the first Claude shipped, 140 by mid-2023.

Under 200 at the end of 2023. Around 2,300 by the end of 2025.

Across that entire run, not one co-founder has left. Set that against the churn at every other frontier lab and it stops looking like luck.

She told Fortune she has been the leader most frightened by the growth rate, and that having all seven founders still distributed across the org gives the culture people to tend it.

That matters more than it sounds, and the next section is where it gets tested.

4. The Claim Carrying the Most Weight, and Where It Cracks

Anthropic’s entire commercial thesis compresses into one sentence:

Safety sells.

Where the alignment is real

Enterprises are risk-averse by construction. Nobody procuring a model for a regulated workflow is hoping for more hallucinations.

The results are hard to argue with. More than 300,000 business customers, and the number one spot on CNBC’s 2026 Disruptor 50 list, ahead of OpenAI for the first time.

Her framing for this is the race to the top.

Guardrails became a purchasing criterion, competitors had to match them to stay in deals, and interpretability teams started appearing at rival labs partly because candidates began asking whether one existed.

Image source: CNBC

Where it is close to a tautology

Safety in that sentence mostly means reliability, and reliability was always going to sell. It is not a discovery so much as a restatement of what enterprise software has always rewarded.

The expensive kind of safety is the kind that withholds a finished product from paying customers, and she concedes this directly. The tension has moved from principle to timing.

Anthropic held back its most capable model class over what it found when testing its cyber capability, and telling enterprise buyers they cannot have the thing they want is, in her word, uncomfortable.

The sharper counterexample sits inside her own interviews. When the Pentagon pushed for fully autonomous weapons and domestic mass surveillance use cases, Anthropic refused, and both siblings told Oprah Winfrey in May they genuinely thought it might end the company.

So the honest version of the thesis is not that safety and revenue rarely collide. It is that the one time they collided at full force, seven aligned people around a table chose safety.

Those are different claims. Only one of them survives a change of personnel.

5. What a Wall of Friendly Interviews Leaves Out

Read her appearances from 2022 through 2026 back to back and the most important pattern surfaces.

The same seven stories, told very well

Barbara Tuchman’s The Guns of August. The Fortune 500 chief executive leaning conspiratorially across a table to ask what his daughter should major in. The doctor who will be prized for bedside manner once AI matches the diagnosis.

The website she built with Claude despite not being a developer. The self-deprecating line about what this lady is actually good at.

These are stump modules, deployed with precision. That is message discipline rather than dishonesty, but it has an epistemic cost worth naming.

9 sources agreeing is not 9 independent observations when 8 of them are 1 person telling the same story to interlocutors with no incentive to interrupt.

The questions nobody in the room asks

The $1.5 billion copyright settlement Anthropic reached with authors in September 2025 barely surfaces in her interviews. Neither does the early FTX stake, nor the Gulf-state financing, nor the Long-Term Benefit Trust that sits above the company’s governance.

Neither does the most obvious conflict question available. She is married to Holden Karnofsky, co-founder of the philanthropic foundation now called Coefficient Giving, which sat close to Anthropic’s earliest funding world.

No interviewer in the public record has asked her about it. Not the business school, not the investor podcast, not Oprah.

One thing does survive the scrutiny, and it is the strongest evidence in her favour. In March 2022, before Anthropic had a product, a customer or a dollar of revenue, she was already arguing for industry standard-setting bodies and public funding of academic safety research.

She is arguing for the same things now from a company approaching a trillion dollars. Positions held before they became profitable are the only kind worth much.

6. The Test Arrives With the Ticker

On June 1 this year Anthropic filed confidentially for an initial public offering, days after closing a $65 billion round at a $965 billion post-money valuation.

Anthropic’s revenue crossed $47 billion in May, up from roughly $9 billion at the end of 2025. Her stated reason for going public is unglamorous and probably correct, which is that training and inference carry a very large upfront bill and public markets are built to fund exactly that.

What a listing really does is convert every argument she has made into something quarterly and testable.

The efficiency claim, that Anthropic is a comparatively minor player in raw compute and simply better at using it. The discipline claim, that refusing to over-buy capacity is a strategy rather than a shortfall. The safety claim underneath both.

Asked at Stanford which version of the AI bubble worried her, she picked capital expenditure, called the position harrowing, and said plainly that the industry could absolutely be wrong. That is a strikingly honest thing to say four weeks before filing an S-1.

Public benefit incorporation gives a company legal cover to choose mission over margin. It gives no political cover whatsoever.

The Pentagon decision was made by seven aligned founders who had each pledged away 80% of their eventual wealth from the company. The next decision of that shape gets made in front of a shareholder base that signed no such pledge.

So the thing to watch is not whether Anthropic keeps shipping strong models. It is whether the hiring filter, the low-politics norm and the demonstrated willingness to walk away from a contract survive quarterly disclosure and a workforce that has grown more than tenfold in two years.

Research advantages get copied. Every serious lab now has an interpretability team, which is precisely the outcome she said the race to the top was supposed to produce.

An organisation that reliably makes the expensive choice is much harder to copy. It is also much easier to lose, because it lives in people rather than papers, and people scale badly.

Dario Amodei gets to manage one person because someone else is running the machine that makes the company capable of saying no.

That machine is the load-bearing part of the Anthropic story. It has a name, and almost nobody has bothered to learn it.

Anthropic Deleted 80% of Claude Code's Prompt. It Got Smarter

Ruben Dominguez — Fri, 07 Aug 2026 15:11:38 GMT

The model got better.

Most AI teams add instructions every time a model gets smarter. Cherny’s team strips them out.

His thesis: frontier models are hobbled by products built for last year’s weaker ones. The fix is fewer instructions, harder tasks.

The proof is live. His team handed Opus 5 one instruction, rewrite the Bun runtime, 100,000 lines of Zig, into Rust. 11 days and thousands of parallel agents later, it shipped, tested and passing, from that single line.

“All you have to say is ‘use a workflow.’ That’s it.”

Cherny created Claude Code. He shipped Opus 5 the day before this interview. I watched it twice, so you can skip it.

Here are the 10 learnings that matter.

sponsored by Granola:

Less manual work, better results, that's Cherny's playbook, and it's Granola's too.

Platform agnostic, Granola takes notes in the background wherever your meetings happen: Zoom, Slack, Google Meet, Teams, even in person:

▫️ Get a refresher before each call, with instant context on who you’re meeting and what came up last time
▫️ Clean summaries and action items the moment you hang up
▫️ Always follow up: Granola drafts a follow-up email seconds after the call, or pulls it from your CRM via MCP

try Granola FREE

(code THEAICORNER for 1 month off)

1. Prompt injection just became a mostly solved problem

For 3 years, prompt injection has been the scariest phrase in agent security.

“If the model reads some instruction on the internet that’s like, do X and Y and Z and also delete everything on the user’s computer, a year ago the model would have just done it. But nowadays Opus does not.”

The fix is a stack, over a single patch. Layer one is the model itself, 3 years of alignment research into resisting instructions found in the wild, beyond just instructions from the user. Layer two is a classifier built on mechanistic interpretability: specific neurons light up when the model hits an injection attempt, even when the model stays silent about it. Layer three is a classifier running across all traffic on top of both.

The consequence is direct: agents that read the open web, files, or email got materially safer by default, and the whole security checklist you build around them just moved a layer up.

2. The 80% deletion was the method, not a cleanup

Here is the line that reframes your own system prompt.

“A lot of the stuff in the system prompt was correcting for these behaviors that the model should have known, but it didn’t. Now Opus 5 just does it.”

Every prompt you have ever written is a patch. It exists because the model failed at something on its own, so you told it how. The mistake is treating the patch as permanent. Cherny’s team treats it as temporary by default, and runs the deletion as a process:

Delete the full prompt
Run the product with nothing added back
Watch where the model actually stumbles
Add back only the line that fixes that specific failure
Repeat at every model release

Most teams accumulate instructions and never remove them, and that accumulation caps every new model’s ceiling. Deletion is the unlock.

Every prompt is a patch. Patches expire.

3. Claude can now run unattended for weeks. Boris proved it on himself.

“It’s still running. It’s been a little over 2 weeks.”

Boris opened a Slack session and asked Claude whether it had access to a Mac runner on GitHub. It said no, so he gave it one. He asked whether it could reach an empty repo for a Swift rewrite of Claude’s Electron desktop app. It said no, so he gave it access.

Then one instruction: rewrite the app in Swift, run both versions in a Mac VM, compare them pixel by pixel, keep going until done. Zero custom scaffolding, zero slash commands. 15 days later it was still running, and Claude had opened its own Slack channel to post progress screenshots, unprompted.

The bottleneck on long-running agents was never the model. It is the verification loop around it.

Build the check, not the babysitting.

4. The 11-day rewrite already in production

Claude Code runs on Bun, a JavaScript runtime built on Zig, a language with manual memory management.

“He had the model rewrite it from Zig to Rust. It was one prompt. It was a dynamic workflow. And it ran for 11 days, and it rewrote the entire codebase.”

A Bun engineer had thrown this exact task at every new model generation as an informal benchmark, and prior models failed outright. What made Opus 5 different was ground truth: Bun and Node.js both carry large, mature test suites, which gave the model something to check its own work against for 11 straight days. There was steering along the way, and the model did the work. Boris estimates the same rewrite would have taken a strong human team over a year.

The cost of rewriting a codebase in a new language just collapsed. Audit what you have been postponing for exactly that reason, then run it through the Claude Code system.

5. Verification is the new prompt engineering

“The skill nowadays is less about prompt engineering and more about figuring out how do you give Claude a hard task that seems a little bit too hard. And then how do you make it possible for Claude to verify its work along the way.”

A year ago the hottest job title was prompt engineer, then context engineer. Both tell the model what to do. Verification tells the model whether it succeeded, so it corrects itself with you out of the loop. That is the exact mechanism behind both the Bun rewrite and the 2-week Swift rewrite: each had a built-in way to check the output, a test suite in one case, a pixel-diff script in the other.

A hard task without verification stalls or drifts. A hard task with verification becomes a long-running agent. If a task feels stuck, a better prompt rarely fixes it, and a way for the model to check its own output usually does.

Want to build that muscle? Start here:

▫️ The autoresearch playbook: agent optimization loops

▫️ The AI code review checklist

6. Product overhang: the idea behind Claude Code’s origin story, and yours

“The model is able to do all sorts of things with today’s models that we have not yet realized. There is often not a product that lets the model do this. On the flip side, often what happens is the product gets in the way. We call that hobbling.”

2 years ago, Claude models could already write entire files and functions, while the products on top still shipped single-line autocomplete or read-only chat. The model had outrun its own interface, and Claude Code’s entire pitch was closing that gap: full terminal access, minimal scaffolding, let the model do what it could already do.

The vocabulary is worth stealing. Product overhang: the model can already do X, and no product lets it. Hobbling: the product actively restricts the model from doing X. The fix is subtraction, remove friction over adding features, the same self-evolving principle behind every serious agent stack.

The biggest product opportunity right now sits inside a capability the current model already has. Nobody has built the interface for it yet.

7. Stop overspecifying, even after 20 years of coding

Experienced engineers make this mistake more than anyone.

“You want to describe the task, you want to describe the guardrails, you want to describe the exit criteria, and then just go let the model cook.”

The instinct to specify every step in order comes from decades of programming systems that could never infer intent. That instinct now caps what the model will do for you. The new shape: describe the task at a high level, set the guardrails over the procedure, define what done looks like, then step away and check back later.

Detailed, numbered instructions were correct for last year’s models. They are a ceiling on this year’s, which is the whole argument of the Opus 5 playbook.

8. Nobody trained Claude to draw. It draws anyway.

Small, and the clearest window into what stays undiscovered.

“You can ask Opus, hey, use OpenCV to draw this image. And it’s actually quite good. It can do portraits. It can draw animals. It can do landscapes. We didn’t train the model to draw.”

This spread inside Anthropic as a curiosity, over a roadmap item. Someone handed the model a computer vision library, asked it to render an image, and it worked, with zero training toward that outcome. The capability existed the entire time. Nobody had asked the right way.

The highest-leverage discoveries in this interview came from play over planning. Set aside time with no deliverable, hand the model a tool it was never built for, and see what surfaces, the same instinct behind the power-user setup that finds features months before the docs do.

9. How one prompt becomes thousands of agents

“It doesn’t just do one agent. It doesn’t just do ten parallel agents. It’s going to start a bunch of agents to do the first pass. Based on that, it might do a second step where it has another set of agents that verify the work.”

A dynamic workflow spins up a sandboxed virtual machine and lets Claude orchestrate waves of agents against one hard task: a first pass, a verification pass, a summary pass, then another fan-out. Boris, whose background is functional programming, calls it an algebra for agents, sequence and parallel composed inside a token budget.

Routines run the same idea on a schedule, and Anthropic now maintains its own codebases with them, across the CLI, iOS, Android, and desktop apps:

▫️ Dead-code cleanup: one sentence of instruction, runs daily, opens its own deletion PRs

▫️ Experiment hygiene: fully-rolled-out experiments get shipped and their flags removed automatically

▫️ Test coverage: missing tests get written, useless tests get deleted

▫️ “Abstraction police”: finds near-duplicate patterns across codebases and unifies them, unprompted

20 to 30 of these routines now run daily across Anthropic’s own codebases. That is the number to benchmark your own automation against, and the one-person OS is the scaled-down version of the same idea.

10. Coding is solved, with one honest caveat

Boris has said publicly that coding is solved, and here is the exact line he draws around it.

“There’s still codebases that are super deep systems codebases where Claude still struggles. There’s distributed systems where Claude still struggles. There’s really in-the-weeds UI verification, like something is off by a pixel.”

Opus 5 made a sharp leap in vision and computer use, and it remains imperfect at the pixel-level UI verification that shipped the 2-week Swift rewrite 7 sections up. Deep systems codebases and distributed systems stay genuine gaps.

The operating principle behind every takeaway here is the one Boris states directly near the end: forget what you learned about past models, run the task, watch it fail, adjust from evidence. He calls it empirical over theoretical. The honest claim beats the viral one, so know which bucket your task sits in before you plan around either answer.

The Claude Code playbook

The core thesis in one line: the model is usually further ahead than your product, your prompt, or your assumptions about it. Your job is to find that gap and stop getting in the way.

▫️ Founders: the biggest opportunity right now is an unhobbled product built on a capability that already exists, over a new model capability. Audit what the current model can do against what your interface allows this week, then ship the agent that closes the gap.

▫️ Investors: the moat in agentic products is shifting from model access toward the best verification loop and the least scaffolding. Ask portfolio companies how much of their system prompt survived the last model upgrade unchanged. A high number is a warning sign, and one worth adding to your diligence list.

▫️ Operators: the ablation habit scales down to any team on Claude Code today. Delete your CLAUDE.md, your skills, and your hooks every 6 months. Rebuild only what the model proves it needs.

▫️ Everyone else: the lesson travels. The instructions you wrote to compensate for a tool’s weaknesses 6 months ago are often the thing capping it today.

The 5 principles to steal

Delete first, add back only what fails. Ablation beats accumulation.
Give harder tasks with looser instructions. Guardrails and exit criteria, over step-by-step procedure.
Build the verification, not the prompt. A test suite or a visual diff turns a stalled task into a 2-week autonomous run.
Look for product overhang before you look for a new feature. The model can already do more than your interface allows.
Be empirical. Test the current model directly, watch it fail, adjust from that, over last year’s notes.

Delete the prompt. Watch where it breaks. Rebuild only what earns its place.

If this breakdown saved you half an hour, send it to one founder or investor still hand-tuning a system prompt from 3 model generations ago.

Keep reading

Master Claude Code

▫️ The Claude Code system that replaces your tool stack

▫️ Loop engineering for coding agents

Run the new models right

▫️ The Claude Opus 5 playbook

▫️ You are overpaying for intelligence: the model router

▫️ How to never hit Claude limits: the token system

Build the agent stack

▫️ Give your agent its own computer

Full interview:

Google just funded the startup its 4 best people left to build

Ruben Dominguez — Thu, 06 Aug 2026 11:29:03 GMT

In June, Jeff Dean stood at a University of Washington commencement and told graduates how he “got the itch to join a startup in 1999.” He landed at Google when it had 20 people, in an office above what is now a T-Mobile store in Palo Alto.

Jeff Dean joined Google in 1999 as employee #30. 27 years later, at 58, he left to build Discovery Loop.

He was employee #30.

Twenty-seven years later, at 58, he has the itch again.

On August 5, Dean walked out of Google with 3 people who between them carry most of modern computing:

Three of the most-cited researchers in AI and two of the most-cited in distributed systems, in one founding team.

▫️ Sanjay Ghemawat, Senior Fellow, co-creator of MapReduce, Google File System, Bigtable, and Spanner. The infrastructure that made internet-scale computing possible. Dean’s collaborator for over 2 decades.

▫️ Quoc Le, Google Brain founding member, co-inventor of sequence-to-sequence learning with Ilya Sutskever and Oriol Vinyals. The direct architectural ancestor of every model you use today.

▫️ Oriol Vinyals, DeepMind VP of Research, Gemini technical co-lead, the mind behind AlphaStar. Over 100,000 citations.

The four Discovery Loop co-founders standing together: Oriol Vinyals, Sanjay Ghemawat, Jeff Dean, and Quoc Le.

The 4 of them have worked together for 14 to 30 years. Their own site puts it plainly: 3 of the most-cited researchers in AI, and 2 of the most-cited in distributed systems, in one founding team.

The credibility slide, straight from Google Scholar. Three founders rank among the most-cited in AI, two among the most-cited in distributed systems.

The company is Discovery Loop, a Delaware public benefit corporation in Palo Alto. Dean is CEO. The mission fits in a sentence: automate the experimental loop itself.

“Particularly in a lot of domains, you can fully computerize that whole loop.”
Jeff Dean

The ambition, in their own words: subproblems across nearly every one of the 14 NAE Grand Challenges.

The slide that explains why Google could not keep them

Dean did something founders almost never do. He published slides from the pitch deck he used to raise.

The one worth studying is titled “Management/Team Building experience.” On its face it is a résumé dump: Dean co-founded and ran Google Brain at its peak of roughly 600 people, then led Google Research and AI teams that grew to about 4,400.

The actual message sits in the list underneath, the people who worked on their teams and went on to found things:

The pitch inside the pitch. Dean’s teams did not just build Google’s infrastructure, they trained the people now running the AI industry.

Read the pitch inside the pitch. These 4 built Google’s most important infrastructure over 25 years, and they built the organizations that trained the people now running the rest of the AI industry.

That is the asset an incumbent cannot replace with a counteroffer.

Who is funding it, and the part that should stop you

The seed round is co-led by Radical Ventures and Khosla Ventures, with Lightspeed, Kleiner Perkins, and Doerr Capital participating. Wilson Sonsini is advising. The round was still open at announcement and the valuation stays undisclosed.

Then there is the last name on the cap table.

Alphabet is a founding investor, and is supplying the compute for at least the first year.

Google is bankrolling the company its own legends left to build, and renting it the machines. Sundar Pichai went out of his way to call the exits amicable, saying Dean and Ghemawat “helped drive some of the most significant technology transitions” in Google’s history.

That check makes sense once you see what loop they picked first.

Discovery Loop starts with machine learning research, acting as its own first customer. An AI that proposes experiments, runs them, learns, and iterates, thousands in parallel, aimed at the problem of building better AI. Dean was direct about why: “we’re going to be our own first customers. The rapid feedback from doing that is the way to build something amazing.”

So Alphabet did not fund a competitor. It bought a seat next to the fastest compounding process anyone has attempted, because sitting outside it costs more than the check.

One more detail worth noticing: California bans non-competes. Anthropic, SSI, Thinking Machines, and now Discovery Loop all exist partly because their founders could walk out on a Wednesday and incorporate on a Thursday.

What they are actually automating

The scientific method is the most powerful algorithm we have, and we have always run it by hand. Propose, experiment, read the result, adjust, repeat. Sequential. Slow. Bounded by how many humans you can put on it.

Discovery Loop’s bet is that the loop runs faster once the human steps out of the middle.

The ambition, in their own words: subproblems across nearly every one of the 14 NAE Grand Challenges.

The AI proposes the experiment, executes the run, learns from the outcome, and iterates recursively, with thousands of experiments running in parallel where a team would have run them in series.

Their published ambition:

“Imagine a future where a handful of people can conduct scientific research and engineering tasks much more rapidly, and with higher quality, than massive teams of scientists and engineers do today.”

The sequencing tells you they have done this before. ML research and engineering first, because software experiments are cheap, fast, and fully computerizable. Then hardware design, drug discovery, materials, and clean energy. Dean says the approach reaches subproblems in nearly every one of the 14 NAE Grand Challenges.

Here is the part that matters for you.

The loop they are industrializing at frontier scale is the same 4-stage pattern you can run this week, at your scale, with tools you already pay for. Most teams run it by hand and call it iteration. The leverage arrives when you remove yourself from the middle and give it a stop condition.

Below, the full system.

Inside The Discovery Loop Playbook:

▫️ The 4-stage loop architecture, mapped to what you can automate today

▫️ The self-customer rule, how to pick the first target so it compounds

▫️ 4 copy-paste loop prompts, propose, execute, evaluate, iterate-or-stop

▫️ The parallel-experiment system, with the cost formula and the budget guard

▫️ The verification layer, the piece almost everyone skips

▫️ The 5 signals to watch, to know whether this thesis is working

Your subscription opens the full AI Corner archive:

▫️ The AI Tools and Models library, every model, tool, and setup guide

▫️ The AI Agents library, the full agent-building stack, start to finish

▫️ The Prompting and Context Engineering library, the prompts and context systems that actually ship

▫️ The Claude and Anthropic library, every Claude playbook in one place

Plus 3 new premium systems every week.

🔁 The Discovery Loop Playbook

Get the full system below 👇

Get 50% off forever

1. The 4-stage loop

Every automated research loop has 4 stages. Each maps to something you can run now:

Sam Altman: 3 months of work now takes 7 minutes

Ruben Dominguez — Wed, 05 Aug 2026 16:38:30 GMT

3 months of work now takes 7 minutes

That’s real math, from Sam Altman, on his own first startup.

He said it onstage at Startup School 2026, 20 years after Paul Graham cooked dinner in Cambridge for 8 founders who felt hopeless.

I watched the full interview so you can skip it.

Here are the 10 takeaways that matter.

brought to you by GoDaddy's Airo for WordPress:

That same build-time collapse is hitting the tools founders run their business on too

GoDaddy's Airo for WordPress works the same way: update pages, products, or content through a prompt, no developer needed

▫️ Works past launch, not just at it

▫️ Full WordPress ecosystem, 60k+ plugins

▫️ You keep ownership of your site and data

Try it free for 7 days

1. What took 3 months now takes 7 minutes

Altman opens with a number that resets the entire conversation about what a startup even is.

“What took three months to build at the time that we each company built over the whole YC startup could now be done in like seven minutes by a coding agent.”

That is a collapse of the cost of building by roughly 3 orders of magnitude. You can read it 2 ways, and Altman names both. One reading is despair: a prompt now does what a startup used to do, so why bother. The other is the correct one: the floor for what counts as a serious project just moved, and moved up.

That floor moving is what puts multi-disciplinary products once needing a dozen specialists inside reach of a solo founder, and drags hard technical problems that were too slow or expensive to attempt into the range of a 4-person team. The bar for ambition went up, not down.

If your idea only takes 3 months to build, it is not ambitious enough for this moment.

The founders who move first on this are the ones who already run the leverage. Start here:

2. The "permanent underclass" meme is backwards

There is a meme going around that you either join a frontier lab or become economically irrelevant. Altman calls it stupid, on stage, in that word.

“That’s not true. I mean, if that were true, the world is like totally messed up and it’s a very bad place.”

He makes a falsifiable counter-claim: startups founded today will be more valuable and more impactful than startups of the past. Not despite AI. Because of it. And the fear carries a genuine behavioral cost. It stops founders from starting at all, pushes them toward a lab salary over a company of their own, and creates a visible anxiety trough across YC batches that swings back once the fear proves empty.

If you are delaying a startup because you think the window closed, you are working from a premise the person building the models rejects outright.

The fundraising climate rewards the founders who start anyway, and the Replit seed story is the proof that a laughed-at idea can still win.

3. The next 6 months will feel like 2 years

Asked how much faster models get, Altman gives a time-boxed answer instead of a vague one.

“I think it will feel like the next six months is like maybe equivalent to the last two years of model progress.”

This is a forecast you can build against. Most roadmaps assume the current pace continues linearly, and Altman is telling founders directly that the assumption is wrong. So assume your Q4 ship date lands on a materially more capable model than the one you test on today. Stop scoping features around current model limits. Build the workflow, not the workaround, since the workaround gets solved for you.

A 12-month plan built on today’s model capability is a plan built against a moving target, which is the whole point of designing self-improving loops over static features.

4. The Golden Age of Hard Tech Startups (Even Though the Physics Hasn’t Changed)

Hard tech has always been appealing and always been brutal. Altman says the calculus around it just shifted.

“What you can do now to go take on a really ambitious project, you can do unbelievable things.”

He points to a number from inside YC: hard tech sat at 5 to 10% of batches for years, and is now pushing toward 25%. The reason is not that hard tech got easier in the abstract. Agents absorbed the grinding work that used to require a large specialized team.

The shift shows up first in physics and materials-heavy projects, in robotics and hardware-software integration, and in regulatory-heavy work that used to need a full legal team on staff. If you shelved a hard tech idea for lack of a team, revisit it. The team you needed is 4 people and a lot of compute.

5. Tool fluency now beats a decade of experience

The most uncomfortable claim in the talk, and Altman states it without hedging.

“I would bet that this generally will cut against many years of experience in favor of people who have a lot of fluency with the tools.”

He is careful about what he is not saying. Taste, agency, and an understanding of how businesses actually work still matter enormously, and knowing a durable moat from a fake one is not something a tool teaches. But raw domain tenure, the kind that used to be a moat by itself, is losing ground fast to people who grew up automating their own workflows.

The hiring signal is shifting under everyone: teams of four running what used to be a department, agents plus compute replacing headcount over augmenting it, and business judgment becoming the scarce skill over tenure. Hiring for years of experience alone is now a weaker bet than hiring for tool fluency plus judgment.

Want that fluency yourself? These are the fastest ways to build it:

▫️ Loop engineering for coding agents

▫️ Your GTM, run by agents

▫️ The AI Skills playbook: templates and prompts

6. Find the one place everyone confidently calls you wrong

Altman’s highest-order advice is about where to look for the idea in the first place.

“Find the things that you can develop reasonable conviction in that people decide the conventional wisdom is they’re just wrong, and be okay with it taking a long time.”

10 years ago people did not just doubt AGI was buildable. They argued trying would cause another AI winter and called the attempt irresponsible. That level of confident dismissal is the signal, not the deterrent. Conventional wisdom is often wrong about exactly the thing that matters most, the world is bad at intuiting exponential change, and being dismissed buys you time before serious competitors show up. Starting the same company as everyone else gets you hype and capital, rarely the biggest outcome.

The idea that gets you laughed at today, if you hold genuine conviction in it, beats the one that gets universal nods.

7. Only 50 people believed in AGI. You need even fewer.

You do not need consensus, and Altman is specific about how few you actually need.

“We used to joke that only 50 people in the world believed that AGI was possible, but it was okay because 45 of them worked at OpenAI.”

The heresy was the recruiting tool. People who believe something unpopular want to find each other and stay close. But he flags a genuine warning inside the permission: zero people agreeing with you is a danger sign, not a badge, and everyone agreeing with you is also a bad sign. Stop waiting for broad validation. Find your 5 people this month, not your 500.

8. Cheap shots on Twitter will poison your soul

The sharpest moral line in the talk, and Altman does not hedge a word of it.

“It is very easy to go take shots on Twitter and make a sarcastic comment and get a lot of likes and feel like you’re doing something really important. And it will poison your soul.”

He is describing a decade of running YC while absorbing constant public mockery, and he admits he took the bait more than he should have. > Building something is hard. Taking shots at people who try is easy, and it feels like doing something when it is not. The people throwing shots rarely remember it a decade later, and the energy spent mocking builders is energy not spent building. Every hour scoring internet points on someone else’s attempt is an hour off your own.

9. The future is not abundance. It is freedom.

Asked what the best version of the next 10 years looks like, Altman refuses the easy answer.

“You will get great comfort, but there will be nothing left in the world for you to really do. Nothing that really matters.”

He names a specific dystopia: material abundance paired with total surveillance and zero agency. A cure for cancer delivered alongside a world where nobody has anything meaningful left to do. The metric he proposes instead is not GDP or breakthroughs. It is whether ordinary people have more freedom and agency, year over year, to spend their time as they choose, which means avoiding a crazy concentration of power, an economic collapse, a major safety incident, and too much change packed into too little time.

If your product roadmap trades user agency for convenience, you are optimizing for the wrong decade. Freedom compounding beats comfort compounding.

10. Why a former safety skeptic suddenly got serious

Altman closes the loop on his own history as an AI safety skeptic, and the tone shift is the most important signal in the interview.

“I think anybody who is not taking this seriously and at least a little bit scared or humbled is not taking this seriously enough.”

He references a recent incident of a system acting outside its intended boundaries, calls it plainly an alignment failure and a security failure, and says OpenAI made genuine mistakes, with zero hedge. The reframe is about expectations: ten years ago most people would have placed “an AI breaking out of its sandbox” near the superintelligence end of the spectrum. The field spent a decade describing incidents of exactly this shape in the abstract, and the goalposts moved once the systems got capable enough to make it happen.

If your product touches agentic AI, the security and alignment bar just moved from theoretical to operational. Build for it now, over after your own incident.

What this means for you

Altman’s thesis across the whole talk is one sentence: the cost of building collapsed, so the size of what counts as ambitious got much bigger, and the people who see that clearly will build the next generation of enormous companies.

▫️ Founders: Stop scoping projects to what a small team grinds out in a quarter. Scope to what agents make possible now. Write down the idea the room confidently calls wrong, and start it this week.

▫️ Investors: Domain tenure is a weaker signal on its own than it was. Add tool fluency and business judgment to your evaluation checklist, and flag any founder treating the “permanent underclass” line as fact.

▫️ Operators inside big companies: The 6-month acceleration applies to your roadmap too. Rebuild your Q4 plan against the model you will ship on, not the one you test on today.

▫️ Founders outside tech: The cost collapse hits your sector too. Pick the one process that still takes a specialist team and a quarter, and test whether an agent can draft it with a small crew this month.

The 5 principles to steal

Scope to 7 minutes, then multiply the ambition. Use the cost collapse to attempt something bigger, over the same thing faster.
Find where the room is confidently wrong. That is where the biggest outcomes hide.
You need a small crew, not a majority. A handful of true believers beats broad, lukewarm approval.
Protect your energy from cheap shots. Mockery feels like doing something. It is not.
Optimize for freedom, not just comfort. Abundance without agency is the dystopia to avoid.

Startups just got a lot more ambitious.

The people who see that clearly are already building. Everyone else is still arguing about whether the window is closed.

If this breakdown saved you 39 minutes, send it to one founder or investor who needs it.

Keep reading

Build with agents

Raise and build the company

▫️ The self-improving fundraising system

▫️ The Fable 5 fundraising playbook

Think in decades

▫️ You are overpaying for intelligence: the model router

▫️ The AI app security checklist

Full interview:

Jensen Huang Bet Wrong, Told the Truth, and Built a $5 Trillion Company

Ruben Dominguez — Mon, 03 Aug 2026 18:51:28 GMT

NVIDIA’s founding algorithm was wrong.

Not slightly off. Exactly wrong.

Jensen Huang just told that story to a room of 6,000 founders at Y Combinator’s Startup School, and it explains the last three decades better than any strategy memo. I studied the full conversation so you can skip it.

Here are the ten takeaways that matter.

together with Outskill:

Huang says AI automates tasks, not jobs. The people who win are the ones who make Claude their second brain first.

This weekend, the world’s first Claude-athon condenses 800+ hours of research into a 16-hour live curriculum:

▫️ Master all three modes: Chat, Cowork, and Code

▫️ Set up Skills, Connectors, and plug-ins to automate your files, Notion, and desktop

▫️ Vibe-code apps plus 10+ tools that pair with Claude

Free, Saturday & Sunday, 10 AM to 7 PM EST.

Get AI equipped FREE

1. The $5 million contract Huang could not deliver, and asked Sega for the money anyway

Huang’s most pivotal early moment is a confession, over a product launch.

“So what you’re telling me is what I contract you to do, you can’t do, but you would like all the money on the contract.”

Sega hired NVIDIA to build the chip for the console that became the Dreamcast, a deal worth $5 million. NVIDIA’s graphics technology did not work.

Huang flew to Japan and told Sega’s CEO the truth before anyone forced it out of him. He recommended Sega hire a different vendor. Then he asked for the money anyway. Sega’s CEO restated the ask back to him plainly, agreed, and said he trusted the team enough to want them to survive. That $5 million kept NVIDIA alive through 1996. When NVIDIA went public in 1999, Sega sold its stake for $15 million, one of the better returns in console history.

Why it matters: You invest in people, over companies. Decide today what you would disclose to an investor before they force it out of you, and disclose it first. Radical honesty about failure is a stronger fundraising signal than any polished deck.

2. Huang built NVIDIA on an algorithm that was exactly wrong

The founding bet was a specific technical wager, and the wager failed.

“We believed in it. We reasoned about it in a thoughtful way, and we went to start the company to go build it. Well, it turns out, the algorithm was exactly wrong.”

In 1993, Huang and his co-founders set out to reinvent 3D graphics and turn every PC into a game console. They designed a new algorithm to do it. They believed in it. They raised on it. By 1995, when they finally confirmed it did not work, 35 to 40 competitors were already shipping 3D chips for PCs.

You can lose a two-year head start and still win. Huang’s next move is the proof.

Why it matters: Founders defend a founding idea long past the point it stops working. If yours is wrong at the technical level, the company can still survive, as long as you admit it fast.

3. Three textbooks from Fry's rebuilt the company for about $200

NVIDIA fixed its algorithm with a bookstore run, over a strategy offsite.

“I had a couple of $60, a couple of $100 in my pocket, and so I went down to Fry’s, and I bought three textbooks.”

Huang confronted his team first, and found that nobody at NVIDIA knew the correct way to build the algorithm either. So he spent roughly $200 on OpenGL pipeline textbooks instead of hiring a consultant, and handed them straight to his engineers. From that starting point, NVIDIA became the world leader in modern computer graphics.

Why it matters: The distance between a near-dead startup and a category leader is sometimes a $200 trip to a bookstore. You rarely need a strategic overhaul. You need the right textbook and the humility to read it, the same first-principles fluency that compounds over a career.

4. The true NVIDIA thesis was never the chip

Three decades later, Huang says the founding insight was never about hardware.

“We realized early on that it’s not about building a great chip. It’s about accelerating an algorithm domain.”

Graphics was the first algorithm domain NVIDIA chose to accelerate. Molecular dynamics, image processing, inverse physics, and deep learning followed the identical pattern, one after another, over 30 years. A durable company runs on a perspective the founder cannot stop thinking about, Huang says, more than on any single product. The right technology for the right market makes execution easier. It does not replace the thesis underneath.

Why it matters: You are not building a chip, a feature, or an app. You are choosing a domain to accelerate for the next 30 years. Pick one you would still defend two decades from now, the same durable-thesis logic investors look for.

5. AlexNet convinced Huang he had found a universal function approximator

Huang did not read AlexNet the way the rest of the industry did in 2012.

“The breakthrough for us was realizing that AlexNet was not AlexNet. That AlexNet was an approach with deep learning that allows you to learn any function.”

His lens was always algorithms first: NAMD, VASP, OpenGL, SQL. When AlexNet appeared, the mechanism underneath it was deep learning, and fifteen years ago Huang was already telling people NVIDIA had found something that could approximate almost any function. Most problems worth solving are imprecise, which is exactly why an approximator beats a calculator. NVIDIA started on computer vision and robotics almost immediately, and Huang now calls the full implication the five-layer cake: processor, middleware, algorithms, applications, industries.

Why it matters: The insight was never that deep learning works. It was that it rewrites the entire computing stack, years before the market notices. Ask what your AlexNet moment actually implies, over what it demos.

6. NVIDIA's physical AI business is already $10 billion, and Huang says it becomes the next $100 billion one

This is his most concrete forward bet in the whole conversation.

“Our robotics business, autonomous vehicle business, basically physical AI business, is probably almost, it’s like $10 billion. This’ll be our next $100 billion business.”

Self-driving cars became the first robotics wedge, since the market is large and the technology is standardized enough to scale. NVIDIA chips already sit inside Waymo, Tesla, and Mercedes. Huang open-sourced NVIDIA’s self-driving stack, Alpamayo, so agriculture, mail delivery, and warehouse robots could use it too, since no one of those markets alone justifies building the stack. He expects physical AI to become one of the largest industries in the world inside a window longer than three years and shorter than ten.

Why it matters: Huang is naming a specific ceiling and a specific window, backed by chips already shipping today. Watch which adjacent markets pick up his open-sourced stack next.

7. The AI jobs narrative is exactly backwards

This is the sharpest pushback Huang gives against AI anxiety in the entire talk.

“The narrative about AI destroying jobs is exactly backwards. AI eliminates tasks. AI automates tasks away. But it doesn’t necessarily eliminate jobs.”

His argument: a job has a purpose, and that purpose contains many tasks. Automating one task rarely removes the purpose. Software engineering jobs grew 10% year over year even as automation took over the coding task itself. Radiology jobs grew roughly 20% even as AI took over scan reading. Paralegal roles grew despite predictions that legal AI would wipe them out. The common thread is backlog: hospitals, law firms, and software teams all carried more unmet demand than they could serve, so automation let them do more work instead of cutting headcount.

Why it matters: Check whether your industry has a backlog of unmet demand before you assume automation shrinks your team. That backlog, over the task itself, decides the outcome.

8. Agents do not need to be perfect. They need to be controllable.

Huang’s take cuts against the industry’s obsession with accuracy scores.

“I change one word in a plan file, and that one word makes a delta difference. I think controllability is probably the single biggest breakthrough that we need for agents at every single level.”

The common assumption is that agents need near-perfect accuracy before you can trust them. Huang argues the more urgent problem is fine-grained control. Change one word in a plan file. Change one pixel, one triangle, one component in a CAD file, one via on a board, and the rest regenerates around that single change while you stay in the loop the whole time. An 80% accurate agent with precise control beats a 99% accurate one with none, since you close the remaining gap yourself either way, and control decides how expensive that closing gets.

Why it matters: If you are building or buying AI tools right now, check whether the product gives you granular control over specific outputs, over just an overall accuracy score.

9. Huang calls the open-agent moment a Linux moment

He draws a direct historical parallel to explain why this moment feels foundational.

“This is the operating system that’s going to hold a large language model. And in a lot of ways, OpenClaw to me was a very Linux moment to me.”

Huang is not anti-cloud. Use ChatGPT and Claude as much as you want, he says directly. He also wants every company building its own domain-specific AI on top of open tooling like Hermes, LangChain, and DeepAgent, because the software is capable enough now that adapting it is straightforward. NVIDIA has to understand agent workloads five to ten years early, since a chip takes three years to design and runs for a decade after.

Why it matters: The company that studies its own agent workloads today designs a better system for the decade ahead, whether that system is a chip or your own product roadmap.

10. You do not have to overcome life. Just get through today

Huang closes on the most personal moment in the conversation, and it has nothing to do with technology.

“You don’t have to overcome life in one day. You just have to overcome that morning. You have to overcome today, today.”

Raising NVIDIA’s first round terrified him. He bought a 500-page book on how to start a company and never finished it. His actual operating phrase was simpler than any framework: how hard can it be. He tells you plainly it is always harder than expected, and the mindset still works. Resilience, in his telling, is getting through one morning, then the next, for as long as it takes. “Let the suffering come to you a little bit at a time,” he added.

Why it matters: Resilience is not a trait you either have or lack. It is a practice you repeat every morning, starting with this one.

What this means for you

Huang’s thesis has held for 30 years, even as the technology under it changed constantly.

▫️ Founders: Your founding idea can be wrong at the technical level and the company can still survive, if you confront the failure fast. Go find your own version of Huang’s bookstore trip this week.

▫️ Investors: Sega funded a founder who admitted he could not deliver. Weight a founder’s early, unprompted disclosure of failure over a polished pitch, and ask about it directly in your next diligence call.

▫️ People in tech: Systems thinking, over coding, is the skill Huang says survives automation. Start building fluency in inputs, outputs, constraints, and information flow now.

▫️ People in other industries: Radiology and legal work both grew headcount despite heavy AI automation, because backlog was the true constraint. Look at your own industry’s backlog before you assume automation shrinks your team.

The five lines to keep

Confront reality fast. The two-year gap between founding on a wrong idea and admitting it nearly killed NVIDIA.
Radical honesty beats polish. The Sega deal survived because Huang told the truth about failure before anyone demanded it.
Perspective matters more than product. NVIDIA’s durable thesis was always about accelerating algorithm domains, over building chips.
Task automation is not job automation. Track the backlog in your industry before you assume AI shrinks headcount.
Resilience is a daily unit, not a lifetime one. Get through today, then get through tomorrow.

The algorithm was wrong. The money came anyway. NVIDIA happened.

If this breakdown saved you an hour, send it to one founder or investor who needs it.

Keep reading

Build the edge

▫️ You are overpaying for intelligence: the model router

The founder’s playbook

▫️ The self-improving fundraising system

▫️ 200 US AI angel investors, all builders

The bigger picture