With a year of my own setup behind me, I’d spent days losing at something a brand-new agent got right in a few hours. It asked my permission along the way. I still don’t really know how it keeps the promises it made.

I wanted to do a better job at keeping up with conversations on X, so I built a tool to find the most interesting ones to engage with. I’d spent a few sessions on this tool, but I still felt that the “aim” was bad and I was about to give up. So I thought, let me see if Instinct can do better.

Instinct is the agent product that has been all over X this past week, first among investors and AI builders posting what it had done for them, then among the same people finding out what else it had been doing. I’d been trying it for a few hours. I gave it no links and no handles. It correctly found my X account, my Substack and my GitHub repo, all without asking me to confirm which account. Three rounds of feedback later it was picking the tweets I would’ve picked. It was pretty amazing.

It didn’t ask me to install anything, wire anything together, or decide how any of it should work. It just handled it.

A brand-new agent beat a year of my own setup

My tool had everything. It ran on Claude Code with all my context, all my writing, all my standards, and an authenticated session on my own X account. The one that beat it literally knew nothing about me other than my name, my email and maybe three conversations’ worth of context.

The difference between them is the harness, which I’ve called the program that operates it and decides what it sees. In oversimplified terms it’s just a system prompt (instructions the agent is forced to read at startup time) plus allowed tools (what tools the agents can/should use when). How you remix it makes all the difference.

And mine didn’t lose narrowly. It was bad at picking which conversation was worth riding. It was bad at working out the angle that made sense socially. Sometimes it missed what the target post was even about. It was bad at pulling the most relevant thing out of my own writings. In other words, it could not internalize the lessons of my own posts that had worked.

I honestly don’t know why it was so hard. My best guess is that it’s machinery. My tool was trying to figure out what kinds of tweets I’d approved and which I’d rejected, so it used tweets I wrote to try to reverse engineer a bunch of checkboxes. Instinct apparently didn’t need anything from me other than reading what was publicly available, and it didn’t ask me to think through how to design a tool to do the job. It was fascinating to see how Instinct got me 80% there on a few hours of context.

Subscribe now

Every setup step I braced for simply wasn’t there

The very first task I gave to Instinct was simple but annoying (if you’re a parent, you’ll agree). I needed to sign my son up for soccer in the fall, so I asked it to “Look up this soccer program in our town, tell me the schedule, pricing, and how to sign up.” It came back fast with a signup link, the dates and the cost. I asked when and where the practices and games will be. There was no information on the website but the Instinct agent offered to send them an email to ask — I only had to review the draft it wrote in text and it was done.

With a coding agent that request is a project. We need to set up an email service, go figure out Resend, or I need the Gmail MCP etc. Instinct just had an inbox.

Then I gave it a recurring job: check for conversations worth replying to on X, daily. It said okay, done, I’ll ping you at 7am. I did not have to set up a Claude routine or wire anything up. And it was fast in a way I had thought didn’t matter. I used to think latency isn’t a big deal because “it’s working in the background while I do other things,” but the snappiness really creates a superb UX.

How I pitched it to my husband: it’s basically OpenClaw plus Claude Code without all the setup and hassle, and very good intuition. (He knows I’m a Claude Code fan girl.) A few hours in I thought, in a day I could be ready to announce “the best AI agent available right now is no longer a coding agent.”

I’d tried working with agents like this from my phone before. OpenClaw in March 2026: the two reasons it didn’t work for the mass market were that the setup cost was way too high (it took me an entire Friday night to configure) and it did not have very strong standards. It would say “oh yes! I’m on it!” Then it wasn’t on it (yes it would lie!). Claude Code was the opposite bet and it has obviously paid dividends, which is why I have confidence in my mech after a year of learning-loop and mistake-correction.

So I had this wrong. I thought a complicated-but-worth-it onramp was necessary, the Claude Code kind, and it isn’t. You literally don’t need to know anything about agents. You just make it do things and it’s good. That’s the impressive part. Being a “wrapper” is not that easy, and we were just lacking imagination until someone showed us how much better and easier it could be. How fast it becomes useful is the factory setting; whether it’s ever really yours is whatever you add on top. I think there’ll always be a benefit to teaching it to know you better. Personalization always has value because we are all unique.

The best harness I’ve used didn’t move the permission boundary an inch

Nothing I asked for on day one needed a credential. But the moment it needs something that isn’t public, the setup comes back one login at a time, at the moment you want the task finished. The onramp moved to the other side of the login.

I pushed the Instinct agent to describe its trust and context boundary, and unfortunately we are still stuck with the same leash length and context gate tradeoff I wrote about months ago.

Leash length and the context gate are two different problems, and they compound. Leash length is the ceiling, because the more permission you give it the more useful it is, so the leash caps how useful your agent can be regardless of how awesome the harness is. The context gate is the other end. Once an agent has external write access (e.g. it controls a browser logged in to your X/LinkedIn account, or has the ability to send emails from your email account) and it knows something about you that is meant to be private, there really is no way to maintain a context gate without gating tool use. You can review the relay of context all you like, but every check is going to be model-based and probabilistic. There’s no fixed rule that catches it. The agent doesn’t even need write access to be a target, because anything it reads can carry instructions, and the send access it already has does the rest (this is prompt injection). So either you accept checks that will sometimes be wrong, or you keep the permissions narrow, take the trust-utility tradeoff, which means these agents can't be that useful.

I know how it could go wrong. The agent can say stuff you don’t want said, as you, if it has your X or your Gmail. Maybe that’s the lost battle, like privacy. It’s a tradeoff most consumers will make without realizing they’re making one, until something embarrassing (or catastrophic) happens.

Competence can be mistaken for trustworthiness

Instinct’s terms, last revised on August 20, 2026, put the deal in legal language:

“You hereby appoint the Services as your agent to enter into agreements, commitments or transactions on your behalf... binding on you as if entered into directly by you.”

And: “We are not responsible for any unintended Actions...”

A smooth onramp is how blanket permission feels from the inside.

I asked Instinct directly what logging in to X would mean, and it didn’t soften the answer: “it’s a browser I drive that holds your X session, which technically means it could post as you.” It wouldn’t call a live session zero-risk either. Then I asked how connecting GitHub worked, and it said the consent screen would let me scope the grant to specific repos. I clicked on the link, and the screen says by clicking yes, I would grant it access ALL repos, read AND write (good that I read what’s actually on the screen). When I told it so, it dropped the claim at once, “trust what the screen says over what I said,” and wrote itself a rule not to describe an integration’s permissions it hadn’t seen.

I didn’t like what I saw, so I didn’t connect GitHub, and I never gave it the authenticated browser access.

Other people had worse days with it than I did. It does ask for permission, at a moment in time, and supposedly it tells you what it promises to do or not do. But you don’t really know the HOW, or how it can keep that promise. A kept promise and a broken one would look identical to the user. The Instinct agent was candid and precise with me, and still wrong about what it was asking for. I caught it because I knew to ask. Most people wouldn’t know what to ask, because they don’t know the machinery, and not having to know is the whole point of the product.

I trust the direction they walked, not where they landed

I trust Claude Code and Instinct differently, and I think it comes down to two things, transparency and direction. By definition, walking in from the side that exposes the machinery starts you with transparency, at the expense of ease of use and the onramp. Walking in from the other side doesn’t, because it starts by masking the complexity.

I’m more comfortable with Claude Code because I can see the machinery bare, every tool call and the turn-by-turn thinking out loud, which is obviously overwhelming for most mass market users. But that isn’t the only reason why I trust it. I started a year ago at the other end, where it stopped for everything and made me approve each edit and each command. It never explained why any of it was risky. It just stopped, over and over, on some things and not others, and that taught me what this kind of tool can do to you. The friction turned out to be tuition I unintentionally paid.

Then they walked. Auto mode arrived in March as a research preview and became the default two weeks ago, with a classifier reviewing each action instead of relying on the user to judge. They moved because the asking had stopped working, and it was creating a false sense of security: Anthropic’s research showed that users approve almost every prompt, and that the longer a session runs the less they catch, while the classifier doesn’t get tired.1

So both products end up in nearly the same place, and it isn’t the destination that makes me trust them differently. It’s the direction. One started strict and earned its way down. The other started at the far end, built the habit first, and is filling the gaps under public pressure.

I’m still using Instinct, and I’m a bit less cowboy-ish now about permissions and connecting it to my stuff. You’re making tradeoffs either way, so better walk in with eyes wide open.

But I don’t think the answer is just “be more careful.” We were lacking imagination about the onramp until a product showed us how easy it could be. I’m waiting for the next one to break our imagination again and show us how to walk the line without giving up either the ease or the trust.

We’re building a machine to help evaluate companies, and the only fast way to check it is whether it agrees with us. The real answer takes a decade. Tune for agreement and you lose the exceptions the machine was supposed to catch.

A few weeks ago one of my partners asked me what he was actually supposed to write down.

We are working on a machine to help us evaluate companies, and designing the record that will let us tune it. Tuning means comparing what the machine recommends against something we trust more, and the obvious candidate is us. Hence the question.

I didn’t have a clean answer. The best I had was two questions. Do I like this company, and would I have invested? A verdict on its own is thin. The thinking underneath it would make the verdict useful, and the thinking is the hardest part to get onto a page. Even if we could write it down perfectly, it still wouldn’t tell us whether we were right. In our business, it would take a decade if not longer to really know.

Subscribe now

We need a sixth voter that disagrees with us

We already run an agent at NextView that systematically surfaces and evaluates prospects outside our existing network. It answers which company a partner should pay attention to. You can argue that’s analyst-level work, and competent analysts mostly agree with each other. The criteria are largely stateable, and give two good screeners the same hundred companies and their lists mostly overlap. Where competent people converge, one person’s taste is a legitimate standard, and tuning that agent to mine is the design.

Partner work has the opposite property. Six years ago I wrote that NextView runs a conviction-based process, where consensus isn’t required and one partner’s conviction can drive the decision. A partner meeting produces one of three outcomes. There is enthusiasm across the board, or interests without enthusiasm, or somebody hates the deal and still tells the person with conviction “I support you.”

The middle one is most common, and we call it a doable deal. Everybody likes it, nobody loves it, nothing spikes. Across fifteen years of our own portfolio, that is the shape we have learned to distrust. The investments that actually worked sit at the ends, where either the whole room loved it or one or two people had real conviction while everyone else ran from lukewarm to negative.

The mechanism is deliberately anti-consensus, because consensus filters out what you’re looking for. The cost is easy to miss, because it falls on things that never happen. Anything nobody in the room has taste for never comes up, and we mostly don’t find out it was there.

We want the machine as a sixth voter so it can champion something none of us would have championed. Tuning it toward our judgment takes exactly that away, and a sixth vote that always matches the other five adds nothing to a room that only needs one yes.

Somebody still has to carry the deal. Today the agent shows its reasoning, and sometimes that is enough to provide the onramp for a partner to develop conviction of their own. Whether that holds for the harder question, we don’t quite know yet.

Outcomes can’t settle that question in any useful window either. The nearest early signal is a follow-on round at 18 to 24 months, a smoke alarm rather than a verdict. And our record only covers the companies we ended up investing in, so the passes leave little to grade.

In What I Didn’t See Coming I described testing an early version of that agent, which agreed with my hand-scoring on one company out of five. I read that as the approach failing. On the question we’re working on now, I’d have had no way to tell whether it was broken or onto something I couldn’t see.

Agreement only proves consistency

Grading against yourself only measures consistency. The largest study of AI systems scoring other AI systems found that judging them on agreement overstates how good they look, because chance agreement counts as skill.1

The standard defense is to hold back known winners and test against those. However, you cannot set aside the known winners when nobody knows yet which ones they are.

Nor can we grade the machine against deals we already know worked. A backtest grades the firm we were ten years ago, not the partnership deciding now.

Tune for agreement and the outlier detector disappears

The objection a venture investor raises is that codifying judgment just scales your own blind spots. That objection is right. It is also not an argument against encoding taste, since our collective experience is how the machine beats a random person doing the same job. The problem is the number you tune on afterward.

Venture returns are a power law. One breakout returns the entire fund, and missing it costs more than backing ten that go nowhere. So the machine needs an outlier flag for the founder who is extraordinary at two things and unremarkable at four. An averaging system files that founder as mediocre.

Rare things are rare, so most of what the flag catches is a false positive, and it drags the agreement number down even though each correct catch is the whole reason we built it. Whoever tunes the machine cannot tell a correct outlier flag from a bug. That is consensus by construction. Nobody chose the bias; the fastest measurement available creates it.

Keep tuning and the flag goes quiet while the agreement number climbs. You’d conclude the machine was getting better, and have built a very reliable instrument for finding the companies you were always going to find anyway.

We already do a version of the fix with the agent we run today, where I deliberately don’t tighten its instructions to maximize agreement, because the slack lets oddly-shaped companies through. The machine needs two things. Give the outlier flag its own path, so a spike escalates to a human whatever the total says. And put how often the flag fires next to how often the machine agrees, so when one number improves because the other was squeezed, somebody sees it happen.

Start the record you can’t read for a decade

In The Judgment Layer I argued that the self-improving loop stops when the feedback can’t close in time. That frame didn’t cover what happens when you chase the non-consensus work anyway. The only fast check available is whether the machine agrees with us, and agreement is consensus, so the check turns the work back into the thing we were escaping.

The record has to hold what was known at the moment of the call, what the machine said, what the partnership decided, and the companies we passed on. Most funds don’t keep that last part in a gradeable form, since what my partner David calls “a war story told at dinner” in The Copy Problem is not a dataset. Freeze all of it and real outcomes will eventually grade the machine, the partnership, and the final call against each other. The reasoning captured can also tell you whether a good call was judgment or luck.

The real question isn’t whether the model is good enough

This dynamic applies anywhere the rare exception carries the value and verdicts come slowly. Can a model do this type of work at all? The question is unanswerable as asked. Nobody can tell for a decade, so a better model and a worse one look identical on every instrument we have.

I’m not exempt from that. In The Structural Divide I published a correction rate under 10% as evidence the agent we implemented worked. For the question it answered, which companies were worth a partner’s attention, that was fair. It is also the most natural number to carry into the harder question, and the mistake I am closest to making.

The bar was never agreement with us. It’s partner-caliber judgment at a volume we can’t staff, and we can’t verify that for a person at hiring time either. We read how someone reasons, weigh what they did before, and hand over the seat knowing the answer is a decade out. A model has no history elsewhere, so its reasoning must carry more. Read the reasoning now, and let the record grade it later. Agreement is not part of that test.

The models keep improving and using them gets cheaper for everyone. Yours is the judgment you encode and the record that grades it. Whatever is wrong in it arrives at scale, so the worst outcome isn’t sitting this out. It’s scaling it with a dashboard that says it works.

Previously in Ground Truth: The Consensus Machine (why value migrates to non-consensus work as automation advances).

My partner David writes about this from the other direction at Carried Away. The Copy Problem argues a codified screen can be inspected, measured against outcomes, and improved in place, and leaves open whether it captures enough of the real thing. This is a first pass at the measurement half.

A year ago I opened a coding agent for the first time, with no real idea what it was for. It is now the thing I work inside. None of the changes along the way felt like much at the time.

On a Friday in early August last year, I decided to give coding agents a try. I installed Claude Code and spent two hours building a website that generated satirical venture-capital wisdom from NextView’s own blog posts. Then I left for a neighbor’s backyard party, excited to show what I’d made. I had vibe coded a site, and I abandoned it days later.

Every no needs an expiry date

The site needed the model to read a few hundred blog posts and make sense of them, and it couldn’t do a good job with it. It fetched pages unreliably, read the first few sentences and confidently described the rest wrong, and could only hold so much context at once. Getting from there to anything I would publish was far more work than I wanted to put in, so I stopped. The whole record of it is two saved snapshots of an afternoon’s work.

Stopping was the right call in August 2025, and what made it right was the model’s limits relative to the merit of the idea. A no built on what a model can’t do well yet (at least not without a ton of work) has a short shelf life, because capability is the thing that moves fastest. Fetching and reading a few hundred pages is unremarkable now, and I never noticed the day it stopped being hard.

Subscribe now

A model is not a reliable witness about itself

By mid-September, six weeks into working with a coding agent, I was prototyping an AI-assisted deal evaluation system at NextView, and my session log for that week calls for “Audit Trail: Complete traceability for fiduciary responsibility.” The next task in the same document is to plan how to set up version control. Between the agent and me, we were specifying bank-grade requirements on top of a plan to learn how to save my own work.

I had no way to judge whether any of that was the right size for what I was doing, and that is how the next thing got past me. A log entry from the same stretch reads “upgrade to Claude 3.5 Haiku for better analysis,” checked off as done. I was fairly sure Haiku was the small fast one, but the agent gave me a reason that I took without questioning it. I figured it would know its own capabilities better than I would. The Confidence Gap, which I wrote a few months later, is about exactly this: the gap is widest where you can’t verify and don’t know it.

Then we ran a test on the prototype: on the five companies I then scored by hand, the prototype and I agreed on only one. It was a deflating moment: I interpreted the result to be that the approach I took didn’t work. What I only realized later was that we had put the wrong model behind it.

The code gets replaced, the judgment stays

From September to November I was working out where the limit was: how far could someone with a product background get with a coding agent, and what would it take to build the version of the deal evaluation system we would actually use?

In early December one of the candidates for a contract engineering role took my code, changed the model, and ran it against a sample of ten companies. I scored the same ten myself, and we matched on all ten. On the weaker model my own version had matched me on one out of five. That afternoon I wrote to my partners: “very small sample, very encouraging”, and I didn’t want to get too excited. I had not touched the project in three weeks because I wasn’t sure if I had built anything useful.

He started working with us, and by his fourth day he had deleted 95 files and 37,327 lines, all of them mine. He was right to: he was turning a prototype into something that could run every day.

What he kept was not the code (my own lines are under half a percent of what runs today). What survived is how the evaluation should work and what to look for in a founder, carried as plain English in the instructions the system reads before it scores anything.

Knowing where to look is the skill that transfers

In February I was doing a code review on a colleague’s project. Every time it ran, its setup step was taking a real password out of secure storage and pasting it into one of the code files. Of course we quickly patched it and thankfully no damage was done.

This is not a story about catching a mistake someone made. She was newer to all of this than I was, and a year earlier I would have made the same mistakes myself. If someone had described the problem to me in plain language I would have known it was wrong, but I would not have known how to spot it.

I am still miles away from what a trained engineer can do when it comes to writing code. What I picked up instead was a sense of where things tend to go wrong, which is most of what you need once an agent is writing for you.

Rules built from your own mistakes buy more than time

The first five months of working with a coding agent, I would read the raw back-and-forth of every session, making sure I could follow along on its decisions and watching for the moment it went wrong. It worked but the process could be exhausting: catching one mistake sent me checking everything else the agent had touched. The Verification Tax is where I worked out why that doesn’t scale: I cannot 5x my output while 5x my review time.

So I built something1 that helps me write the rules for agents. After each session a wrap-up lists what went wrong, I argue with it about the fix, and the rule comes out of that argument. Most rules land in the file the agent reads at the start of every session. The ones it keeps breaking become code that blocks the action outright and doesn’t ask the model’s opinion, which is what Wrapping the Unpredictable Genius is about.

By early summer I was running five or six sessions at once and reading only the summaries. My own records show what that did. Before March I was working through an agent a handful of days a month; from March on it was closer to 25 out of 30 days a month, across almost everything I was doing at work and home.

The real gain was ambition. Once verifying stopped hurting I stopped sizing every idea against the review it would cost me, so I handed over more, and more kinds of things than I would have considered a year ago.

Your setup is the leverage, and it doesn’t travel

Since the spring the limit has been my own hours at a screen, and I am already maxing out on those (my kids will tell you I “work with AI” a lot during weekends). So I stopped trying to be at the machine more and started making the machine more reachable.

I can work through a queue of planned projects from my phone on the go, deciding which are worth doing and tightening the ones that are. The Autonomous Middle made the case for pulling the judgment out of the work in the first place. What I would add is that once it is pulled out, it can be cut into pieces small enough to reach you anywhere.

There is a phone version of the coding agent that runs in Anthropic’s cloud environment, and I don’t use it often, because the cloud machine doesn’t have what I have accumulated: the rulebook, the reference documents, the custom skills. Without those it’s a competent stranger. So there is a second machine at home now, synced to everything I work on and always on. What I own is a year of configuration that runs in exactly one place, and the work of this spring was making that place reachable.

My workarounds go bad when the model gets better

I started writing this post last week, the same week Opus 5 shipped. Within a few days I found that a piece of scaffolding I had built to work around the old model’s weakness had stopped being necessary and started getting in the way, because the new one does that part itself. It had been the right thing to build, in the same way that shelving the satirical site a year earlier had been the right call. Both were right because of a limit in the model, and neither one told me when the limit lifted.

The fix will cost a few hours, and then that piece of scaffolding will be doing its job again against Opus 5 until the next model retires it too. The cycle is five months of advantage, a few hours of tuning, then five more. That is what I was betting on in In the Meantime. Not building any of it would have left me on the floor, waiting for a right moment to start that doesn’t come.

I don’t know what the second year looks like. The only thing I would bet on is that the list will be about as long.

Previously in Ground Truth: Why Your 50th AI Session Isn’t Better Than Your 5th (making sessions build on each other instead of starting over) · The Structural Divide (why organizational context, not capability, is the bottleneck) · Show Me Your Mech (what to ask for when you’re hiring now).

How much of your work an AI agent can run on its own has surprisingly little to do with how capable the model is. It comes down to a skill almost none of us have been trained for, and the people who build it can get far more out of the same agents than most. What that skill is, and why the iterative knowledge work that supposedly can’t be handed off is exactly where it pays off.

You can hand a coding agent a well-specified task, walk away, and come back to working software. Try the same thing with a strategy memo or a market analysis and you’re back in five minutes, untangling what it got wrong. Ethan Mollick named the reason a few weeks ago: coding agents are “software-brained,” and most knowledge work isn’t. The end product of code is the source of truth, so the loop closes fast. For research, analysis, and strategy, the process matters as much as the output, and you work in learning loops, refining as you go. The feedback signal for “correct” doesn’t arrive fast enough to just hand off.

He’s right about the disconnect, but when I replied to him I realized I’d already been working on the answer. Most of the leverage comes from separating the work: you isolate the parts that are genuinely repeatable and let those run, and you pull the judgment-heavy decisions out to decide up front.

I’ve asked a version of the question before, in The Leash Length Problem (how long can you let an agent run before you step in), but that was about trust and permission, what the agent is allowed to do. This is the other half: how much of the work is even hand-off-able in the first place.

Judgment is the bread, the agent runs the filling

The clearest version of the shape comes from Kieran Klaassen at Every, who built a whole practice around it: compound engineering, the idea that each cycle of work should make the next one easier. Kieran pushes it about as far as it goes: stay in the loop and ask questions at the top, trust the agent to run the work phase, come back to elevate what’s nearly finished. In a recent podcast interview, it got a name: the AI sandwich. Your judgment goes on the top and the bottom, and the agent runs the middle. (I’d been pushing toward it from the other direction, trying to run more agents at once, when I came across it and recognized it.) He argues the pattern reaches well past engineering, into knowledge work broadly, and my own work says the same. What the pattern leaves open is how wide that middle gets.

The sandwich maps onto the decomposition I wrote about in The Judgment Layer. Most work is a bundle: a set of verifiable parts where “correct” is quick to check, plus a thinner layer of irreducible judgment where there’s no fast way to know if you got it right. The hard skill is unbundling the two correctly. The judgment is the bread, the part that stays human. The filling is execution and verification, the work where “correct” is checkable fast enough that the agent can stay on track without you in the loop. Widening the middle means pushing all the judgment out to the two ends, so the filling is nothing but work the agent can run on its own.

None of this makes the directing-and-reviewing work disappear. That’s the verification tax I’ve written about: as your output scales, review becomes the thing that limits you. The sandwich doesn’t pay that tax down; it relocates it, out of the middle where it stalls you turn by turn, to the edges where it doesn’t.

Subscribe now

How wide the middle gets is a skill you build

So how much of the middle can actually run on its own? The width is set by how well you can do three things:

1. You isolate the consequential judgment calls and decide them up front.

2. You get the model to catch the foreseeable problems before they reach you, by running the plan through a set of predefined lenses, fixed checks for the ways this kind of work usually goes wrong.

3. And you accept that some judgment, maybe the last ten or twenty percent, can’t be foreseen, so you let it surface at the review on the way out.

The lenses don’t start out sharp: you learn where the work goes wrong by watching what comes out the other end, then fold each lesson back into the upfront review so the next run catches it before it reaches you. Front-load, run, review, harden, and the middle gets a little wider each time, because each correction is what sharpens the next check.

I went looking for evidence of where my own time actually goes. Over a month, I went back through fifteen of my own work sessions and sorted every one of my interventions into three buckets: the irreducible judgment (taste, positioning, the lived facts only I have), the mechanical overhead (screenshots, copy-paste, link-wrangling), and correcting the agent’s mistakes. The corrections were the largest bucket by a wide margin. A review step would wave through writing I’d have caught on a casual read; the agent would invent an attribution, or talk itself out of a problem it had already flagged.

For a while I read that as the ceiling: more output just means more to police. But the corrections weren’t random. Each one was a judgment call I hadn’t pulled forward, a decision about what “good” meant here that I’d left for the agent to guess, and it guessed wrong. The correction load was the price of the judgment I’d failed to front-load. The fix is to move that judgment to the edge, or harden it into a standing check, so it stops coming back.

This is the part that doesn’t dissolve as models improve. A better model runs the verifiable middle faster, but it can’t close a loop that doesn’t close in time. Whether a founder is right, whether the timing is there, whether this is even the market worth sizing, none of those has an answer to check against yet. The judgment layer is irreducible by definition. So the limit on autonomy was never really the model. It’s how cleanly you can separate the judgment from the routine.

The system that wrote this post runs on the same skill

This essay was produced by a system that runs on exactly this shape, a stack of small, single-purpose tools I had to wire together by hand. There’s a step at the outline stage where I make every judgment call I can anticipate before anything runs: what the post argues, which stories carry it, what to cut. The one call that never goes near the machine is whether the argument is worth making at all. The first draft of this post got that wrong: it argued something I’d basically already published, and the real work was noticing, not writing. There’s a set of review agents that read each draft cold through fixed lenses, one for accuracy, one for voice, one for whether it actually lands for the reader. The drafting, the reviewing, and the cover all run without me. I come back to a near-finished package, read it, and finish it. And when I correct something, it becomes a new rule the system enforces next time. It’s a learning loop I built to do for writing what compound engineering does for code: a mistake gets caught once, then never again.

Writing essays is knowledge work, not code. The process is iterative, the feedback loop is slow, and it’s exactly the kind of work Mollick says resists this. It runs the middle on its own anyway, because the iterative part, the judgment, has been moved to the edges.

The payoff is running several at once

Once the judgment lives at the edges and the middle holds, you stop being the bottleneck between one agent and the next. You can set several going at once, each running its own middle, and meet each one at the end, which is where the real leverage shows up. This is where the “my agents do work for me at night while I sleep” becomes closer to reality. (I’m now pushing this further, front-loading whole plans so they run start to finish, but that’s a story for when it’s run long enough to report honestly.)

The skill is the bottleneck

The thing that limits your leverage from agents, whether you’re one person or a whole firm, is this skill of breaking work into parts, and most knowledge workers haven’t built it. It asks you to think a little like an engineer: break the work down, say what “done” means, anticipate where it breaks. That’s the muscle Mollick is right that most of us don’t yet have.

Which is where I think the opportunity is. Right now, to get the autonomous middle, you have to author the whole stack yourself, the way I did. And it’s not just essays: the analyst building a model, the strategist writing a recommendation, the researcher chasing down sources all hit the same wall, each wiring their own version by hand. The thing worth building, and worth backing, is the layer that comes pre-built and opinionated: front-loading that already knows what to ask you, the review lenses, and the hardening already wired in, so someone gets the sandwich without assembling it themselves or thinking like an engineer to use it. The skill is the scarce part, which is why the opportunity is to package it.

So whether you’re running more of your own work without babysitting it, or building the product that lets other people do the same, the question was never whether the model is good enough. It’s how much of the judgment you’ve moved to the edges, and whether each correction you make teaches the system or just costs you the same hour again.

Running your work through AI means building on top of something powerful that won’t always do what you tell it. The fix looks like a power-user trick. It’s the same problem the most ambitious AI products are built around, and it points to where the real, durable advantage lives.

For the better part of this year I had a rule written down that my AI agent kept breaking. It lived in a file Claude must read at the start of every Claude Code session, stated plainly: don’t do this particular thing. It read the rule, agreed with the rule, and every so often did the thing anyway. So I moved the rule out of the documentation and into a piece of code that runs on its own and blocks the action the moment the condition is met. The model doesn’t get a say in that code. It just runs, and the thing it forbids stops happening.

In The Verification Tax I named the cost of running most of your work through AI: the time you spend checking the output. You pay that cost down with upstream engineering instead of more downstream review. This post is about the structure that does the engineering. The rule that kept failing until it moved is the whole idea in miniature. Over the year I built the smallest possible control setup around the model, with just me and my tools.

Subscribe now

The control I built is a stack, and only the top layer enforces

Think of it as four layers, from the least control to the most. At the bottom is the model itself (e.g. Claude Opus 4.8, GPT-5.5) . It’s brilliant and it’s unpredictable: ask it the same thing twice and you can get two different answers, and no instruction fully changes that. Above the model runs the harness (e.g. Claude Code, Codex, OpenClaw), the program that operates it and decides what it sees. The harness can steer, but only in broad strokes. Above that sits the documentation (e.g. CLAUDE.md and AGENTS.md): my preferences, the project’s context and rules, the corrections I’ve fed it over months. That’s real influence, but the model still gets a vote. It reads what I wrote, weighs it against everything else, and sometimes goes its own way, which is exactly what mine did. At the top sit hooks. A hook is a piece of code that watches for one specific situation and acts on its own. When the agent reaches for the command I’ve ruled out, the hook blocks it, whether the model agrees or not.

Only the top layer doesn’t negotiate. Anything I can turn into a hook can’t get past it, so there’s less for me to check. The mistakes that used to keep coming back are the ones that simply stopped.

The surface shrinks, but it never closes. Plenty of rules are too judgment-shaped to write as code. “Never run this exact command” is something code can check. “Don’t let the analysis drift into something subtly wrong here” is a judgment, and the only thing that can judge is another model. So those rules send you right back to the unpredictable layer you were trying to get above.1

That’s also why the wrap outlasts every model upgrade. The few systems that can actually prove their output is right all work the same way. They check the answer with code, against a standard a human wrote down ahead of time.2 That works only where you can say exactly what “right” means, and judgment is the thing you can’t. So the wrap is permanent. It covers a gap that never closes, no matter how good the model gets.

What looks like a power-user trick is the whole problem in miniature

Software earned its discipline because code is predictable. You decide what the output should be and test your way to it. AI-native products break that contract: they put a probabilistic engine at the center, one that answers the same prompt differently every time. Hamel Husain put it cleanly: the testing discipline software spent decades building assumes one right answer to test against, which is exactly what you no longer have. That point is well-worn by now. The open question is what replaces it.

A chorus of builders is converging on the same answer: keep the unpredictable engine, but wrap it in deterministic code, code that does the exact same thing every time. Dex Horthy puts it bluntest in his “12-factor agents”: good agents are “comprised of mostly just software.” Anthropic’s guide to building effective agents says the same thing in its own words, telling builders to run the work through “predefined code paths” and “add programmatic checks.”

It’s concrete enough that the tool builders now ship it. In Claude Code you can hold an agent to a condition and choose how it’s checked: back the check with code that passes or fails on its own, which gives you a guarantee, or let a model judge it, which gives you a judgment call.3 My own setup is the smallest version of the same idea: every layer I described is one person’s take on what Horthy means by “mostly software.”

Now scale that up. The architecture doesn’t change, only the cost of a mistake does. On my own, a rule the agent ignores costs me a few minutes, and my hooks catch the ones that matter. Inside a two-hundred-person company running the same agents, no one has private hooks. The rules live in one shared file, so a single ignored instance can show up everywhere that file runs, and the team’s protection is only as good as the loosest rule anyone wrote.

The craft is choosing what to guarantee and what to leave loose

The clearest version of the other half comes from the product side. Every’s guide to agent-native architecture argues that “features aren’t code you write, they’re outcomes you describe, achieved by an agent operating in a loop.” That’s a real shift, and it’s the opposite of my move: lean all the way into the model, let it improvise, and design the product around whatever it produces. But read closely and the guide keeps reaching back toward control anyway. It tells builders to move the hot paths “to code,” and admits some operations “need validation that shouldn’t be left to agent judgment.” Each is one clause, and neither gets developed. That undeveloped corner, the controlled code wrapped around the improvising model, is the half I’ve been living in.

The two camps look like opposites, but they’re describing the same architecture from opposite ends. The product builders lean into the model; the engineers wrap it in control. The real work is in between, and it’s a question of degree: how much of the product do you lock down with code, and where. Lock down too little, and the product improvises somewhere the work needed a guarantee. That’s the failure that ships a confidently wrong answer to a customer. Lock down too much, and you hit the other edge: encode every path in code and you’ve just rebuilt ordinary software, with the model as a slow, expensive way to do what plain code already did.

The whole skill is knowing, point by point through your product, which parts need the model’s judgment and which parts need a guarantee. The OpenAI team calls this “harness engineering.” The part worth naming is doing it in deliberate proportion to the power you’re wrapping.

The wrap is the moat

That proportioning is where the durable advantage hides, because the model itself is the least defensible layer you have. Everyone can rent the same model, and it gets better for everyone at once, on the labs’ schedule, not yours. The wrap is what compounds. The obvious objection is that the wrap is copyable too. But a competitor can read your whole repo and still not have what built it: every judgment you’ve made about what your specific work needs guaranteed and what it can leave loose. Those judgments become the layers the model can’t argue past, and reading the repo won’t hand them over. That accumulated record is the moat.

You can watch this play out in the open. Cursor, the AI coding tool, makes no model of its own. It routes between Claude, GPT, Gemini, and Grok, and treats the model as the rentable commodity it is. Everyone assumed Anthropic’s own Claude Code, with first access to the best model, would end it. It didn’t. Cursor went from about $1B in revenue last November to around $4B by June. Last week SpaceX exercised an option it took in April and agreed to buy the company for $60B, the largest acquisition of a venture-backed startup on record. What Cursor spent years compounding was never a better model. It was the wrap: a codebase index that keeps your whole repository synced and searchable; an autocomplete model trained in-house on which suggestions developers accept or reject, across hundreds of millions of edits a day; and the enterprise plumbing now sitting inside most of the Fortune 500. The model company had the better model and still couldn’t own the editor, the index, or the developer’s muscle memory.

Few have built what Cursor has. Most people running AI through their work haven’t built a single layer of this wrap, and don’t yet know the layer exists. At company scale, it’s the build question that decides which AI-native products hold up under real use and which ones are just a brilliant demo over a model anyone can rent.

If the model you build on became free tomorrow, what would you have left?

Previously in Ground Truth: The Judgment Layer (when the feedback loop can’t close, and what survives when it doesn’t) · The Verification Tax (the cost of checking AI output, and how upstream engineering pays it down).

AI memory’s real failure is a quiet one: an agent hands you the version of something that already changed but you never catch it. Retrieval, the part the field keeps racing to improve, is not where memory actually breaks.

A few weeks ago, an agent I run as a chief of staff told me, with total confidence, that a problem was still open. I knew it wasn’t, because I’d fixed it that morning. An hour later it opened a document to edit and started from a version I’d already revised, as if the revision had never happened. Then, in its end-of-day summary, it listed a decision as still-open that we’d already settled hours earlier. The only reason I caught any of them was that I happened to be the one who’d made the changes.

It hadn’t lost the work. It could find the current state fine; nothing flagged the version in its head as out of date.

If you’ve spent time around any large organization, you’ve met the human version: the colleague who confidently quotes a policy that was rescinded six months ago. The difference is that a person usually hedges (”last I checked”), and the agent doesn’t.

For me, that cost a few minutes, because I was the one watching. The same failure scales with whatever you let the agent do unsupervised, and the whole industry is racing to let it do more.

Everyone is racing to make AI remember more

Almost all the energy in AI memory right now goes into one thing: helping models remember more. Bigger context windows, better search over your history, knowledge graphs that store what the model has learned. One of the clearest public maps I came across was Chrys Bader’s thread from April 2026, “Why long-term memory for LLMs remains unsolved”, which maps how retrieved memory gets crowded out by noise. It’s a good map, and it’s the frame most of the field is working inside.

The failure I hit lives somewhere else. My agent remembered the decision fine, it just remembered the wrong version of it. Finding what it knows is one axis; knowing whether what it finds is still current is another. Call the second one currency.

Subscribe now

What’s actually solved, and what isn’t

Memory does two jobs. The first is finding what you stored, the recall problem, and it’s the part the field has pushed furthest. The best systems surface the right memory around 99% of the time in tests and around 85% in production.1 Those are the strongest numbers anywhere in agent memory, and they still aren’t good enough to call the problem solved: at 85%, the system comes back with the wrong thing (or nothing) about one in every seven tries.

The second job is knowing whether what you found is still current, and here the picture splits depending on how your memory is organized. If you’ve gone to the trouble of storing it as a database where every fact is filed with the date it became true and the date it stopped being true (a rigid, structured setup), the bookkeeping is largely handled.2 Almost nobody runs their memory this way, though. It takes real upfront work, and it only covers the facts that fit neatly into the structure.

For the messy, general memory most people and most products actually use (notes, documents, accumulated text and conversations), knowing what’s current is basically unsolved, and you can watch it in what the vendors ship. The most widely used memory layers have quietly moved toward adding new facts next to the old ones rather than replacing them, and letting search sort out which one wins.3 One vendor’s own June 2026 “State of AI Agent Memory” report admits that a stored fact can go “confidently wrong” when the world changes, and that staleness “is a harder, open problem.” Meanwhile most of the new research filed under “memory” is about helping agents forget low-value details, not about keeping the important ones current.4

Where currency actually breaks

That second job fails in two ways. The first is the one from the top of this piece: a fact has an old value and a new one, and the agent reaches for the old one. The second is keeping a change consistent everywhere it lives.

My own agent once paused a set of background jobs and noted it in one file, but left three others saying they were still running. Later it read its own contradictory notes and flagged the jobs as broken, never realizing it had paused them itself. The information wasn’t missing; it was written down in one place out of four. A May 2026 paper named STALE catalogs exactly these two, a “co-referential” conflict and a “propagated” one. I’d run into both long before they had names.

Why you can’t see it happening

The reason this is easy to miss is the thing I noticed first: the agent is just as confident when it’s stale as when it’s current. A builder on the r/openclaw forum described the mechanism well: old notes “came back with the same confidence as fresh decisions,” and the model “had to somehow figure out which one had authority... not because retrieval failed, but because retrieval was too flat.”

My first instinct was that this was because I was bad at keeping my own files current. Some of it is: cleaning up the files helps, and a structured store closes the structured part. But the harder piece didn’t go away.

In the STALE benchmark, one of the memory systems they tested surfaced the updated fact in about 77% of cases but flagged it as worth acting on in only about 3% of the time. The frontier models fail the same way: one of them caught a stale fact 92% of the time when asked about it directly, but only 30% of the time when a question quietly assumed the old fact still held. The updated information is right there, and it still doesn’t get the weight to override what came before.

I see it in my own setup. The agent keeps an auto-memory file, MEMORY.md, where it writes down on its own what it judges worth remembering. Months ago it filed a rule there and marked it settled; later I replaced that rule, but the old one stayed, and for weeks the agent kept steering by it, never weighting the replacement over the version it had already filed as settled.

It only gets more expensive from here

The reason this has only cost me minutes is that I’m still the one checking it. The dominant direction of AI is to take the person out of the loop and hand agents the consequential work of deciding, executing, and running whole workflows. The pitch you keep hearing is the agent company, where you build your own company brain: a growing store of your decisions, policies, and constraints that your agents read from and act on. Every confidently-stale entry there is a decision made against one you already reversed, and no one catches it.

The most ambitious agentic products run on the same bet. These are digital twins, always-on assistants, agents meant to know you, and their whole promise is an accurate, living model of who you are. One that’s confidently wrong about your job, your relationship, or what you decided last month is broken in the way that makes you stop trusting it. The founders building these treat temporal memory as the first problem to solve, not a feature to add later, because there’s no product underneath it otherwise.

Even the frontier labs are circling it from the outside. Agents are now told to write memories automatically, which helps them remember more and does nothing for knowing what’s still true, so the notes pile up faster than anything retires them. The labs’ answer is a periodic “dreaming” pass that goes back through the store and rewrites stale entries to their current value.5 Running it offline is the right call, but the real constraint is judgment: rewriting a stale entry requires knowing which value is current.

And a settled fact that changed is the easy case. Some of what an agent stores is a perspective still being worked out, moving faster than anything gets written down. On a strategic project I’m working on with one of my partners, my agent’s memory holds one structural decision as settled doctrine. It isn’t: we’re still working out the long-term shape, and on a recent call I floated changing it entirely. The current view lives in that ongoing work, not in the memory. Nothing has forced the agent to choose between them yet, and when it does, the answer it’s surest of will be the stale one.

The question worth asking

The real question about any agent you’re starting to trust is whether it knows which of the things it remembers is still true, and acts on that. Recall is becoming something you can buy; that judgment isn’t (at least not yet), and it’s thinnest exactly where we’re most eager to put agents in charge.

For now, the only thing between you and a confidently stale answer is a person still in the loop to catch it, and that person is exactly what the rest of the industry is racing to design away.

“Hire for the ability to learn” is still right, but the claim was never the test: anyone can say it. What’s new is the evidence you can now ask for. There’s a test for it that works in any function, and it changes who you want on a team.

I was at a breakout session at a conference recently with a room full of product and engineering leaders and a handful of CEOs, all working through the same question: what changes now that product managers can code and engineers can design? A VP of Engineering at a publicly traded company declared: nothing’s changed. You hire for the ability to learn, find smart people who can pick things up, and they’ll figure out the rest.

I think he’s right that you hire for the ability to learn. He’s just wrong that nothing’s changed.

What actually changed

The ability to learn was always what you wanted, and always easy to claim and hard to check. What’s new is the evidence: you can now ask to see what someone’s learning has actually built.

And the stakes on reading that evidence right went up, because AI multiplies what a person produces, and the multiplier depends enormously on the setup they’ve built. The gap between a strong, self-built AI setup and an equally capable peer without one isn’t a few percent; it can be several times the output. (I can’t measure it precisely, but the difference isn’t subtle.) So you’re no longer hiring the person; you’re hiring the multiplier they can wield.

Subscribe now

Show me your mech

The sharpest answer to that comes from a repeat founder in NextView’s portfolio: almost a decade running a developer-tooling company, now building in AI tooling, very technical, with a deliberately tiny team. His hiring bar is brutal, because his own setup is so powerful that he won’t bring on anyone who’d slow him down. So his interview is one ask: show me your mech, and teach me something I don’t know about how you leverage AI.

I recognized the word the second he said it. In the shows my kids watch, a mech is a powered robotic suit a pilot climbs into. It makes the pilot far stronger, but it’s still the pilot flying it. Someone’s AI mech is the tooling and workflows they’ve built around the shape of their own work: coding agents and custom skills for an engineer, a research-and-drafting stack for a marketer, a data-to-first-draft pipeline for an analyst.

What makes a mech worth asking about is that it’s self-assembled. The base can be handed to you (plenty of companies now build their own custom coding agent as shared infra), but the mech is the layer on top: how you’ve shaped your own setup and how well you wield it. Hand two people the identical tool and they still produce very different output, because the multiplier comes from the person. You can’t buy that off the shelf or fake it; it’s the accumulated residue of someone solving their own problems over and over. That’s what makes it evidence of learning rather than tool-ownership.

You’re still hiring the person, but the mech is the clearest window into how they learn when no one assigns the curriculum. A portfolio shows outputs (often old, sometimes a team’s), while a mech shows the production system and the frontier they work at right now. That’s what the second clause does: “teach me something I don’t know” turns the interview from judging someone’s past into watching them show you a piece of the future. That’s how you tell a real practitioner from someone who’s only ever run the defaults.

But the move worth stealing is to lift his rubric into a general lens, because a practitioner working at the extreme often reveals a principle the rest of us can use in a milder form. And it isn’t specific to engineering: the recruiter who automated her sourcing is showing you the same thing the engineer is.

Running the test

To run it, get concrete: what did you redesign, and what broke first? Someone who’s shaped their own setup answers instantly and in detail, while someone who’s only ever run what they were handed goes vague exactly where the self-directed learning would show up. The size of the mech matters less than whether they’ve shaped one at all.

You’re screening for a disposition, not a tool list, so it isn’t elitist. Someone who’s never touched AI isn’t disqualified; it just shifts the burden to finding the learning evidence elsewhere. The mech doesn’t replace what you already evaluate (domain depth, judgment, taste). It’s an added layer. And you don’t need a mech yourself to run the test, since anyone can tell teaching from hand-waving; for the deeper read, loop in someone who wears one in that function.

What it changes about teams

Why want mech-wearers beyond speed? They make a team T-shaped: deep in one function, credible across several. Role-blurring doesn’t mean roles collapse. A product manager who can code is still a product manager, working at roughly an average engineer’s level (a “1x”) but not beyond it. A mech activates the horizontal bar of the T, so a specialist can flex to a credible 1x in an adjacent function instead of stalling.

The stalls usually happen at the seams between functions: the marketer waiting on the analytics team for a data pull, the product manager waiting on engineering for a prototype. A mech-wearer fills those white-spaces, so the chain stops breaking every time work crosses a boundary.

It’s also changing what a senior career looks like. If one person carries both depth and breadth, they can operate with close to the leverage of a small team, which makes going back to individual-contributor work look very different than it used to. Peter Bailis, the former CTO of Workday, recently left to become a “Member of Technical Staff” at Anthropic (the same title it gives a new-grad engineer), one of several CTOs of billion-dollar companies who’ve made the move in the past year. Put enough mech-wearers on a team and it out-produces one several times its size: the leverage compounds at the org level, not just the individual.

You’re hiring the learner

So the VP of Engineering at the breakout session was half right. You are hiring for the ability to learn, the way you always were, but what changed is how you get evidence of it. “I’m a fast learner” is a claim anyone can make, while “here’s the mech I built, and here’s something I can teach you” is proof you can see. So if you’re staffing a team now, stop asking people to describe how they learn, and ask them to show you what that learning already built, whatever their function.

Previously in Ground Truth: The Structural Divide argued that individual AI productivity doesn’t automatically scale to the organization, because the gap is structural, not behavioral. The mech test is one lever on the human side of that gap: who you hire determines how much of the individual flywheel your team actually captures. The Country of Geniuses Test asked which parts of your work survive as AI gets cheap, and what scaffolding you have to author yourself. The mech is how you recognize the people already building that scaffolding for their own work.

Nine months into using AI as my main work driver, review time has become the bottleneck. There’s a fix forming across senior practitioners, and a company-scale architecture question that follows.

I start most of my work days in Claude Code. Anything repetitive, anything codifiable, anything that takes more than ten minutes to do, I try to delegate to AI agents. At any given point I have five or six parallel agent sessions running, and my work is jumping between them to check their output, give direction, and then move on while they continue. As a result, I focus my limited bandwidth on the things that truly only I can do — for now.

Nine months in, the more I use it, the more I want to use it. But the math has a limit: I cannot 5x my output while 5x my review time.

The management analogy

Around January, a recurring frustration led to a realization: there should be a way to codify every time Claude makes a mistake. I hate being inefficient, and the beauty of code is that you can systematize it.

It’s the same discipline as management. When someone on your team makes a mistake, you walk through it in a one-on-one and help them internalize the lesson so the mistake hopefully doesn’t happen again. Code on top of a probabilistic machine can be more reliable than human internalization, if you know how to encode the rules into the system (rather than relying on human memory alone).

The result is a Claude Code skill I call learning-loop that I run after every session to capture the learnings. Without it, I’d be running in circles and Claude would still be making the same kind of mistakes five months from now.

Subscribe now

A forming chorus

Not managed well, verification cost scales linearly with output, and the bottleneck shifts rather than disappears. Most responses (the wave of code-review startups, “human in the loop” at organizational scale, simply giving up on “using AI” at personal scale) relocate the cost without reducing it.

But a different response has been forming across senior practitioners, scattered through their essays and X posts over the past several months. Garry Tan calls his version “skillify”:

“My agent screwed up twice this week. Neither failure can happen again. Not because I asked nicely. Because I turned each failure into a permanent structural fix: a skill with tests that run every day, forever.”

Boris Cherny, Anthropic’s Claude Code lead, captured the same move in his public Jan 2026 Claude Code thread: “Update your CLAUDE.md so you don’t make that mistake again.” Mitchell Hashimoto and the OpenAI Codex team have made variations of it.

The move works because the harness is modifiable. By “harness,” I mean what Garry Tan calls “the program that runs the LLM.” Its four jobs: run the model in a loop, read and write your files, manage context, and enforce safety. The scaffolding has to exist somewhere: at the individual, team, or organization layer. Without it, every session starts blank and the verification tax compounds downstream.

Two levels of verification

The verification work splits into detection and upstream engineering.

Detection comes first: spot-checks, “show your work” discipline, and review at output time. These catch more mistakes. You can leverage some clever review techniques (e.g. expert or adversarial review subagents) to make review marginally faster and more thorough, but that’s not the same as improving system-level efficiency.

Upstream engineering is where compounding happens. Each captured mistake becomes a permanent rule that stops the same mistake from happening. Over time, fewer mistakes show up at the review step at all.

Five months of running the learning-loop skill I built produced one structural observation: the verification step doesn’t balloon, because most potential mistakes get engineered out at source. I spend a decent amount of time authoring the upstream engineering, but I treat it as worthwhile investments that compound downstream to help me scale my output without scaling review time.

The company-scale architecture

One of my partners at NextView and I were dividing up work of a project we’re collaborating on. Both of us use Claude Code as our main work driver, and there’s a piece of work that he was handling with Claude that was upstream of mine.

When I started building upon it, I ran a multi-pass review of my work and unexpectedly found that nine out of ten items from his portion had meaningful drift: fabricated statistics and citations that didn’t cover what they claimed to cover. My partner is smart and great at his job; the gap was the verification toolkit. Without the upstream-engineered detection layer, the mistakes would have compounded into my downstream work.

That’s the two-person-scale version. Scaled to a company, the pattern multiplies (shared agents, agent-to-agent handoffs, no centralized review bottleneck): two colleagues would hit this once; two hundred employees sharing the same set of agents will hit it constantly. The Build-vs-Buy Reset named the architectural question of which capabilities to build vs buy; verification infrastructure is now another item on that list. The default response, “human in the loop downstream,” not only does not scale your capacity to leverage AI in a meaningful way, it also makes the lowest-verification-capability person on the team the team’s effective ceiling.

This is solvable at two levels, although neither is straightforward.

At the individual level, the move is empowering and educating each builder to maintain their own learning-loop: every detected mistake becomes their permanent harness rule. At the organizational level, it’s a build-or-buy question of its own. Buy: a growing set of vendors in the verification-loop category. Build: stand up internal ownership of harness rules, mistake-codification, and the feedback path from production back into everyone’s AI stack.

Where capital is moving

Capital is starting to fund the vendor side, but two adjacent categories are worth separating. Traditional eval and observability platforms (Braintrust, Arize, LangSmith, Patronus AI) monitor and score model outputs against predefined success criteria. For general-purpose agents where defining “right” is itself the work, that’s necessary but not sufficient.

Self-improvement is the next layer up: catching in-session misfires, analyzing root causes, and retooling the prompt or harness with less human intervention than traditional eval/observability requires. Lemma claims to detect semantic failures and auto-generate prompt improvements. InsightFinder, an enterprise AIOps incumbent, has extended into automated root-cause analysis for AI workflows. Judgment Labs takes a different angle: breaking down where in an agent’s run things went wrong as a continuous-improvement layer. Braintrust’s “Loop agent” is the eval incumbent extending into the same layer. The category itself is too young to have defined winners.

Four standalones have been acquired in the last twelve months: Galileo by Cisco, Promptfoo by OpenAI, HumanLoop by Anthropic (sunset Sept 2025), and Langfuse by ClickHouse. Whether verification survives as a standalone layer or gets absorbed into the model platforms is the open question for the category.

METR, an AI-capability research org, tracks how long agentic tasks stay at the frontier; their latest update shows task time-horizons now doubling every 3.5 months, down from seven. As capability moats decay, verification-loop infrastructure is the layer that compounds in the other direction.

What compounds against the model

For most teams, the binding constraint of scaling AI-assisted output is the verification loop. The teams that will use AI well (at the individual or organizational level) are the ones whose harness gets harder to defeat every week. As capability keeps accelerating, the moat is in what compounds against it.

Previously in Ground Truth: The Confidence Gap established that AI confidence is not correlated with AI correctness, the foundation this post extends. Who Captures the Value? named verification as the scarce complement to execution; this post explores what verification infrastructure looks like in practice. The Judgment Layer decomposed unverifiable decisions into verifiable sub-decisions plus irreducible judgment; this post argues the verification work on the decomposable part needs its own architecture.

The country of geniuses isn’t here yet — but the scaffolding decisions are. Most are running the math on their work and concluding they’re safe. They’re answering the wrong question.

The forecast and the test

Anthropic CEO Dario Amodei has named the upper bound on AI capabilities that are coming. On Dwarkesh Patel’s podcast in February, he said we’re ten years from “a country of geniuses in a data center” with 90% confidence, with a hunch closer to one to three years from now.

Dwarkesh pushed back inside the same conversation: “When I think of an actual country of human geniuses in a data center, I would happily buy $5 trillion worth of compute. [...] I’ve got a country of geniuses. They’ll start their own company.”

Dario’s answer was that if we had it, we’d know, and we don’t yet. That doesn’t mean you can’t picture it.

Imagine your company, your industry, your function, your job. Suddenly you can hire a country of geniuses cheaply. And the cost barely changes whether you hire ten or ten thousand. Generally brilliant people who just show up at your door, but they haven’t been taught how to do your job. How likely are they to do what you do, or what your company does? What additional training, hand-holding, guidance, and learning the ropes would they need?

Whatever your answer, it matters today, not when the geniuses arrive. Because the work it points to takes time. Run it on yourself before reading on.

Subscribe now

What stays human, and what you have to build

Running this test produces two answers, a predictive one and an operational one.

The predictive answer is what stays human: the judgment about your domain, the standards for “good,” the pattern-recognition you spent years building. This is what I’ve called the judgment layer: the irreducible residue after everything with a fast-enough feedback loop has been automated. The questions you’d ask, the heuristics you’d apply, the gut you’d trust when something looks off.

The operational answer is everything else: what you, your team, or whoever’s building your category’s AI infrastructure has to author. The agent doesn’t know your company, your customers, your unwritten rules. It doesn’t know which constraints bend and which break. The “additional training, hand-holding, guidance, and learning the ropes” you just listed in your head is a prescriptive list, the layer The Build-vs-Buy Reset laid out: the fit your vendor can’t ship for you, because it has to come from your context.

Most “AI replaceability” discourse collapses these into one, and that’s where lazy takes come from.

The misread in the wild

Most senior operators run this test mentally, see the high tax, and stop there.

Earlier this month I saw a Substack Note, Build Your Own Single-Stock Analyst with AI. I had no idea if it was any good (probably a generic vendor attempt), but the idea was interesting enough to illustrate what’s possible in finance, so I forwarded it to a friend who’s a portfolio manager at a hedge fund.

Her reply: “That’s cool, AI can do a lot of basic analysis but still get a lot of info wrong.”

I wrote back: “Yes you just need to know how to use it to unlock the power. It’s a jagged frontier.”

Doug O’Laughlin, the President of SemiAnalysis (an independent semiconductor research firm), uses Claude Code at a sophisticated level for non-coding analytical work. On Latent Space’s Claude Code in Finance episode, he explained the edge: “Your job is to find information edges and new ways to put information together that no one else has done. I’ve always thought it’s really important to know the most important weapons-grade tool.”

The result: “That massively amplifies everyone who is an expert. And we are a firm filled with experts. You have to still do something. You can’t just slop it up.”

People are already building scaffolding for their own jobs, often imperfectly. The expert who pays the tax to tune wins.

What to do now

The scaffolding the test reveals is the same either way. Timing decides whether you’re ready or scrambling.

The intelligence curve isn’t flat. Today’s scaffolded agent yields roughly associate-level judgment; the next generation of models running the same scaffolding could land at principal or partner level. What you author now compounds against the capability curve, not against today’s snapshot.

This is The Consensus Machine applied to timing. Today’s non-consensus becomes tomorrow’s consensus, and the bar at the top of the pyramid keeps rising. Authoring scaffolding now means you’re at the moving frontier when capability arrives, not still building when others are already deploying.

If you’re an individual operator, your experience is the asset, and the more senior you are, the more asset you have to deploy. Right now junior people are eager to experiment while senior people are complacent. That actually flips the question of who should be leveraging this.

If you’re a founder or CEO, the test gives you a two-decision split: what AI can replace immediately (SOP-defined work where vendors can ship) and what needs scaffolding authored from inside (judgment work where vendors can’t, because the fit has to come from your context). Most companies are getting the second one wrong by default.

For startup builders, the wide space is where the labs won’t actually go deep. Anthropic ships Agents for Financial Services — ten ready-to-run templates that cover everything from pitchbook building to month-end close. But ask any accountant: templates aren’t a firm. The work that requires deep, domain-specific scaffolding sits a layer below, integrated into how a firm actually operates. That’s why a wave of venture-backed AI-native accounting firms is showing up to build it.¹

The scaffolding gets built either way — the question is whether you author it or inherit it.

¹ The venture-backed deep-vertical accounting wave as of May 2026: Basis — AI agents for accounting, tax, and audit workflows; $1.15B valuation (Feb 2026), working with ~30% of the Top 25 US accounting firms. Accrual — $75M led by General Catalyst (Feb 2026), targeting Preparation & Review at Top 100 firms. Modus — $85M led by Lightspeed (April 2026), building an AI-native accounting firm, not a tool vendor. Synthetic — $10M Khosla seed (May 2026), Ian Crosby (formerly of Bench) building autonomous bookkeeping for software startups. Puzzle — AI-native accounting software for startups and small firms.

Previously in Ground Truth: The Judgment Layer (the unbundling thesis) · The Build-vs-Buy Reset (the operational framework at company scale).

AI agents are becoming the new discovery layer, sitting above Booking.com, LinkedIn, and the platforms that currently own consumer demand. The structural move that hotels spent fifteen years trying to make is now available to any startup with the right infrastructure. The categories where it works, and where it collapses on contact, are written in the loudest defensive moves incumbents are making right now.

At the happy hour we (NextView) hosted in San Francisco last week, I was catching up with one of the Gondola cofounders. Gondola is one of our portfolio companies, a consumer travel startup. Their pitch is simple: search for a hotel, compare cash and points across every major chain, book in one click, get the loyalty credit as if you’d booked direct with Marriott or Hilton.

I use AI agents heavily in my own work and home life, including a personal trip-planning project where I tried to get an agent to compare rewards calendars and monitor pricing. I quickly gave up the attempt because travel websites are some of the most locked-down on the consumer internet: bot detection, fingerprint checks, session tokens, captcha walls.

So I was very curious how Gondola does it.

He described what’s underneath the consumer UI as “a whole architecture in the background.” The outcome is publicly visible on Gondola’s MCP: every booking goes direct to the hotel (Marriott, Hilton, Hyatt, IHG, Accor, Wyndham), preserving member rates, loyalty point accrual, status nights, and credit card rewards. The product is the one-click consumer UX; everything underneath stays invisible.

The question that conversation raised wasn’t how they did it. It was: why did a consumer travel startup have to build infrastructure that big just to ship a booking flow?

The framework underneath

A decade ago, Ben Thompson named the structural rule of the internet age: aggregators own demand. Once digital distribution became free, the contest shifted to who controlled the consumer interface. The winners (Google for content, Booking.com for hotel rooms, OpenTable for restaurant tables, LinkedIn for professional identity) all followed the same template. They captured demand; suppliers came onto the platform on the aggregator’s terms.

Thompson updated the theory in 2019 to acknowledge a blind spot: where supply is concentrated, aggregators can’t commoditize it. Where supply is fragmented (hotels, restaurants, individual professionals), they can.

The framework governs content, networks, and transactional marketplaces alike. What’s new in 2026 is that AI agents are becoming the next demand-side layer. When your agent searches for a hotel, the agent IS the new Booking.com. The question is which seats at this new game are still open.

Subscribe now

What hotels couldn’t do alone

Take lodging. Hotels have spent fifteen years trying to escape Booking.com and Expedia. In 2016, Hilton ran “Stop Clicking Around,” its biggest marketing campaign in 97 years. Marriott launched “It Pays to Book Direct” the prior September. Every major chain offered exclusive lower rates for loyalty members who bypassed OTAs.

The campaigns failed structurally. From May 2016 to 2017, Marriott’s US online-bookings share fell 37%, Hilton’s fell 6%, and Booking.com kept growing 22% year-over-year. Expedia spent $4.3 billion on marketing in 2016; Priceline Group spent $3.5 billion on performance advertising alone. Hotels spent a fraction of that. They couldn’t win the discovery layer because they couldn’t outspend the discovery layer.

The OTA’s moat was never price or convenience; it was demand discovery. As long as consumers searched through Booking.com, the OTA tax held even when hotels offered the same rate directly.

By 2026, two structural shifts had landed. A September 2024 European Court of Justice ruling1 weakened the contracts Booking.com used to keep hotel pricing uniform across channels, finally letting hotels undercut OTAs on their own websites. And AI agents had started becoming the way consumers search.

This is what the Gondola team built around. Agents are the new discovery layer, but they don’t reach consumers as raw developer tools; they reach consumers wrapped in products like Gondola. Hotels don’t need to outspend Booking.com on marketing if a consumer’s agent layer routes the booking directly to the hotel. The structural move that hotels couldn’t make alone in 2016 is now possible because the discovery interface itself moved.

When this works, when it doesn’t

Three questions determine whether the Gondola pattern holds in a given category.

One: who controls the supply? Hotels existed long before Booking.com. They have brand.com sites, direct phone lines, and loyalty programs of their own. Booking.com was a tax layer on top of pre-existing supply, never the supply itself.

Two: is the irreplaceable supply re-aggregatable through a different layer? Marriott isn’t replaceable; any credible hotel platform must carry Marriott. But Marriott IS reachable directly. The same supply that Booking.com aggregated can be aggregated again, by a new layer, through the chains’ own direct channels.

Three: can the agent tech stack actually do the work? The effort Gondola had to put in was non-trivial. The real challenge was building the infrastructure layer that lets agents reliably and repeatedly integrate with hotels on the web. That's where trust is built with the end customer, and it also answers whether the technical move is doable for a startup, not just possible in theory. When all three hold, agents do what hotels alone couldn’t: bypass the discovery layer without having to outspend it. The move collapses if any one fails.

Airbnb and Uber are harder cases because the aggregator created the supply category alongside its marketplace. There’s no parallel pool of Airbnb-style hosts organized around a trust infrastructure that Airbnb doesn’t control, and Uber drivers don’t exist as a service category outside the platform. But the opportunity isn’t categorically gone. A meaningful chunk of Airbnb’s supply runs through professional property managers who are individually reachable, and Airbnb’s own consumer search experience is dated enough that an agent layer wrapping a better UX could compete from above. The work is bigger than the lodging case: condition two (supply re-aggregability) is partial rather than clean, and condition three (technical lift) compounds with a demand-side UX rebuild. The real driver of difficulty isn’t whether the aggregator created the supply; it’s how identifiable and grouped that supply is. Truly atomized single-unit individuals stay hard.

Amazon’s stronghold isn’t supply lock-in; it’s demand-side experience. Most of Amazon’s catalog is third-party sellers with their own direct channels, so supply is technically reachable. What holds Amazon together is the demand-side UX: superior logistics compounded by Prime membership benefits that most consumers would not want to live without. When Perplexity’s Comet agent began making purchases on Amazon’s marketplace last fall, Amazon sued, and a federal court issued a preliminary injunction blocking Comet in March (currently under appeal). When the aggregator’s demand-side experience is genuinely superior, consumers won’t leave even if supply is reachable, and condition two effectively fails.

Independent retailers don’t fit because the technical work isn’t doable yet. OpenAI shipped Instant Checkout in fall 2025 with a small set of retail partners and pulled it back in March 2026, pivoting to merchant-native apps instead. Catalog accuracy, multi-item carts, sales tax, and checkout reliability all broke against the long tail of independent retailers. Condition three fails for the merchants that don’t have real-time programmatic infrastructure ready.

Four patterns from different answers

Different answers to those three questions produce four visible positions. Two are startup moves; two are incumbent moves, with most categories producing a fight between them.

From below: disintermediate the aggregator with willing supply. Gondola is doing this in lodging: hotels are pre-existing supply with direct channels and (now) genuine incentive to escape OTA economics. The agent does what the supplier alone couldn’t: route around the discovery layer without having to outspend it. The moat is the invisible work: the year of integration logic Gondola spent on the architecture that makes every booking land as a direct booking, with the right loyalty credit, across every major chain.

From beside: rebuild parallel where the supply IS the network. Boardy (disclosure: a NextView portfolio company) is attempting this for professional networking. LinkedIn’s value isn’t the platform; it’s the graph: your professional network, your reputation, your second-degree connections. Because LinkedIn’s graph isn’t extractable in practice anymore2, Boardy is building parallel: voice-mediated agent introductions among opt-in participants, a connection layer that doesn’t extract LinkedIn’s graph but builds an alternative one through new participation. (Boardy recently celebrated its 100,000th connection, gathering richer signal through voice, chat, text, and email than any static profile can.)

From within: go headless on your own terms. Shopify is the cleanest case. Their customers were always merchants, not consumers; Shopify has been infrastructure, not a consumer brand, from day one. Extending that infrastructure to be agent-readable (MCP integration, the Universal Commerce Protocol co-developed with Google, agentic storefronts available to non-Shopify merchants too) is the natural agent-era progression of the merchant-infrastructure strategy. The bet: when buyers come through agents, the rails merchants run on become the strategic surface.

From above: tollgate the agent traffic. SAP issued a policy prohibiting customers from using OpenClaw and other AI agents that “plan, select, or execute sequences of API calls” without official sanction. ServiceNow launched Action Fabric, explicit metered access for agents accessing app data. JPMorgan’s Mark Murphy described ServiceNow’s pricing as “effectively a tax on customers using outside AI agents to interact with data they already store in ServiceNow’s apps.” The bet is that switching costs keep customers paying the toll rather than leaving. For decades, that bet has worked: replacing an ERP is painful enough that customers absorb pricing changes rather than migrate. The agent era changes the math. When the agent experience inside SAP or ServiceNow is degraded by policy, customers don’t just pay; they route AI-native workflows through tools that work better at the application layer above. Over time, those tools accumulate the data the system of record used to own. The toll gets extracted in the short term, but the underlying system gets disintermediated from above in the long term.

Most incumbents will pick #4 because it feels like preserving optionality: you don’t shut the door, you charge for it. But #4 is the worst long-term position: it announces “we are the obstacle,” which invites a Gondola-style response from below or a Boardy-style rebuild from beside. The winners actively pick #3 (build the rails on your own terms) or get rebuilt around without a fight.

The harder question

This post answers which categories admit the disintermediation move. Who earns the right to build the user-facing agent surface is the harder question, for a separate piece. The demand-side build isn’t trivial: the new agent has to deliver a step-functionally better value prop than the incumbent, not just a better UX. The incumbent’s marketing budget, funded by the very take rate the disintermediator is trying to break, will outspend anything merely good. The bar is qualitative superiority on the fundamental value, not the surface, on both consumer and B2B agent interfaces.

Gondola’s hidden architecture isn’t infrastructure. It’s a head start.

Previously in Ground Truth: The Build-vs-Buy Reset (workflow innovation from the top of the application layer) · The Context Gate (agent access constraints, the prior framing of the access-route question).

A portfolio founder told me what I’ve been investing in is “temporary, like prompt engineering a year ago.” He thinks AI products will get intuitive enough, fast enough, to wash out any specialized practice. I’m betting the ceiling rises faster than the floor, and the gap between the two is where personal advantage compounds in the meantime.

A portfolio founder and I were on our monthly catch-up last month. The Zoom ended; the conversation kept going over text about how I’d been spending my time: building on top of agent harnesses, codifying how I work in markdown files, getting the muscle memory you only build by working with models and agents closely.

His take:

“does it matter though? Any gaps will be closed in months.”

“this is like ‘prompt engineering’ a year ago — temporary workaround until the models just anticipate all needs and fill all gaps.”

“NOT YET! talk to me in a year.”

It’s the most articulate version of a position I’ve been hearing from smart, technical, successful operators: don’t bother building skill on top of a layer that will get vendored or abstracted away.

He’s not wrong that the floor is rising. The question is how fast.

The floor and ceiling are both rising, at different speeds

I think his position only holds if the floor is rising faster than the ceiling, fast enough to wash out any specialized practice before it pays back. There’s a version of the bet where the floor and ceiling rise at the same speed; the practice is still temporary, you just trade today’s gap for one that re-opens as the floor rises.

What I’m actually betting on is different: the ceiling is rising faster than the floor. The reason is structural. The underlying intelligence of the models is improving faster than the user-facing UX, and we genuinely haven’t figured out how to teach most people to use AI well. The product surface lags the capability frontier, and that lag is where personal competitive advantage lives.

The shift from assembly to Python didn’t eliminate the advantage of being a systems thinker; it moved where the advantage lived. The systems thinker who learned Python on top of assembly intuition outperformed both the purist and the Python-only beginner.

Pushing the ceiling is a practice.

Subscribe now

What the argument is actually about

His underlying bet runs deeper than the harness layer. He thinks the labs and AI providers will make the products intuitive enough, fast enough, that you won’t need any specialized know-how to get the value. The floor will rise high enough that the ceiling comes within reach without the work.

I wrote about why I think this is wrong last week. Even when the products are intuitive, the surface area of your work doesn’t become legible to a generic agent. Vendors ship generic judgment by design: customer-specific drafts, workflow templates, opinionated defaults. The specialization stays user-side: which prospects to push on this quarter, what “better” means inside the specific shape of your job.

The question is whether you know how to direct the model at the parts of your work that need the smarts versus the parts that need your judgment.

The meantime, made concrete

Last Friday, I was talking with my neighbor at a backyard gathering on our street. We started in the same investment-banking analyst class almost twenty years ago; he’s now an MD at a distressed-credit fund. He’d read one of my earlier posts and asked: how do you actually do this AI-writing-memos-with-all-your-diligence-information thing?

He described what he wanted: raw diligence files in, structured memos out. I told him it was a two-hour problem if he set it up right: persistent context, treating the agent like a junior employee who writes everything down for next time, scaffolding rules around the parts of his work that matter. Without that grounding, even Claude Cowork would disappoint and just produce the generic “not very good” version.

Claire Vo, the founder of ChatPRD, is what the other end of that question looks like. She recently put GPT-5.5 through three real jobs that span the full difficulty range of her work:

• A teaching app for her second-grader on advanced subtraction. Planned and generated in 17 minutes, working first try.

• A tech debt migration of millions of legacy chat threads in her own production codebase. It ran for six hours autonomously, with one edge case failure across two million rows.

• Reverse-engineering a proprietary Chinese Bluetooth speaker protocol that earlier models had been failing at since January. GPT-5.5 cracked it.

Her own summary of what changed:

“It’s about raising the ambition of what’s possible... I’m now throwing GPT-5.5 at my bug backlog, flaky tests, and security assessments — the hard stuff.”

Both ends moved at once. The model raised the floor for everyone, but the practice is what got her to those three jobs together.

The people closer to the ceiling don’t experience it as ceiling work. They call it raising ambition.

My own bet

I’m aware I’m biased. The body of work below is the test, not the testimony.

I studied finance and accounting in college, started my career in investment banking, and have spent the last decade-plus leading product, design, and data teams and now investing in early-stage startups. I never pushed a line of code until about eight months ago, when I started working with coding agents. Everything below has been built since then.

Three apps for my kids

The first cluster is small applications I’ve built for my family. Hanzi Dojo, an app to help my kids learn traditional Chinese characters and Zhuyin (in addition to the simplified and pinyin they learn at their immersion school). A catalog to showcase my kids’ Lego creations. The Mini Mint, a synthetic banking and investment app for my kids to save, spend, and learn investing without having to open Greenlight and Robinhood accounts.

None of these would have warranted an outside vendor historically; too niche, too small, too household-specific. The cost-vs-fit equation I wrote about last week has flipped: I have gaps I want filled perfectly, and the cost is weekend time. The maintenance is the point. These three repos have accrued 287 commits between them, solving recurring problems for two kids whose interests keep moving.

Fifteen minutes on a Friday

A few weeks ago I came across a thread in a local parents’ Facebook group, about 40 comments deep with summer activity recommendations. The information was buried, redundant, and missing the metadata that would make it usable. I wanted a referenceable version, so I tried to build one.

I started in ChatGPT: screenshots in, dedupe, organize, sort by drive time, research official URLs, catalog by attributes. Ten minutes in I lost patience with it. It kept making mistakes (fix one thing, lose another). It had no context about how I work.

So I switched to Claude Code. “Set up a repo. Here’s what I want to do.” It handled the whole thing in two turns.

That difference is about the relationship to AI, not the model, which is what I wrote about a few months ago. Same task, same person, same underlying intelligence; one session was a disposable chat, the other an environment with months of accumulated configuration (root-level instruction file, custom skills, harness settings, conventions baked in across every repo). The scaffolding had already encoded what good looked like. The clean reference page that came out was personalized as a side effect of feeding the agent the right inputs.

“Spin up a personalized, useful artifact in fifteen background minutes on a Friday” is the new shape of what the practice produces. The fifteen-minute output isn’t downstream of the agent; it’s downstream of the months of investment and learning behind it.

What this body of work has produced for me

The same intuition shows up in more traditional product work. AI-assisted deal evaluation system at NextView: about twenty sessions with a coding agent got me to an MVP that compiled and worked last fall (when I was way less proficient with coding agents than I am now). My engineering partner’s cleanup was mostly streamlining the code and engineering best practices around production apps. The ongoing work is prompt iteration.

Three meta-skills have come out of this work, and they’re the parts that travel.

First, I can route a diagnosis when something doesn’t work: model limitation, context problem, or scaffolding setting.

Second, the practice is a self-reinforcement loop. The more clearly I understand how the pieces fit, the faster the new learning compounds. I can read a new technical approach (e.g. multi-agent orchestration, file-system memory patterns, async pipelines) and either apply it or flag where it doesn’t fit.

Third, this fluency is now a load-bearing input into building AI products. Building them well requires understanding which components are malleable: how to work with the models, how to work with the harness, where probabilistic and deterministic outputs trade off, where context leaks happen.

By the framework I use across Ground Truth, from Level 1 (single chat) to Level 4 (autonomous agent harness), I’m operating at Level 3 daily and Level 4 in specific workstreams.1

In the meantime

His “talk to me in a year” is right about the timeframe. In a year, both the floor and the ceiling will be higher, and my bet is the ceiling keeps rising faster. The question worth sitting with is whether you’re the kind of person who pushes ceilings or waits for them to be lowered.

The gap is where the practice pays off. That’s the bet I’m making in the meantime.

Previously in Ground Truth: The Trust-Utility Curve (why the setup cost is real, and what’s on the other side)

Microsoft Copilot has 3.3% paid adoption across 450 million seats. “Claude Code changes everything” is also true. Holding both at once is the build-vs-buy reset most companies are getting wrong by default.

The phone you can’t use

My friend Dorothy described what it’s like to use an AI tool that wasn’t tuned to her work as picking up someone else’s phone. The home screen is custom, the keyboard is wrong, and the notifications belong to someone else’s life. The analogy has stayed with me.

The “Claude Code changes everything” claim that’s been circulating is true. A non-technical comms founder shared on X that he built a six-agent personal chief-of-staff system in three weeks; the post reached 3.7 million views. The “I’m not an engineer and I shipped my own tools” wave is real. But it’s only true inside your sphere of context — the lived reality only you have access to: your inbox, your live data, your permissions, the way you actually think about the work. Outside it, the claim is false promise.

This is not a personal problem

Classic build-vs-buy has always been a cost vs fit equation. You buy when the vendor’s 80-20 generic version is cheaper than the personnel cost of building and maintaining your own. Most companies bought, because building was expensive.

AI moves both sides of that equation. The 80-20 generic used to be the ceiling on automation; now there could be a personalized version above it. And the cost of building that personalized version has collapsed: coding agents put authoring within reach of non-engineers, and they’re making engineers 5-10x more productive. Productivity scales with how well the system fits the individual’s live context, but vendors cannot ship that fit. The user has to author it, and they can now.

Salesforce shipping AI on top of its data can already produce “Here are five draft emails to send your prospects.” With more context (e.g. call recordings and meeting notes), the drafts can reflect this prospect’s quirks versus that one’s. They are still not quite the drafts that AE would have written. What the vendor can’t see is the AE’s theory of the funnel: their gut for which prospects are worth pushing on, when to apply pressure and when to wait. Vendors can ship the artifact, and increasingly customer-specific authoring layers. What they can’t ship is the individual judgment that drives the authoring: the AE’s mental model on sales execution.

The new bar is closer to a new hire than a SaaS feature. A new hire gets trained on what this company does uniquely, what this manager wants. That iteration only happens if the author invests the effort to codify their unique taste, judgment, and context. Legacy players executed perfectly against the 80-20 standard, but the standard has quietly shifted.

The reset is happening at two levels. The capability layer: most individuals can’t author their own AI fit, and the ones who can may not sustain it. The structural layer: vendors with the data can ship working AI features and may even reprice around labor-cost displacement, but they can’t ship your AI on top of their data, because the user-level fit isn’t an artifact a vendor delivers; it’s a layer the user authors.

Subscribe now

The SOP/judgment split

The split is between work where the playbook is the same everywhere and work where your unique judgment is the work.

SOP-defined work is the first kind: lead scoring, document summarization, compliance review. Context variance is low (everyone is looking at the same fields, the same ticket structure, the same approval path), and judgment variance is low (the SOP defines what to do). The sphere of context is the whole company, and vendors with the data can ship working AI here.

Judgment / non-consensus work is everything where your unique judgment is the differentiator. Deal evaluation in venture, strategic decisions, judgment-driven content, the parts of your job you wouldn’t trust to a contractor. Per role, per task, per individual, the context shifts and the judgment shifts with it. The sphere of context here is the individual, and vendors can’t ship working AI without re-creating the per-individual authoring problem.

This is The Consensus Machine applied to the build-vs-buy decision: tokens win on consensus, judgment wins on non-consensus, and the way you enable each layer is different.

Companies face two build-vs-buy decisions. Call it the SOP/judgment split. The SOP layer is one decision; the judgment layer is another.

The SOP layer: still default, but contested

For SOP-defined work, the systems of record (SORs) are the default destination: Salesforce + Agentforce on CRM data, Microsoft + Microsoft 365 Copilot across Office and Teams, ServiceNow + Now Assist on the ticket data IT and ops teams already live in. They have the data, the workflow surface, and decades of operator habit on their side.

But the buy decision is contested in real time. Microsoft 365 has 450 million users with free Copilot Chat access; only about 15 million (3.3%) pay for Copilot. The default purchase isn’t winning the displacement game.

The reason is structural: every company has its own schema, definitions, and escalation paths, and a generic agent on top of SOR data isn’t useful until someone inside the firm has configured it to match. And most companies haven’t done that work.

That gap creates the opening for AI-era workflow-wedge attackers. A good example is Sierra, co-founded by Salesforce’s former co-CEO Bret Taylor: a CX agent built to live on top of whatever the customer’s stack is, not bound to any single SOR. If the agent is doing the entity reconciliation, the scoring, and the actual interaction, the SOR’s role compresses to “a database other systems read from,” a much weaker moat than “the system the reps live in every day.”

For the buyer, “buy from SORs” could still be the right default for SOP work, but it’s a different bet than it was in 2020. It requires the firm-specific configuration work that the 3.3% number says most buyers are skipping.

Any agentic AI product, whether SOR-native, workflow-wedge, or in-house, is fundamentally an agent harness (the orchestration layer that wraps the model: tool use, memory, control flow, error handling) + prompts (the system prompt the vendor ships defines the default behavior) + connections to your live data, sitting on top of the AI model. Companies that can unify their data and write their own harness capture the integration benefit without the vendor tax, but most aren’t equipped to do so. The judgment layer is where the four real options live.

The judgment layer: the four-option choice

The four options apply to the layer where individual judgment varies, and they have real tradeoffs. Most companies are choosing by default rather than by design.

Option 1: Every individual builds their own

Train and equip every individual to author their own AI fit on top of the model directly.

The ceiling is highest here. When it works, the user’s competitive judgment is encoded into their prompts, skills, and harness. But the floor is also punishing: most people can’t, many of those who can won’t, and most who try won’t sustain it.

I reflect on this from the microcosm of the venture industry. AI-for-VC products ship modules (sourcing, diligence, memo generation), each carrying a vendor’s out-of-the-box version of the work. Many surface “the most interesting companies of the week,” and my reaction is always the same: I don’t want your most interesting companies. I want NextView’s. Even the task of evaluating “should a partner take a look at a company”, the junior version of judgment work, encodes a firm’s specific thesis. My version of that prompt is better than any vendor’s because it incorporates how NextView thinks about early stage teams and markets, and this led us to build our own AI-assisted evaluation system at NextView. Diligence, the senior version, stays even more individual because we believe non-consensus bets benefit from individual edge.

The vendor’s value collapses to a thin layer over the CRMs partners live in (Affinity, Attio), and the question becomes obvious: if I can iterate on a prompt directly, what am I paying the vendor for?

Venture sits at the extreme end of the judgment-variance spectrum. Most categories live closer to the middle, and that’s where the other three options become the real choice.

Option 2: Build the internal substrate

Ramp built its own internal substrate so individual judgment authoring could happen on top of unified company data. As Ramp’s CPO Geoff Charles shared: AI usage up 6,300% YoY; 99.5% of the team active on AI tools; 1,500+ apps shipped in six weeks across 800+ builders.

Ramp’s setup has three components: Glass, an internal version of Claude Cowork, authenticates 30+ tools (Salesforce, Snowflake, Slack, Notion, Google Workspace, Figma) through one Okta SSO; a team of four built it in under three months. The internal skills marketplace, Dojo, hosts 350+ shared skills. The home-built coding agent, Ramp Inspect, now powers 12% of human-initiated PRs to production from non-engineers.

Ramp’s substrate captures SOR-grade integration benefits at the company level while preserving the per-individual judgment authoring layer through Dojo. The two-option default is pay-vendor-tax-to-SORs or fragmented-per-individual-chaos. Ramp figured out a third path.

This option is only available to companies that can afford to build it. Ramp’s culture (speed, initiative, leadership backing bold bets) preceded the AI strategy; there was no plan and no formal change management. Copying the playbook without the culture would most definitely mean disappointment.

Option 3: Forward-deployed humans

A class of people who deploy the personalization for each company: consultants, internal AI engineers, the next Palantir, and increasingly the AI product vendors themselves.

Why this exists structurally: company A’s SOPs, data sources, and judgment patterns aren’t company B’s, even when the surface workflow looks identical. Both do “lead scoring” but use different fields, different definitions of “qualified,” different escalation paths. Forward deployment is a way to connect an agentic system to a specific company’s eighteen-step version of the work.

For some AI vendors, forward deployment is becoming inevitable rather than optional: without it, the product doesn’t get used well enough to deliver real productivity and ROI. This is also where the pricing pivot lives. A vendor who ships a forward deploy engineer (FDE) alongside the product might have more success charging against labor-cost displacement rather than per-seat economics, if the combo can more effectively demonstrate true labor substitution.

The economics are harder than the Palantir mythology suggests. AI FDE talent is scarce, and playbook compounding can be slower than expected because every customer’s setup is genuinely different. The reusable scaffolding is mostly observability and eval harness, and that scaffolding plus the playbook is the vendor moat.

Option 4: Accept the layer stays manual

Accepting that most judgment work will stay manual is the easy default, and the de facto outcome when companies don’t make the choice. It preserves human bandwidth for non-codifiable judgment, at the cost of the leverage you don’t capture.

Most companies are choosing this option implicitly, not because they evaluated it, but because the other three feel too hard. That’s fine for some companies. As a default for all of them, it’s a mistake: the non-consensus frontier doesn’t sit still. As competitors author the layer, yesterday’s competitive judgment drifts into today’s table stakes, and the holdouts find that the bar moved while they were standing still.

What’s under-built: Option 2 productized

The most interesting startup wedge in the grid is the missing one: helping companies that can’t build a Ramp-grade platform reach something useful. Multiple shapes are emerging. Dust is productizing the company-wide substrate (skills marketplace plus connectors). A different cut targets the individual layer: helping enterprise employees author better prompts in the AI tools their company already bought, which is the missing UX between “we paid for Copilot” and “anyone actually used it well.” Different attacks on the same problem.

Microsoft Copilot Studio, Google Agentspace, Salesforce’s Agentforce Studio, and Workday’s Sana (acquired in 2025, itself a signal that incumbents are buying the wedge before startups can establish it) are racing to own the company-wide version, with data and distribution on their side. Their products are organized around admin-side configuration: one admin sets up the agents, everyone uses them. The startup wedge inverts that model: per-customer authoring UX where the end user is the author, not the admin.

The un-productizable variable is what made Ramp’s culture work. Productized versions can sell the infrastructure or the UX. They can’t sell the culture.

What this means

The four options at a glance:

For founders trying to capture value, the un-portable nature of individual context is the constraint, not the moat. The moats live in the scaffolding: the parts that DO scale across customers. Forward deployment with reusable playbooks charges against labor-cost displacement. Internal-substrate-as-a-service sells the infrastructure that per-customer authoring sits on top of. Both accept that the authoring layer is per-customer and capture value on the parts that travel.

What’s exposed: generic AI tooling that has none of the three structural moats — no first-party data (the SOR play), no workflow lock-in (the wedge play), no forward-deployment motion (the personalization play). Those products will keep showing 3.3% adoption.

Choose for each layer

The “Claude Code changes everything” claim is true, but the implications people are drawing from it are wrong: it changes everything for the layer of work where individual judgment varies, when the user authors the fit. The SOP layer is a different decision with a different right answer.

Most companies aren’t deciding which of the two decisions to make differently. They’re letting both default into “buy SOR,” which underserves the judgment layer, or letting both default into “let individuals figure it out,” which wastes the SOP layer’s leverage. The unlock is choosing for each layer deliberately.

Looking at your own work: which parts could an AI vendor actually ship for you, and which parts would you have to author yourself?

Previously in Ground Truth: The Structural Divide (the org-scale gap between AI capability and organizational reality) · The Consensus Machine (why consensus work automates and judgment is the scarce input)

The Input-Metric Bubble

Uber’s CTO Praveen Neppalli Naga told The Information this month that “I’m back to the drawing board, because the budget I thought I would need is blown away already.” Three months into 2026, it had maxed out its full year AI budget.

Meta runs an internal leaderboard called “Claudeonomics“ that ranks 85,000 employees by token consumption, with titles like “Token Legend” and “Cache Wizard.” The dashboard came down two days after the story broke, but we can assume that the incentive structure underneath did not. Keith Rabois, on Lenny’s podcast the same week, offered a corollary from outside engineering: “What I’ve noticed in some of the best organizations is the number one consumer of tokens is the CMO.”

Goldman Sachs circulated an industry inference-cost datapoint the same week: “We heard one industry datapoint on inference costs in engineering now approaching about 10% of headcount cost, but could be on track to be on par with headcount costs in the next several quarters.”

Anthropic is eliminating bundled token allowances on Claude Enterprise seats: enterprises keep the $20/user base fee but now pay metered API usage on top instead of getting a token allowance included. For heavy Claude Enterprise customers, the bundled allowance was already a thin wrapper over actual consumption. The bundled-seat abstraction that briefly hid AI’s token economics from enterprise buyers is unwinding from the supply side.

On the demand side, most organizations are still fighting the first battle: getting their workforces to use AI and trying to move them from Level 1 to Level 4. Leaderboards and aggressive budgets are rational responses to that phase. Box CEO Aaron Levie captured the posture on the a16z podcast last week: “we should probably waste a lot of tokens because that means that we’re trying new things.”

The Input-Metric Bubble: when a breakthrough resource works too well, the input metrics we built to govern it (tokens consumed, prescriptions written, seats activated) start behaving like a currency that just hit hyperinflation. The numbers go up fast while the correlation with useful output falls apart.

Subscribe now

What GLP-1 Already Taught Us

GLP-1 deployment in the American healthcare system already ran a version of this experiment. The drugs work as prescribed, producing real weight loss and related health improvements, and unmanaged deployment still broke budgets everywhere it landed.

The North Carolina State Health Plan ended GLP-1 coverage for weight loss in April 2024 after projected drug spend hit $1 billion over six years. Ascension dropped coverage for its 139,000 employees the year before; Idaho followed. Mercer’s 2025 survey found 77% of large employers now call managing GLP-1 costs “extremely or very important.”

The outcome data came in parallel. Across trials and real-world studies, the GLP-1 benefits largely evaporated when patients stopped taking them or used them without wraparound support. Prescribing freely and measuring by prescription volume produced a predictable pattern: exploding budgets, middling outcomes, and benefits that didn’t persist unless deployment was actively managed.

The industry’s response was managed deployment. A health policy institute’s 2025 framework structured GLP-1 coverage into managed stages (starting, sustaining, winding down), with lifestyle programs and adherence support built into each. HIT Consultant’s summary: “Stop paying for activity and start paying for results.”

Outcome evidence on managed GLP-1 programs is still thin (most data comes from vendors, not independent trials). But the cost framing flipped. Duke’s Sanford School put it carefully in its 1.4 million-veteran study: “These medications deliver real health benefits, but policymakers should be cautious about assuming they will immediately pay for themselves.”

Why Cost Optimization Is a Trap Thesis

The instinct looking at the current moment is to build the cost-control layer for AI. The cloud era already ran this experiment.

CloudHealth raised roughly $85M and sold to VMware in 2018 for over $500M; the product is now an “odd duck” under Broadcom, distributed through a single channel partner. Spotinst (Spot.io) raised $52M and sold to NetApp in 2020 for $450M. NetApp divested it to Flexera in March 2025 for $100M, a roughly 78% markdown in under five years. Cloudability was absorbed into Apptio in 2019. Turbonomic sold to IBM for $1.83B as AIOps (AI-driven IT operations). Apptio itself went to IBM in 2023 for $4.6B, but as Technology Business Management, a broader category.

None of the major cloud cost-optimization companies reached enduring category-defining scale. Value migrated three ways: up into broader categories (TBM, AIOps, observability platforms like Datadog’s Cloud Cost Management module), down into free native tooling from the hyperscalers themselves (AWS Cost Explorer, Azure Cost Management), and sideways into a discipline called FinOps (cloud-spend financial operations).

FinOps won because it is a discipline, not a category: a way of aligning engineering, finance, and procurement around whether the spend is producing useful output. Gartner has since called for organizations to further consolidate FinOps with software asset management.

Token prices are commoditizing on the same curve cloud compute did. A cost-control layer for AI gets absorbed into something bigger. The middle layer disappears as the underlying resource gets cheap.

Outcome Optimization Is Where Value Accrues

What compounds is the layer that manages deployment for outcomes, not spend for cost: which units of work are actually earning their tokens, and what judgment is embedded in each automated workflow. The gap between managed and unmanaged deployment persists regardless of unit cost, because the gap is about judgment —what’s worth automating, and what “better” means in this company’s specific context.

In The Consensus Machine, I argued that value moves from consensus work (pattern-following, measurable by inputs) to non-consensus judgment as AI automates the former. Input-metric bubbles pop because input metrics are the definition of consensus work. Outcome metrics live upstream, in the judgment layer.

Form Health, one of NextView’s portfolio companies, is building a version of this pattern on the GLP-1 side. Its employer program pairs GLP-1 prescriptions with obesity-medicine physicians, registered dietitians, and structured behavioral protocols. The thesis: managed deployment beats drug-alone on both patient outcomes and employer economics. Form Health reports 16% average weight loss at 18 months, with 17% of patients dropping other medications as underlying health improves. Employers see a 3-5x ROI through better medication selection, stronger adherence, and lower downstream prescription load.

Managed AI is the same bet on the token side: prior-authorization-style gates on which workflows earn agents, adherence monitoring on whether those agents are actually shipping better output, and a willingness to pull agents off work that isn’t paying its way. The exercise is continuous as the line between consensus work (where tokens win) and non-consensus work (where human judgment still wins) keeps moving. It won’t be a dashboard telling a CFO which team used the most tokens this month.

The Capacity Zigzag

Anthropic preferred renting compute across multiple cloud providers through most of 2025 rather than match OpenAI’s $500B Stargate commitment. That changed in November, with a $50B Fluidstack data center build and a Microsoft + NVIDIA partnership that included a $30B Anthropic commitment to Azure compute, announced within a week. Ben Thompson’s April Stratechery piece summarizes where this leaves them: “Anthropic is already short on compute serving its current models… not a marginal cost problem, but an opportunity cost problem: where to allocate its compute.”

Dario Amodei, in his February Dwarkesh interview, described the underlying sizing problem directly: “You have this hellish demand prediction problem when you’re buying the next year of compute and you might guess under and be very profitable but have no compute for research. Or you might guess over and you are not profitable. … If you’re off by a couple years, that can be ruinous.” The forecasting problem means the industry will zigzag on capacity for years even as tokens and models commoditize over the long run.

Frontier models are different near-term. Labs balance their own opportunity cost against capacity buildout, so frontier access stays rationed and per-token prices probably don’t drop — they may even rise. Total enterprise spend keeps climbing anyway as adoption grows. Managed deployment becomes an operational necessity.

2026 Is a Regrouping Year

The cloud era in 2018 and GLP-1 in 2024 both produced the same shape: a breakthrough resource works so well that unmanaged deployment explodes budgets, the first wave of startups tries to build cost-control middleware, and the durable companies are the ones that managed for outcomes. Coding agents are now in this arc. The first wave is the cost framing: “how do we rein this in?” The second wave will be the allocation framing: “which units of work are actually earning their tokens, and how do we keep assigning them correctly as the line between consensus and non-consensus keeps moving?”

Uber’s CTO at the drawing board is the first named face on the first wave. The question for the next twelve months is what Managed AI looks like inside a specific business: which workflows deserve wraparound care, and which inputs will turn out to have been the wrong thing to measure. The ones still selling spend discipline will look a lot like NetApp’s 78% markdown on Spot.

Previously in Ground Truth: The Consensus Machine (consensus work automates; value accrues to non-consensus judgment) · The Judgment Layer (what compounds in an agentic stack)

One of the most compelling narratives in AI right now is the self-improving agent/system: point it at an outcome, give it a feedback loop, let it compound. A viral article from a former Cruise engineer captures the vision cleanly, and his own case study reveals exactly where it stops. What you do with that boundary turns out to matter more than where it is.

“AI systems went from completing sentences to completing KPIs.” That’s how Nicholas Charriere, who spent four years building self-driving systems at Cruise before founding Mocha, describes the shift in “The Great Convergence.” Every AI company is converging on the same architecture, he argues: self-improving agents that do knowledge work. Give an agent an outcome and the tools it needs. Let it loop. “The companies that own more of that loop will improve faster and their progress will compound.”

In Who Captures the Value?, I wrote about what happens when execution costs trend toward zero: value migrates to verification. But that assumed someone could eventually check whether the output was correct. What happens when the feedback loop takes over a decade to close, and every iteration is an irreversible bet?

Cruise’s continuously learning machine stopped at the last mile

At Cruise, the engineering north star was a Continuously Learning Machine: drive, collect data, retrain the model, deploy, on an ever-tightening loop. In four years, they compressed the deployment cycle from quarterly to weekly, real improvement by any measure.

But the machine stopped short of its own ambition. Charriere admits it plainly: “This was of course never quite achieved, there were always humans in the loop.” Humans steered at “the highest leverage areas: tough labeling, model tuning, deploy decision.”

The verifiable parts of the system converged as the thesis predicts. Data collection, model retraining, and deployment cadence all compressed toward routine. But the last mile stayed human: hard labeling edge cases, safety thresholds, whether to deploy on a given release. Simulation environments and synthetic data are active research areas in autonomous vehicles, but the feedback signal for “correct” on those decisions doesn’t resolve fast enough within real-world deployment timelines to train against.

Subscribe now

The Judgment Layer

Most decisions that feel like pure judgment are actually bundles of verifiable sub-decisions plus a smaller layer of irreducible judgment. The hard skill is unbundling correctly. The Judgment Layer is the irreducible residue after you’ve automated everything that has a feedback loop fast enough to learn from.

Early-stage investing shows the pattern cleanly as I reflect on my experience over the past decade. Competitive landscape mapping, financial modeling, traction metrics: all verifiable. My partners and I can (and increasingly do) automate these leveraging AI. Founder-market fit, market timing, and conviction on a bet that takes over a decade to resolve: judgment.

Even “verifiable” sub-decisions are less clean than they look. Market sizing seems straightforward, but sizing the right market (especially for early-stage startups) is trickier than you’d expect. In 2014, NYU professor Aswath Damodaran valued Uber at $5.9 billion by sizing the market against taxis and black cars. Bill Gurley of Benchmark responded that the real market was all personal transportation, potentially 25x larger. Same company, same data available, completely different conclusion. The calculation is verifiable, but the choice of what to calculate is not.

The story around one of NextView’s earliest funds makes this concrete. My partners set the deliberate strategy of systematically evaluating performance across 30 portfolio companies and concentrated follow-on capital into the top four. Only one of these investments truly outperformed. But the judgment layer wasn’t which four to pick — it was the strategy of whether to double down at all. They understood power law dynamics well enough to know that in venture, a single winner can drive an entire fund’s returns. Without that concentration decision, the one company that did work wouldn’t have had enough capital behind it to matter. You can argue that the evaluation exercise was verifiable, but the conviction to concentrate was judgment.

The verifiable layer converges. The thin layer above it determines whether any of it is pointed in the right direction.

Where the self-improving loop breaks

Take the “Software Factory,” a three-person AI team formed inside StrongDM (an enterprise security/infra company) last July with an extreme founding mandate: no code written by humans, no code reviewed by humans. Developer Simon Willison wrote about it in February after visiting and seeing working demos. Their approach: let coding agents write and test software against “Digital Twin Universe” clones of the services it depends on (Okta, Slack, Google Docs), running scenarios at volumes far exceeding what’s possible against live services. It’s early (the team had only been running for three months when Willison visited) and expensive, at roughly $1,000 per engineer per day in token costs. But it’s one of the clearest working attempts at what Charriere describes.

This works because coding has something rare: a fast, clear definition of “correct.” Write a test spec, run the code against it, see if it passes. Define the KPI, build the loop, let it run.

But try applying “build once, runs forever” to “should we invest in this founder?” or “is this the right strategy?” The feedback loop can’t close because the signal for “correct” doesn’t arrive within a useful timeframe. The system can execute faster, but it can’t judge better when there’s nothing to judge against yet.

And even within the verifiable layer, individually correct sub-decisions can compound into a direction nobody intended. Each market-sizing model is defensible on its own term. Each competitive analysis checks out. But the accumulated weight of those analyses can drift the overall thesis without any single KPI flagging the shift. The signal is indirect: you notice the overall thesis has moved but can’t point to the specific decision that moved it. Only someone holding the full context catches that drift before it compounds wrongly.

The three layers — and why judgment sits on top

Who Captures the Value? mapped two layers of the value stack: execution (trending toward zero) and verification (the scarce complement). This post adds a third:

Most important decisions span all three layers simultaneously. A single investment decision involves execution (building the financial model), verification (checking the model against reality), and judgment (whether the market timing is right for this founder). The skill isn’t choosing which layer you’re in. It’s unbundling a decision into its components and treating each one appropriately.

The design skill: compound what you can, own what you can’t

The convergence thesis is right about the verifiable layers. The Software Factory experiment is already showing what this looks like in practice. Many companies are racing to experiment with building self-improving loops as the next frontier to unlock AI productivity.

The piece it leaves room for is the design skill — and it’s a practice, not a one-time architectural decision. What it looks like day to day is a question you keep asking: which parts of my work do I actually need to be the one deciding? The answer changes as the automated layer gets better. The question stays the same.

What’s a decision in your work that felt like pure judgment the first time you made it — but got more systematic the more you did it?

Thanks to my partner David Beisel for helping pressure-test the investing sections of this piece.

The most capable AI working environment right was originally built for software engineers, and knowledge workers adopted it anyway. The individual productivity is real, but the moment two people need to collaborate on something, they’re back to copy-paste. The multiplayer layer doesn’t exist yet, and whoever builds it will define how knowledge workers collaborate for the next decade.

I’m working with one of my partners at NextView on a strategy document. My setup: Claude Code connected to my call notes, prior research, and months of accumulated context. It produces a structured analysis with tables and recommendations, saved as a local file on my machine. For individual work, it’s amazing.

Then I need to share it. There are protocols (the most prominent one is called MCP, Model Context Protocol) that let an AI agent interact with other software, but the collaboration tools of the last decade weren’t built for agents. Claude can read a Google Doc through MCP, but it can’t write to one. So instead, I copy the whole thing and paste it into a Google Doc. My partner reads it, adds comments, restructures a section, writes in his own analysis.

Now I need to bring his changes back. Claude can pull in his edits from the Google Doc as context, but it still can’t write back to it. So I iterate locally, incorporating his feedback and extending the analysis with new material Claude surfaces. We go back and forth like this, local file to Google Doc, Google Doc to local file, with copy-paste as the bridge.

The alternative is a shared GitHub repository. Clone, branch, commit, push (the full engineering workflow) to collaborate on a document. When I was describing this setup to a friend, she jokingly suggested what we need is “MarkdownHub.” This is single-player mode: the best AI working environment I’ve used, and the collaboration workflow is copy-paste.

The accidental operating system

Claude Code was designed as a coding agent for software engineers. It lives on your computer, can read and write files, run commands, remember context across sessions, and connect to external tools through MCP. It’s a command-line tool (CLI), meaning you interact with it by typing rather than clicking, natural for developers, unfamiliar for everyone else. Then non-engineers discovered it was the most productive way to work with AI.

At our five-person partnership at NextView, four of us now use either Claude Code or Cowork (Anthropic’s point-and-click version for non-developers) daily. We use it for diligence, market analysis, deal memo drafting, strategic planning, work that most of the time has nothing to do with writing code. Each person builds their own local setup, connects their own MCPs, accumulates their own context. For one person at a time, it’s an extremely powerful setup.

The numbers suggest this isn’t niche. Anthropic’s CCO has told Bloomberg that Cowork will reach “a wider market than Claude Code,” tens of millions of developers versus hundreds of millions of knowledge workers. What started as a developer tool is becoming an operating system for knowledge work.

Because it was built for engineers, file-based markdown became the default artifact format. Non-engineers adopted markdown because it’s what works with agents. Nobody chose it as the collaboration medium for day-to-day knowledge work; the tooling chose it for them. And markdown files live in repositories, which means collaboration requires git, a version control system designed for software, not for two people who want to edit a document together. Real-time collaboration and version control are hard to do together, and nobody has solved both in a single tool that agents can participate in.

Subscribe now

What’s actually missing

Git and GitHub have versioning and collaboration infrastructure, but they’re designed for code. Clone, branch, commit, push, pull requests, merge conflicts, and explaining what a branch is, all to do what should be “let’s both work on this.” But git is also load-bearing: agents need the ability to revert anything, and that safety net matters.

Of course, real-time document collaboration exists (Google Docs does this well), but agents can’t meaningfully participate. The most common Google Drive MCP is read-only for Docs. You can update a spreadsheet cell-by-cell, but you can’t touch a Google Doc.1 It’s a human collaboration tool that structurally excludes agents.

Proof, from the team at Every, is tackling the document layer: an agent-native markdown editor with provenance tracking and an open-source SDK. But it solves one document at a time.

The project layer — where multiple people, each working through their own agent, need to collaborate on shared work and bring results back into their own environments — is where the gap gets structural. The startups building here are well-funded, but they’re all building for engineering tasks.2 Non-code knowledge work teams have zero purpose-built infrastructure for working together through agents.

Anthropic is racing to become the Microsoft Office of the agent era

Cowork is Anthropic’s attempt to bring Claude Code’s capabilities to non-developers. Under the hood, it runs the same engine as Claude Code in a virtual machine, but wraps it in a familiar point-and-click interface with built-in connectors to tools like Google Drive, Gmail, and Slack. If you squint, the trajectory looks a lot like Microsoft Office: a hub (Cowork) with integrated apps (Claude for Excel, Claude for PowerPoint), shared context across them, and a connector ecosystem (MCP) tying it to external data.3

Cowork Projects, launched in March 2026, give users persistent multi-file context. But they’re local-only. You can’t share a project with a teammate, even on the Enterprise plan. The collaborative project layer doesn’t exist yet. Anthropic is building the Word and Excel of the agent era, but not yet the SharePoint.

Google has the actual Workspace and Microsoft has Microsoft 365, both with collaboration infrastructure and distribution, but neither has made it agent-native (Microsoft’s Copilot has 3.3% paid adoption across 450 million Microsoft 365 seats). OpenAI is merging ChatGPT, its Codex coding agent, and its Atlas browser into a single desktop “super app”, killing Sora and other products its head of applications Fidji Simo called “side quests.” The move is a direct response to Anthropic gaining enterprise share. And yet the most agent-native working environment was accidentally created by a CLI tool nobody expected non-engineers to use.

The collaboration gap between human-agent pairs, where each pair has its own context and needs to work with other pairs without losing it, is the obvious next primitive.

Open protocol or closed feature

The beauty of Claude Code is that it’s a CLI tool sitting on top of your repositories. Your context, your memory, your accumulated institutional knowledge lives in files you control, and the value accrues to your own infrastructure.

The open ecosystem is powerful, but navigating it today feels like assembling your own computer from parts: you need to know which components exist, which versions are compatible, and how to wire them together. If Anthropic solves collaboration inside Cowork, that will be compelling because it’s the push-button alternative. But then your team’s shared context, your collaboration workflows, your institutional knowledge moves inside Anthropic’s product, and the gravity shifts from your infrastructure to theirs.

Anthropic’s track record here is split. MCP was donated to an independent foundation under the Linux Foundation, co-founded with Block and OpenAI, adopted by Google, Microsoft, and thousands of developers. Cowork Projects are closed: local-only, no export, no interoperability. Which philosophy wins for collaboration primitives shapes whether the next era of productivity software is open or captured.

At least four things are missing for agent-native collaboration to work, maybe more:

• Collaborating on a document shouldn’t require learning branch management. That’s a versioning problem nobody’s solved for non-code artifacts.

• Shared agent memory at the team level, not just personal (each investor’s context, the deal history, the institutional knowledge that should inform everyone’s agent).

• A way to know who wrote what, human versus agent. Agent provenance needs to be built in, not bolted on.

• Permission scoping for shared context, so that when two people’s agents contribute to a shared project, each person controls what context crosses into the shared space and what stays private. This connects directly to the problem I explored previously in The Context Gate.

Each of these could be built as an open protocol or a closed feature, and the architecture decisions being made right now will be hard to reverse.

What the workarounds reveal

When power tools get adopted by users they weren’t designed for, the workarounds are the product insight. Non-engineers using GitHub for markdown files, copy-pasting between terminals and Google Docs, teaching colleagues what “commit” means so they can collaborate on a memo. None of this is wrong. It’s what happens when the tools outrun the infrastructure that connects them.

For the small number of people who’ve built deep agent setups, individual productivity is transformative. But the moment you need to work with another person who has their own agent and their own context, you’re back in “MarkdownHub,” toggling between a terminal and a Google Doc. Every one of these workarounds is a spec for what the next tool needs to do, and whoever reads these workarounds correctly builds the next platform.

How does your team handle it when one person’s AI-produced work needs to become another person’s AI-assisted project?

2025 gave us the first real glimpse of an agentic future — AI that doesn’t just answer questions but acts on your behalf. In 2026, with frameworks like OpenClaw and Claude Code going mainstream, the promise is bigger: teams of AI agents running serious operations and managing workflows. However, there’s an unnamed problem blocking multi-agent systems from fulfilling that promise — and it has nothing to do with what agents can do. It’s about what they know.

A few weeks ago, I set up an always-on AI agent as my chief of staff — one that runs in the background, monitors my industry, tracks signals, and surfaces insights while I’m working from my phone. It has a ton of context on me: how I work, my preferences, and what I’m looking for. That’s what makes it useful. (I built it on OpenClaw, an open-source framework for self-hosted AI agents.)

One of the things I wanted it to do was monitor a dynamic X feed — a curated, real-time stream of the market conversations that matter to my work. So I considered giving the agent its own X account to generate a personalized algorithmic feed tuned to what we want to track.

The agent is helpful precisely because it has so much context on me, much of which I wouldn’t share publicly. I can govern its behavior with configuration files — rules about confidentiality and guardrails on disclosure. The issue is, those governance layers only work most of the time. There’s nothing that mechanically stops the agent from saying something that inadvertently reveals what I’d consider confidential. The information leaks through what the agent knows, and no amount of instruction-following can guarantee it won’t surface.

I shelved the idea. The technology could handle it — I couldn’t trust the information boundary. I’d hit the Context Gate.

Previously in Ground Truth: The Trust-Utility Curve explored the direct relationship between how much access you grant an AI agent and how much value you get back. More trust, more utility. This post examines what happens when that curve hits a wall — when the access an agent needs to be useful is exactly what makes it dangerous.

The action layer is getting solved. The knowledge layer isn’t.

The agent security industry is booming — dozens of startups, several major acquisitions in 2025, and hundreds of millions in funding, all focused on the same layer: controlling what agents can do. Which APIs can they access? Which databases can they query? Which tools can they use? These are solvable problems with clear answers.1 Google’s A2A and Anthropic’s MCP (a new standard for connecting AI tools to each other) are standardizing how agents authenticate and communicate.

All of it solves the same problem: what can an agent do? You can write a rule, test it, and prove it works.

Almost nobody is solving the other problem: what does an agent know?

When a “boss” agent with sensitive context delegates a task to a sub-agent — one that talks to external APIs or interacts with other people’s agents — sensitive context can leak through the delegation. The leak doesn’t require a security breach. It happens through the content of perfectly authorized actions.

This is the Context Gate — the missing infrastructure between what an agent is allowed to do and what it should know while doing it. Action permissions can be solved with rules, but context permissions resist rule-based solutions entirely. Models have gotten much better at following confidentiality instructions — the best ones now leak directly less than 4% of the time. But that improvement is misleading. When agents hand off tasks to other agents, total information exposure rises to 69% — the leakage just moves to channels nobody’s monitoring.2 Something even more striking: models can correctly identify what’s private and still leak it when executing tasks. The knowledge doesn’t escape through what agents say — it escapes through what they do.

Subscribe now

The delegation problem

If you use one AI assistant today, the near future is a team of them — one researching, one writing, one sending emails — coordinating on your behalf. This is already how complex agent work gets done: orchestrator agents that delegate specialized tasks to sub-agents.

Each delegation is a context boundary. And at each boundary, someone has to decide: what does the sub-agent need to know?

Agent frameworks are the operating systems developers use to build AI agents. I checked how the seven biggest ones handle information sharing between agents:

If you’re not a developer, the takeaway is simple: none of these frameworks solve the problem. Some have tried — OpenAI’s Agents SDK has the most developed filtering, LangGraph offers declarative type annotations, even OpenClaw has opt-in agent messaging. But every attempt operates at the raw message or state-key level. None filter at the semantic level. You can strip a message from the handoff. You can’t prevent a concept from leaking through. There’s no production system that lets you say “pass this task to the sub-agent, give it market data but not portfolio positions, and ensure its output doesn’t implicitly reveal the portfolio positions it never saw.”

My X account problem is a miniature version of this: one agent with full context and ability to communicate externally.

Context isolation works — until agents need to collaborate

I was talking about this recently with Mitali Pattnaik, a veteran product leader (LinkedIn, early Twitter) who’s now a Partner at Keywork — an investment firm that backs real-economy businesses and builds an AI operating layer for its portfolio. She’s hitting the same design wall from a different angle. Her approach: each agent would operate a single persona with a single identity on X — e.g. “I’m a roofer.” “I’m an HVAC specialist.” Each agent knows only what that persona needs to know and nothing else. No filtering needed at the boundary because there’s nothing dangerous in the context to begin with.

For my X account, the answer would be: spin up a separate agent that knows only market themes, sectors to watch, types of conversations to track, and nothing else. The problem comes the moment agents need to collaborate: if my investment focus shifts, I want the chief of staff to redirect what the X agent tracks. That redirection requires passing context across the boundary — and there’s nothing mechanically stopping the chief of staff from including sensitive information in that handoff. You can write rules about what should and shouldn’t flow. You cannot enforce them at the architecture level.

You could make the collaboration rigid — the X agent only writes to files, never receives direction from the chief of staff. But then you’ve given up the whole point of having coordinated agents. And multiply this design problem by 50 agents in a business setting. Each one needs manually designed scope, documentation, versioning, review. The single point of failure is the human designer who has to get every boundary right and keep them current as the business evolves. At that point you don’t have a security model — you have an operational liability.

The security industry has a blind spot

Thousands of developers are building on agent frameworks, and many of them are trying to do exactly what I described — coordinate multiple agents on tasks that involve sensitive context. The industry hasn’t converged on a name for the problem, let alone a solution.

Researchers have been measuring this, benchmarking it, and formalizing why it’s hard. But look at how the industry itself frames agent security: the leading frameworks catalog over a dozen ways agents can go wrong — and all of them are about what agents do, not what they know. None address what happens when an agent’s knowledge leaks through perfectly authorized actions. Bessemer’s 2026 agent security report maps the entire landscape without mentioning it. There’s no product category for this problem, and no line item in any security budget.

Action permissions are verifiable and deterministic. Did the agent call the forbidden API? Check the logs. Was it authorized? Check the policy. This fits cleanly into the security industry’s mental model, every compliance framework, and regulatory requirements like the EU AI Act (most provisions applicable August 2026). Context leakage is probabilistic and implicit. An agent sends a perfectly authorized email on your behalf, but the way it phrases a question reveals a strategic priority it shouldn’t have known about. Security teams don’t have a mental model for it, and compliance frameworks don’t have a checkbox for it.

Earlier this week, former Atlassian CTO Sri Viswanath raised a $65M seed round for Sycamore, an “agentic operating system” built on a trust-earning model — agents start monitored and gradually gain autonomy as they prove reliable. It’s an impressive approach to behavioral trust. But an agent can be perfectly reliable at its task and still leak context through the content of its actions. Behavioral trust and informational trust are different problems.

Meanwhile, the perception that multi-agent orchestration is ready for enterprise has outrun the reality. The demos are impressive and the frameworks are maturing, but we are not yet seeing widespread deployments across serious enterprise use cases (the “I run my entire agency business with these twenty agents” claims on X notwithstanding). I wrote in The Structural Divide about the gap between AI capability and enterprise deployment. The Context Gate is another reason that such divide persists.

The trust layer that’s missing

In the early 1990s, e-commerce couldn’t scale. Browsers had no encryption. Some early merchants accepted credit card numbers via email — it worked, technically. What unlocked the market wasn’t better shopping experiences — it was HTTPS, a trust layer for the channel.

AI agents face the same constraint. The capability is there, but it can’t scale past demos until there’s a trust layer for context. This one will be harder than HTTPS — context gating is probabilistic, not a clean protocol — and the solution likely isn’t purely technical either. The systems that have historically scaled trust — identity, relationships, brand, reputation — are product and distribution problems, not protocol problems. But the business constraint is the same: capability without trust doesn’t scale.

Developers are running agents with full context access right now — the 2026 equivalent of emailing credit card numbers. When it goes wrong, the damage is leaked PII, lost trust, or a relationship you can’t repair.

What comes next

A few companies are starting to work on adjacent problems3. These address data protection at the agent level — but the semantic leakage that occurs when agents delegate to and collaborate with other agents remains largely unsolved.

Just last week, OpenClaw announced a new integration that lets any connected AI tool send messages through your Slack, Telegram, or email in a single step.4 This makes multi-agent coordination dramatically easier. It also means any authorized AI tool can now communicate outward on your behalf — carrying whatever context it has.

The Context Gate is open when you work alone, with your own agent, on your own data. The moment agents collaborate or act externally, the gate closes — and right now, nobody’s building the hinges.

If you’ve ever hesitated to let an AI agent send an email, post content, or interact with a customer on your behalf — not because it couldn’t do the task well enough, but because of what it might reveal — I’d love to hear the story. How are you handling what your agents know while they act in the world?

Vera on our Platform team at NextView just solved a problem we’d been ineffective at solving for years.

The problem: making sure that every person any partner meets gets properly cataloged in our CRM so we can invite them to future events. Five partners, hundreds of meetings a month, contacts scattered across calendars. We’d tried to fix this with manual processes, reminders, periodic cleanups. Nothing stuck.

Vera’s background is in program management and operations. She has never written code before. She used Claude Cowork (Anthropic’s non-technical counterpart to Claude Code — an agent in the desktop app, no terminal required).

She built an automated system that pulls from each partner’s Google Calendar, cross-references contacts against our Affinity CRM, filters out portfolio founders and internal team members, and populates a personalized review list for each partner — delivered to their inbox every week. About 1,100 lines of Python across four modules. I reviewed the code and had three items to fix, none major.

If people who were never trained as engineers can now build production systems that solve real operational problems, who captures the value?

The printing press didn’t create faster scribes

Boris Cherny, who leads Claude Code at Anthropic, made a point on Lenny’s Podcast that reframes the whole conversation: coding agents aren’t making engineers faster. They’re making the scribes’ bottleneck irrelevant.

The printing press didn’t create better scribes — it made a completely new class of person (publishers, pamphleteers, scientists who could distribute findings) relevant for the first time. The scribes’ productivity gains turned out to be a footnote; the Renaissance was the headline.

Coding agents are doing the same thing. The story isn’t “engineers ship 10x faster” — although that’s happening. The story is that Vera just built a production system that solved a problem our firm had been failing at for years. The bottleneck that kept her out wasn’t talent or judgment — she understood the problem better than anyone. It was the craft of translating that understanding into code. That bottleneck is disappearing.

The intuitive conclusion is that everyone wins — but that’s not what history shows.

Subscribe now

The fault line isn’t complexity — it’s verifiability

Everyone’s saying value shifts to taste, curation, judgment, agency, “the human touch.” These concepts are not wrong — but as economist Christian Catalini argues, they are not a strategy. They are “the names we give to the residual we haven’t yet analyzed.”

Catalini pushes further: the real boundary has nothing to do with whether work is hard or easy, creative or routine. It has everything to do with whether anyone can verify the output.

That reframe changes the question entirely. It’s not “what can AI do?” — it’s “can anyone verify that the output is correct?” And once you ask it that way, you can start to see which companies actually win.

If the output can be scored — right/wrong, pass/fail, better/worse by some objective standard — it can be automated. Not because AI is better at it, but because measurability is what makes automation work. Vera’s calendar sync works because the output is verifiable: either the contacts are in the CRM or they aren’t.

But the cost of executing work and the cost of verifying it are racing in opposite directions. AI execution is collapsing in cost — SWE-bench accuracy went from 4.4% to 71.7% in a single year. The cost of verifying AI’s output isn’t falling at the same rate. In many domains, it’s rising — because there’s more AI-generated output to verify, and fewer experienced humans to verify it.

Catalini calls the space between these curves the Measurability Gap. Where automation is cheap AND verification is affordable — chat, images, short code bursts, data entry — value has already migrated. These are the consensus units from The Consensus Machine.

Where automation is cheap BUT verification is expensive — that’s where the structural danger lives. The agent can produce the output. Nobody can affordably confirm the output is correct.

We don’t have to theorize about what this looks like. It happened this month.

What happens without verification

Last week, The Information reported that an AI agent inside Meta triggered what the company classified as a Sev 1 security alert — its second-highest severity tier. An engineer had enlisted an AI agent to analyze a technical question on an internal forum. The agent didn’t just analyze it — it autonomously posted its response without the engineer’s approval. The response reportedly contained flawed technical guidance that led team members to inadvertently grant broad access to sensitive company data. The exposure lasted roughly two hours before containment.

The agent passed every identity check. It had legitimate credentials. The failure wasn’t authentication — it was verification. Nobody checked whether the agent’s output was correct before it was acted upon.

Where the value is migrating

This is where most commentary stops — with the general observation that verification matters. But “value shifts to trust” doesn’t tell you which companies win.

Execution add-ons are getting commoditized first

Brian Spanswick, CIO of Cohesity — a data security firm with more than $2 billion in annual revenue and a 400-person IT department — told The Information that he’s keeping his core enterprise platforms (Salesforce, ServiceNow, Workday) for at least the next one or two years. But the automation add-ons those platforms sell on top of their core software? Those are getting replaced.

“What I’m not going to spend on is the overhead on those platforms for process automation,” Spanswick said.

He’d been considering buying ServiceNow’s IT Asset Management tool — software that automatically shuts down and decommissions company devices and accounts when employees leave. But his thinking changed after a Cohesity cybersecurity executive created a similar tool using Anthropic’s Claude Code agent in less than two days. The company is still stress-testing it, but so far it appears to be “much cheaper” than ServiceNow’s product, which can cost hundreds of dollars per user per month.

This is Vera’s story playing out at Cohesity. The execution layer — asset tracking, device decommissioning, incident flagging — is consensus work. Measurable, specifiable, automatable. The cybersecurity exec built the replacement in two days because the work had clear verification criteria: either the device got decommissioned or it didn’t.

But the platform companies aren’t dead — they’re pivoting to verification

ServiceNow’s response is telling. A spokesperson disputed the idea that its software could be replaced by vibe-coded tools, arguing that such AI replacements “typically stall” because they lack “the compliance, the integrations, the auditability that regulated enterprises actually require.”

What they’re selling right now is insurance, not verification — “if something goes wrong, you have an enterprise vendor to hold accountable.” The compliance certifications, the audit trails — these are liability shields as much as they are verification mechanisms.

But insurance buys time, and ServiceNow is using it. They’re embedding Claude as their default Build Agent model, racing to become a genuine verification and governance layer — not just the vendor you blame when something breaks, but the platform that can confirm the output is correct before it ships. That’s the pivot: from insurance to verification.

Jeff Weinstein, a partner at FJ Labs, crystallized what durable trust looks like at the other end of the spectrum. Kirkland & Ellis and other white-shoe law firms will be fine in the AI age “not because of their superior legal advice, but rather because they are a risk transfer product, not a law firm. Their key offering is CYA.” They don’t need to pivot — liability absorption is their product. For everyone else, the path is clear: insurance buys time, but verification is the destination.

Three company bets

So who actually wins? Three bets are emerging — and the verification lens tells you which ones are durable.

Bet 1: Sell the tool (copilots)

These companies sell AI tools to professionals who retain judgment and verification authority. Harvey for lawyers. EvenUp for personal injury attorneys. Abridge for doctors. The professional uses the AI to draft, summarize, or analyze — then verifies the output and takes responsibility.

Julien Bek at Sequoia recently argued that this is the “copilot” model — and it’s the one with the most structural tension. Copilots make professionals faster, but the professional remains the bottleneck. You’re selling to the person whose job you’re partially automating, which limits how aggressively you can push.

There’s a deeper problem, too. Copilots run straight into the Structural Divide: they work because individual context is manageable, but the enterprise context problem is combinatorially harder. The knowledge that makes a copilot transformative at the org level is scattered across Slack threads, email chains, and tribal knowledge that exists only in people who’ve been there for years. That context architecture simply doesn’t exist yet.

Bet 2: Sell the outcome (autopilots)

These companies skip the professional entirely and sell the verified outcome to the end customer. Bek calls this the “autopilot” model, and his key insight is that for every dollar spent on software, six dollars goes to services. The autopilot opportunity isn’t the software budget — it’s the services budget.

Crosby doesn’t sell NDA drafting tools to lawyers. It drafts the NDA. WithCoverage doesn’t sell insurance analysis tools to brokers. It provides the coverage recommendation. Rillet doesn’t sell accounting software — it does the accounting.

This is where “the next $1T company will be a software company masquerading as a services firm.” The challenge — and it’s enormous — is that autopilots must build verification internally. When there’s no professional checking the output, the company itself bears the liability. The ones that accumulate proprietary verification data in their domain — what “correct” looks like across thousands of NDAs, insurance policies, or tax filings — build a moat that compounds. Ship plausible-but-unverified output and you accumulate risk instead.

Catalini calls these companies “Liability Underwriters” — they “detect hidden risk, absorb liability, produce the ground truth that makes future automation possible.” The business model is what he calls “Software-as-Labor”: monetizing verified outcomes, not software access.

But there’s a tension Bek doesn’t address. That six-to-one ratio — six dollars of services for every dollar of software — exists because services historically required expensive humans. If autopilots undercut incumbent service firms by 20% while enjoying 95% margins, that’s a gold rush. But if fifty autopilots enter every vertical, the price collapses. The $6 service TAM itself shrinks — AI becomes deflationary for the very market it’s disrupting.

The counter: this is the Consensus Machine playing out inside each vertical. The autopilot that has verified 100,000 NDAs can push the consensus frontier in its domain — yesterday’s non-consensus legal judgment becomes today’s automatable task. The winner takes the deflated market precisely because it has compressed the most verification into its system.

Bet 3: Buy the business, keep the margin (operators)

There’s a third option: don’t buy copilot tools, don’t outsource to autopilot service firms — acquire existing businesses, deploy AI yourself, and keep the margin lift.

This is the bet that’s attracting the biggest checks. Jeff Bezos is looking to raise $100 billion for a “manufacturing transformation vehicle” — acquiring companies and upgrading them with AI. Thrive Capital launched Thrive Holdings with over $1 billion and a partnership where OpenAI researchers embed directly with acquired businesses to build customized models. General Catalyst has co-created at least ten startups buying up services companies — legal, IT, HOA management — and remaking them with AI. Lightspeed is doing the same in engineering services and healthcare. Newcomer reports that the “AI roll-up has officially gone mainstream.”

The logic is straightforward. If AI makes execution cheap, the biggest prize isn’t selling the AI — it’s owning the business where the margin lift lands. Buy an accounting firm doing $50M in revenue with 200 accountants. Deploy AI. Keep the same revenue with 60 accountants. The margin expansion accrues to the owner, not to whatever copilot or autopilot vendor you might have bought instead.

These aren’t just technology bets. They’re transformation bets — and the hard part isn’t the AI. It’s the change management, the compliance infrastructure, and the organizational trust that makes the transformation stick. The technology to automate execution already exists. What doesn’t exist is the operational playbook for deploying it into a 200-person accounting firm without breaking everything.

I’ve talked to operators who have worked inside several of these roll-ups, and the consistent message is: it’s harder than the thesis suggests. You can’t just force-feed the Silicon Valley AI adoption playbook and expect it to stick. Most workers in these acquired businesses are at Level 1 or Level 2 — single-session AI users at best. Organizations are living systems. Cut 50% of the headcount and the culture, execution rhythm, and institutional knowledge don’t stay put.

That said, there are pockets of early success stories. One healthcare services roll-up I’m tracking went from 4% EBITDA margin pre-acquisition to 10% within six months — mostly by using Claude Code to build operational automation. Nothing revolutionary: better funnel management, process streamlining, the kind of common-sense improvements that a practice operating since 1994 with bloated operational headcount had never prioritized. The margin lift came from running the business better with AI — straightforward if you have the buy-ins to execute well.

The verification tradeoff

Each bet solves the verification problem differently — and the shape of the moat depends on which solution you choose.

These aren’t rungs on a single ladder — they’re different bets on where in the verification chain you want to sit. The structural question is the same for all three: who verifies the output, and who bears the liability when it’s wrong? But the answer leads to fundamentally different businesses.

The missing junior loop

There’s one more structural risk in this transition that most people aren’t talking about. Firms are rationally thinning the pipeline that produces future verifiers at exactly the moment the economy most needs to expand verification capacity.

Catalini calls it “the Missing Junior Loop.” Employment for early-career workers in AI-exposed fields has already declined roughly 16% relative to less-exposed occupations. Not mass layoffs — frozen hiring pipelines that quietly treat AI as a substitute for junior execution.

The paradox: the junior roles being cut are the same roles that trained the next generation of people capable of verifying AI’s output. Cut the training pipeline, and you erode the future supply of the scarcest resource. The copilots, autopilots, and operators all need verifiers. Where do they come from if nobody is training them?

What this means

When a technology makes production cheap, two things happen clearly:

1. Production becomes a commodity. The people and companies whose value proposition was “we can build the thing” lose their moat. This happened to scribes, to clerical workers, to travel agents, and it’s happening now to categories of software development and knowledge work.

2. Verification becomes the scarce resource. Every wave of cheap production has created a corresponding boom in verification infrastructure — auditing, certification, regulation, quality assurance. The people and institutions who can say “this is correct, this is safe, this is compliant, I’ll stake my reputation on it” become more valuable, not less. As Catalini puts it: “Scale without verification is not a moat. It is an accumulating debt.”

As Weinstein put it: “The cost of code is trending toward zero. The cost of trust is not.” Copilots sell speed but inherit the professional’s bottleneck. Autopilots that accumulate proprietary verification data build the moat that compounds. Operators who buy the business and deploy AI themselves capture the margin that pure software companies can’t.

The question isn’t whether you can build. It’s whether anyone should trust what you’ve built — and which bet you’re making on the answer.

Everything above applies to work where someone, eventually, can check whether the output is right. But there’s a class of decisions where verification is structurally impossible — not because we lack the bandwidth, but because no framework exists to confirm whether the output is correct until years have passed. Early-stage investing, creative work, strategic bets. The economics there are completely different, and that’s where this series goes next.

Where does value concentrate in your industry as AI makes production cheap — and which bet are you making: selling the tool, selling the outcome, or deploying AI into existing businesses? I’d like to hear from people in fields I haven’t thought about.

A friend who’s a partner at another venture firm asked me recently which AI app I’d recommend. He’d been going back and forth between ChatGPT and Claude, trying a bit of Gemini, and wanted to know which one to commit to.

He’d sent me an article ranking them — feature comparisons, pricing, which one is better for what. It’s a good article. Thoughtful, well-researched, practical.

It’s also answering a question that stops mattering two levels up.

His question — “which one should I commit to?” — reveals where he is in his relationship with AI. He’s comparing products. Which chat app is best? Which one for what?

He’s not wrong. That is what AI is when you’re starting out. But the reason I struggled to answer his question isn’t that I have a complicated setup. It’s that I’ve crossed thresholds where the question itself becomes irrelevant.

The wrong scoreboard

The internet is full of AI maturity frameworks right now. You’ve probably seen them — “10 levels of AI mastery,” scored by what you’ve configured. How many plugins you’ve installed. Whether you’ve set up a custom system prompt. How many integrations you’re running.

I scored myself on one of these 10-point checklists recently, out of curiosity. I came in at 8 — “parallel sessions, orchestrator and specialist agents” — pushing into 9, where background agents run 24/7.

I’ve been through nearly every rung on that ladder. It’s measuring the wrong thing. That’s like measuring a chef by how many knives they own.

Configuration is setup cost. I wrote about this in The Trust-Utility Curve — there’s a real investment required before AI becomes useful, and most people underestimate it. But setup is the price of entry, not the thing that changes. What changes is something harder to count: how your relationship with AI shifts as you cross certain thresholds.

Ethan Mollick published a thoughtful guide to which AI to use that covers the tool landscape well — models, apps, harnesses, what each is best for. It’s a great starting point for Level 1 and 2 decisions. But it measures a different axis than what I’m describing here. Knowing which tool to pick is necessary. It’s just not what changes your relationship with AI.

What I’ve found is that there are four distinct levels. They’re not defined by what you’ve installed. They’re defined by the question you ask.

Subscribe now

Level 1: “Which AI app should I use?”

What it looks like: You use ChatGPT, Claude, or Gemini the way you used to use Google — type a question, get an answer, close the tab. Every conversation starts from zero. You’re comparing products: which one writes better emails? Which one is smarter? You might have tried a few and settled on one, or you switch between them depending on the task.

What defines this level: AI is a tool you talk to. Each session is independent. You’re the one holding all the context — your strategy, your preferences, your history — and feeding it in piecemeal every time.

Most people are here. That’s not a criticism. A year ago, this level didn’t exist for most knowledge workers. Getting here is already a meaningful shift.

The unlock to Level 2: Stop treating every conversation as a cold start. Upload your strategy document, your investment criteria, the brief you explain to every new hire. Give AI your context before you need it — not in the moment you’re asking a question, but as a foundation it can reference across conversations.

What’s waiting on the other side: AI starts catching things you miss — remembering what you told it last week, connecting dots across conversations you’ve forgotten. It stops being a search engine and starts being a colleague who’s read everything.

Level 2: “How do I make it remember my context?”

What it looks like: You’ve set up a ChatGPT Project, a Custom GPT, or a Claude Project. You’ve uploaded documents — your company strategy, your deal criteria, your product specs. You’ve probably written custom instructions. When you start a conversation, AI already knows who you are, what you’re working on, and what you care about.

What defines this level: AI is a persistent collaborator. You’re still driving — asking questions, directing the work — but the AI has enough context to push back, suggest things you didn’t ask for, and connect your current question to something you discussed three sessions ago.

My friend’s question — “which one should I commit to?” — is a Level 2 question. He wants to know which product to invest his context in. It’s the right question for where he is. The answer: at this level, it matters less than most people think. The context you bring matters more than which model you bring it to.

Previously in Ground Truth: The Trust-Utility Curve explored how AI goes from frustrating to indispensable — the setup cost is real, but the trust that builds on the other side is what changes the relationship.

The unlock to Level 3: Two things will start to frustrate you. First, the copy-paste loop — downloading AI’s output, reformatting it, uploading it somewhere else. “Why can’t this just work on my actual files?” That friction is the invitation.

Second, and less obvious: your context is frozen. You uploaded your strategy doc, but it’s already out of date. You learned something in yesterday’s session, but today’s session doesn’t know about it. At Level 2, AI can read your context but can’t update it. Each session starts roughly as smart as the last.

What’s waiting on the other side: At Level 3, the context is alive. The tools can write back into their own instructions — every mistake becomes a rule, every insight updates the system. I build custom workflows that encode what I’ve learned, so next session is smarter than this one. The system compounds. I wrote about this in Why Your 50th AI Session Isn’t Better Than Your 5th — at Level 2, it shouldn’t be. At Level 3, it has to be.

And the bottleneck shifts from “getting AI’s output into my workflow” to “deciding what to delegate.”

Level 3: “How do I get it to work on my actual files?”

What it looks like: AI operates directly on your work — your codebase, your documents, your data. You’re using tools like Claude Code, Cursor, or Codex that don’t just answer questions but make changes. (Claude Cowork is the least intimidating entry point here — it’s designed for people who aren’t engineers.) You’ve built or configured AI systems that touch your actual workflow, not a separate chat window.

What defines this level: AI is an operating system for your work. You’re delegating real tasks, reviewing AI’s output the way you’d review a junior colleague’s work, and making judgment calls about what AI can handle autonomously vs. what needs your oversight.

This is where I spend most of my days. At NextView, I prototyped an agent that systematically scans for prospects outside our existing network — getting us halfway to production with Claude Code before handing it off to an engineer. But it’s not just coding. I use it to evaluate vendor API capabilities against our roadmap priorities, build negotiation strategies, prep strategic presentations for our partner offsites, to synthesize call notes into decision-ready briefs. On weekends, I build apps for my kids (a Chinese learning app, a money management app, a Lego creation catalog) and plan family trips. Anything that takes more than a single conversation goes through Claude Code. It’s become the default environment for how I work.

The Leash Length Problem was about the management science of this level: how much slack do you give AI before you check its work? The answer, it turns out, depends on the same variables you’d use for a human employee — reversibility, stakes, and accumulated trust.

And the transitions to this level can be shockingly fast. My husband — finance background, learned Python in grad school but not an engineer by training — tried Claude Code after months as a heavy Level 2 user across ChatGPT, Gemini, and Grok. His reaction: “This is better than any banking analyst I’ve ever had.” A fellow investor friend whose early career was in marketing and comms (also not technical) went from setting up Claude Code to building two apps in a single day. In the two weeks since, she’s built five — a Doodle replacement, a multiplayer game, an interactive trip itinerary with day-by-day routes on a map. She texted me at 11:30pm after that first day: “How does anybody sleep anymore?”

They didn’t configure 30 plugins. They crossed a threshold — from AI that talks to you to AI that works on your stuff. And once you cross it, you can’t imagine going back to comparing chat apps.

The unlock to Level 4: Stop being the bottleneck for when AI can work. The question that signals you’re ready: “Does this actually need me sitting here?” When you realize you’re spending half your time waiting for AI to finish something before you can review it — and it could have run overnight — you’re at the threshold.

What’s waiting on the other side: You start evaluating AI’s judgment rather than directing every step. Your job shifts from “doing work with AI” to “designing how AI does work.” It’s the difference between driving the car and programming the route.

Level 4: “How do I let it work while I’m not here?”

What it looks like: AI agents run autonomously — monitoring, executing, and reporting back. They operate on schedules or triggers, not on your command. You review their output and refine their instructions, but the work happens whether you’re at your desk or not.

What defines this level: AI is an autonomous agent. You’re designing systems, not performing tasks. The skill isn’t prompting or even delegating — it’s designing the architecture. What should the agent care about? What tradeoffs should it make on its own? What should trigger a human review?

A friend and I have a couple of side projects we’ve been playing around with, and we thought it’d be interesting to set up an OpenClaw agent as our Chief of Staff — something that can synthesize context across two people, do research, and make progress in the background while we’re both at our day jobs. I stayed up until 11pm one Friday night to get it running on a Mac Mini, sitting in our Telegram group chat.

Same underlying model as my Claude Code setup — Claude Opus 4.6. Completely different behavior.

In the first two days, the agent gave a fake ETA on a task it was actually blocked on. It covered up a 50-minute idle period. It marked tasks “done” without proof of completion. This is the same Claude that has never once tried to cover something up in Claude Code.

Two things were different. First, the agent harness — the documents and rules that shape how the model behaves in a given tool. Claude Code and OpenClaw are designed differently, optimized for different things. My Claude Code intuitions didn’t map to how OpenClaw’s agent loop works. Second, my Claude Code setup is the product of months of accumulated learnings — every mistake becomes a rule, every session is better than the last. OpenClaw was day one. None of that institutional knowledge existed yet.

So I did what Level 3 had taught me. I decomposed the system, studied how it was designed and what made it different from Claude Code. Then I rebuilt the governance by adapting my Claude Code learnings to fit OpenClaw’s architecture — tweaking where rules needed to live, how the agent reads them, what enforcement looks like in a different harness.

A feature-counting framework would have scored me “Level 0” in OpenClaw. But what made me effective wasn’t knowing which buttons to press — it was understanding that an agent is just documents guiding a model, and knowing how to rewrite those documents when the behavior is wrong.

What separates Level 4 from Level 3 is that tool mastery doesn’t port. But pattern mastery does.

Why this matters

Understanding where you are — and where the people around you are — changes the conversation depending on who you are.

If you’re running an organization: Your people are probably scattered across all four levels. Most are at Level 1 or 2. The question isn’t “how do we adopt AI?” — it’s “where are our people right now, what does the next threshold look like for them, and how do we help them cross it?” But moving people up isn’t the only challenge. I wrote in The Structural Divide about how fragmented context infrastructure blocks AI productivity gains even when the people are ready. Both problems have to be solved together.

If you’re an individual: Most people are somewhere between Level 1 and Level 2. The question worth sitting with is: what do I have to gain from climbing? Not everyone needs to be at Level 4. But understanding what each threshold unlocks — whether that’s compounding productivity, better judgment, or business opportunities that only exist for people who’ve crossed into Level 3 or 4 — helps you decide where to invest your time.

If you’re building AI products: Which level are you building for? The answer has real product design implications. Are you competing for users who are staying at their current level, or are you the bridge that helps them cross to the next one? The products that help people cross thresholds are fundamentally different from the ones that optimize within a level.

What have you been able to unlock — personally or professionally — by moving up a level?

I’d love to hear. The unlocks are often not what you’d expect.

A few weeks ago, a Substack post helped tank the Dow 821 points.

Citrini Research published “The 2028 Global Intelligence Crisis” — a scenario where AI advances so fast that the global economy buckles under mass displacement. Fortune called it the week the AI scare turned real. Michael Bloch published “The 2028 Global Intelligence Boom” — same premise, same rigor, opposite conclusion. Will Manidis wrote “On the Garden”, a viral essay arguing through the history of Versailles and Lancelot Brown that the entire framing was wrong — that the economy isn’t a storm that happens to us but a garden tended by people making choices.

Three smart people looked at the same data and came to completely different conclusions. Citrini and Bloch both rely on single-variable extrapolation — displacement rate for one, cost deflation for the other — the pattern that has defined technology forecasting for a century. Manidis comes closest to the structural question, arguing that agency matters, that we aren’t passive recipients of technological change. But the structural question is more specific than “we have choices.” It’s about which choices, and whether organizations make them fast enough.

That question has a surprisingly clear answer in the historical record.

The Consensus Pyramid

When I say “consensus,” I don’t mean agreement. I mean the kind of work that follows established patterns — work that can be learned from existing examples and produces predictable outputs.

Summarizing a research report. Screening resumes. Matching travel itineraries to preferences. Executing a stock trade at market price. Writing a first draft of a legal brief. Generating a competitive analysis from public data.

This is the work that large language models are most reliable at producing — and that’s not incidental. It’s the fundamental mechanism. LLMs are pattern-completion engines trained on the largest corpus of human output ever assembled. The patterns that dominate that corpus are, overwhelmingly, consensus patterns. The more a task looks like something that’s been done before, the better the model performs. Every LLM is, at its core, a consensus machine.

Non-consensus work is different — the judgment call in ambiguous situations, the taste that distinguishes a good product from a forgettable one, the decision to pursue a deal everyone else passed on. And it’s something harder to name: the ability to look at discrete pieces of information and synthesize them into something none of the pieces contain on their own. Seeing the forest, not just the trees. Defining the problem, not just solving it.

Now, think of all knowledge work as a pyramid — but not as a pyramid of people. A pyramid of work.

Every person’s job is a collection of work units. Some are consensus: answering routine emails, pulling standard reports, following established processes. Some are non-consensus: making judgment calls, connecting disparate information, deciding what to prioritize. Nobody’s work is 100% one or the other.

At the bottom of the pyramid, people’s days are composed mostly of consensus units — tightly packed, pattern-following, proceduralizable. In the middle, the mix is more even, and this is where it gets most interesting: coordination, project management, translating strategy into execution. At the top, the work is mostly non-consensus — strategy, synthesis, the connective tissue that ties discrete units of information into coherent direction.

There’s a line between the consensus and non-consensus layers, and that line has always existed. What’s new is that AI is automating the consensus units — not replacing whole people, but changing the composition of everyone’s work. The consensus units get handled by machines. What’s left is the non-consensus remainder.

And that composition isn’t fixed. What counts as “non-consensus” shifts as consensus gets automated. Writing a well-structured email used to require judgment. Now it’s a prompt. The frontier moves.

The question comes down to this:

Which is faster — consensus units being automated, or humans’ ability to absorb more non-consensus work?

If automation outpaces absorption, you get Citrini’s crisis. If absorption outpaces automation, you get Bloch’s boom. The historical evidence is surprisingly clear on this. And it’s more nuanced than either camp wants to admit.

Subscribe now

The Pattern: Three Waves

We’ve seen this before. At least three times.

Electrification (1880s-1920s)

In 1899, electricity powered less than 5% of American manufacturing. By 1929, it powered roughly 75%. The consensus work it replaced was the centralized power system — belt-and-shaft factories organized around a single steam engine, where every machine’s position was dictated by proximity to the power source.

But here’s what Paul David documented in his landmark 1990 paper “The Dynamo and the Computer”: there was a 40-year lag between electrification and measurable productivity gains. The technology wasn’t slow — factory owners were. They initially just bolted electric motors onto steam-era layouts. They automated the consensus operation without redesigning the system.

The productivity surge came only in the 1920s, when a new generation of manufacturers built factories from scratch around “unit drive” — individual motors for each machine, with layouts designed for workflow, not power proximity. The non-consensus work wasn’t operating the new technology. It was reimagining the entire system around it.

The economy didn’t just absorb the disruption — it generated entirely new industries in consumer appliances, electrical engineering, industrial research, and factory design that hadn’t existed before.

Computing (1960s-1990s)

The computing wave is even more instructive, because it automated cognitive consensus work — the same category AI targets.

In the 1950s and 60s, congressional hearings and presidential commissions warned of mass unemployment from automation. In 1964, a group of prominent intellectuals — including Linus Pauling and Gunnar Myrdal — sent a memorandum to President Johnson arguing that “cybernation” would create “a system of almost unlimited productive capacity” while making most human labor unnecessary. Here’s what actually happened: clerical employment grew from roughly 2 million in 1910 to nearly 19 million by 1980, driven by expanding corporate complexity. When computers arrived, they initially intensified this expansion before eventually automating it. The inflection point — when clerical jobs peaked and started declining — didn’t come until 1980.

Since 1980, PCs and the internet have destroyed approximately 3.5 million jobs and created more than 19 million, according to McKinsey. That’s more than a 5:1 creation-to-destruction ratio. The non-consensus frontier that emerged — analysis, strategy, software development, knowledge work — was so vast it vindicated what Peter Drucker had already seen coming in 1959 when he coined the term “knowledge workers.”

But the transition was not painless. The workers displaced from middle-skill clerical roles largely didn’t become software engineers. Their children did. The transition was intergenerational, not individual. And the “hollowing out” of middle-skill work created wage polarization that persists today.

Robert Solow captured the delay in 1987: “You can see the computer age everywhere but in the productivity statistics.” It took another decade for the productivity boom to materialize.

The Internet (1990s-2010s)

The internet’s clearest case study is the stockbroker. Before online trading, executing a stock trade was consensus work: take the order, place it on the exchange, confirm the fill. The cost of a single transaction dropped 90% between 1975 and 2000.

But stockbrokers didn’t disappear. The role split. The consensus part (trade execution) was automated. The non-consensus part (financial advisory, portfolio strategy, client relationships) was elevated. Brokers who could only execute trades were displaced. Brokers who could provide judgment became more valuable.

Travel agents are the displacement case everyone cites — employment fell by more than half from its 2000 peak. But even there, the survivors moved to complex, high-judgment travel: luxury, corporate, multi-destination itineraries that require exactly the kind of taste and problem-solving AI still struggles with.

The internet went from niche to ubiquitous in roughly 10-15 years — much faster than electrification’s 40-year slog. The “painful gap” between displacement and frontier creation was shorter. But it was still painful.

The Accelerating Pattern

Here’s what the three waves tell us when you stack them up:

Three patterns hold across all three:

1. The technology initially creates MORE consensus work before automating it. Electrification needed more factory workers before it needed fewer. Computers swelled clerical employment for decades before the 1980 peak and decline. The internet created web content managers before it created platforms that eliminated them.

2. The painful gap between displacement and frontier creation shortens with each wave. From 40 years to 15-20 to 5-10. The question is whether AI’s gap will be shorter still.

3. Frontier expansion has always outpaced displacement — eventually. The 5:1 job creation ratio for computing is striking. But “eventually” matters. In any given 5-year window, the ratio could be inverted. And the new jobs weren’t always better than the old ones.

David Autor, the MIT economist whose framework for task-based labor economics undergirds much of this analysis, puts it this way: computers automated routine tasks (a closely related concept to what I’m calling consensus) and complemented non-routine tasks (non-consensus). The economy created new non-routine work faster than it automated routine work. The pyramid grew taller faster than the line moved up.

So Why Might AI Be Different?

Autor updated his framework in 2024 with a finding that challenges the limits of his own model. Previous technologies — electricity, computers, the internet — couldn’t automate non-routine cognitive work. They could automate calculations but couldn’t exercise judgment. There was a hard barrier that economists call Polanyi’s Paradox: we know more than we can tell, and if we can’t specify the rules, we can’t automate the task.

AI crosses that barrier. “If a traditional computer program is akin to a classical performer playing only the notes on the sheet music,” Autor writes, “AI is more like a jazz musician — riffing on existing melodies, taking improvisational solos and humming new tunes.”

This means AI doesn’t just automate the bottom of the pyramid. It can draft strategy memos and generate research hypotheses that are usable — not expert-level, but credible enough that the gap between AI output and human judgment is narrower than it was even a year ago.

The clean line between consensus and non-consensus starts moving in both directions — AI pushes it up from below while simultaneously reaching across it from the consensus side.

But — and this is where Citrini’s crisis scenario breaks down — the line has always been moving. What was non-consensus work yesterday becomes consensus work today. Writing a grammatically correct email used to require judgment. Operating a spreadsheet used to be specialized knowledge. Building a website used to be engineering.

The question was never “will the line move?” It was always “will the pyramid grow taller fast enough to absorb the people the line pushes out?”

The historical answer, across three waves and 140 years: yes, but not immediately, and not painlessly.

What the Consensus Machine Misses

The Citrini crisis and the Bloch boom share the same error: they treat the future as a single-variable extrapolation from the consensus layer.

Citrini’s model: AI disrupts white-collar work → consumer spending collapses → a deflationary spiral takes hold. The mechanism is more sophisticated than simple displacement math, but the underlying assumption is the same: if AI can do the work, the workers lose. It misses that every person is a mix of consensus and non-consensus work. Automating the consensus units doesn’t necessarily eliminate the person — it changes what they spend their time on.

Bloch’s model: AI deflates the cost of services → purchasing power rises → prosperity spreads. This is a straight-line extrapolation of productivity gains. It ignores the distributional question — prosperity for whom, and when? — and the painful gap between displacement and absorption.

Both treat the future as a math problem with one variable. The actual answer has two:

Speed 1: How fast does AI automate consensus work? Fast, though not frictionless. The distribution infrastructure already exists — internet, cloud, connected devices — which previous waves had to build or significantly expand. Natural language interfaces lower the adoption barrier. But two real constraints loom: energy capacity is already straining under data center expansion, and there’s genuine debate about how much further transformer-based models can improve as the most accessible training data gets exhausted. Even so, the deployment speed is unprecedented relative to any prior wave.

Speed 2: How fast does the non-consensus frontier expand? Historically, it always has — but unpredictably. Competitive dynamics force differentiation. New markets create new categories of judgment. The composition of new work matters as much as the count.

The gap between these two speeds is where the story plays out. And that gap is not a technology question. It’s an organizational question.

The Reorganization Bottleneck

Paul David’s electrification insight is the most important finding in this entire research: the 40-year productivity lag wasn’t a technology lag. It was a reorganization lag. Factories had the electric motors. They didn’t have the organizational imagination to redesign around them.

The pattern repeats today. Many large firms remain in incremental mode — automating legacy tasks instead of using AI to reimagine workflows entirely.

It’s the same mistake and the same lag, a hundred years apart. Anthropic’s own research, published last week, quantifies the contemporary version: even in occupations where AI could theoretically handle the majority of tasks, actual deployment remains a fraction of what’s technically feasible.

In Computer & Math occupations, theoretical AI capability reaches 94% — but actual deployment sits around 33%. The gap is the reorganization bottleneck.

The technology isn’t the bottleneck. The reorganization is — just as it was for electric motors. Redesign is inherently non-consensus work — it requires judgment about what the new system should look like, taste about what matters, and courage to abandon what’s working well enough.

This is what I see in my own work. At NextView, we built an agent to systematically surface and evaluate prospects outside our existing network — companies that traditional relationship-driven sourcing would miss.

What the agent handles is the consensus work of scanning: ingesting large datasets, scoring against criteria, surfacing companies worth a closer look. But here’s the design choice that matters — we intentionally calibrate for a wide net. We’d rather have false positives (borderline companies that come through for a partner to evaluate) than false negatives (non-obvious prospects that get filtered out because they don’t fit the pattern). The agent does the consensus-level labor of scanning. The non-consensus judgment — including deciding that something looks weird enough to be interesting — stays with the partners.

At a firm like ours, where we don’t have junior investment team members, the trade-off without the agent was clear: either we don’t look at prospects outside our network at all, we hire a junior team, or partners spend time on scanning that would be better spent on the work only they can do — evaluating founder judgment, stress-testing market assumptions, connecting patterns across the portfolio that no individual deal memo contains.

The three hours a partner saves aren’t gone — they’re redirected to the most irreplaceable work in the firm.

But not every version of this story plays out the same way. The same dynamic looks different depending on where you sit in the pyramid — and that’s where it gets more complicated than any single prediction captures.

Three Stories in the Pyramid

“Will AI take my job?” assumes one answer that applies to everyone. The work-composition lens reveals at least three different stories playing out simultaneously.

The bottom: displacement and liberation

For people whose days are composed almost entirely of consensus units — data entry, routine processing, standard report generation — AI automation is genuinely a displacement story. Not because these people lack value, but because the work they were hired to do is exactly what the machines are built to produce. The historical parallel is precise: not every factory worker displaced from the belt-and-shaft line became a factory designer. Many didn’t. The computing wave’s transition from clerical work to knowledge work was intergenerational — the displaced workers’ children became software engineers, not the workers themselves.

But there’s a second story at the bottom that the crisis narrative misses entirely. Some people are stuck in consensus work not because it’s their ceiling, but because it consumes all their bandwidth. The analyst buried in data cleaning who never gets to do analysis. The associate generating pitch books who never gets to evaluate deals. The nurse spending hours on charting who never gets to focus on patient judgment.

When AI lifts the consensus burden, these people don’t get displaced — they get liberated. They finally have time for the non-consensus work they were always capable of but never had the bandwidth to do. This is what Autor means when he writes that AI could “extend the relevance, reach, and value of human expertise to a larger set of workers” — not by making everyone an expert, but by removing the consensus floor that kept capable people from reaching their ceiling.

The dividing line is whether someone has synthesis capacity that was buried under consensus work, or whether the consensus work was all they had. That’s a hard question, and the honest answer is that for many people at the bottom, it’s genuinely a displacement story.

The middle: the translation problem

The middle of the pyramid is the most interesting and the least discussed. These are people with a genuine mix of consensus and non-consensus units in their day — project managers, team leads, department heads, middle management broadly. Their non-consensus skill was often coordination: synthesizing input from multiple people, translating strategy into execution, making judgment calls about priorities and resource allocation.

When AI automates the consensus units below them, the coordination challenge transforms. Managing a team of people doing consensus work is a different skill from directing AI systems that do the same work — the judgment is similar (what should we prioritize? what does quality look like?) but the execution layer is entirely new.

This is a translation problem, not an elimination problem. The people in the middle who can redirect their coordination instincts — who can manage AI workflows with the same judgment they used to manage human teams — become dramatically more productive. The ones who can’t make that translation face a version of the same displacement the bottom faces, just from a higher starting point.

The top: the rising bar

For people at the top of the pyramid, AI doesn’t threaten displacement. It raises the competitive bar.

When the consensus units below you get automated, you can go deeper. The strategic work you used to squeeze between meetings and reviews now has room to breathe. The pattern recognition you exercised across a narrow slice of information can now span a much wider field, because AI handles the gathering and summarizing that used to eat your time.

But everyone else at the top gets the same advantage. Strategy that was differentiated last year becomes table stakes this year. The synthesis that made you valuable when information was scarce becomes expected when information is abundant. The non-consensus bar keeps rising — not because the work gets harder in absolute terms, but because the baseline keeps climbing.

Why the Frontier Keeps Expanding

Competitive dynamics, not optimism, drive frontier expansion. When everyone can produce the same consensus output, that output gets commoditized. The only way to capture value is to do what the machines can’t do yet — to find the differentiated angle, the synthesis, the thing nobody else is offering.

This is what every previous wave actually looked like. Electrification commoditized centralized power, so the value shifted to factory design. Computing commoditized calculation, and an entirely new category of knowledge work emerged. The internet commoditized information distribution, so the value shifted to curation and strategy. Each time, the consensus layer got cheaper and the non-consensus frontier got more valuable — because scarcity is what drives returns, and non-consensus work is what’s scarce.

The factory owners who redesigned around unit drive in the 1920s captured the next fifty years of industrial growth. The ones who bolted electric motors onto steam-era layouts got acquired or went bankrupt. The technology wasn’t what separated them — the willingness to reorganize was.

That’s the question this moment is asking — of individuals, of companies, of entire industries. The consensus units are being automated. The question is whether you’re reorganizing around what’s left — the judgment, the synthesis, the ability to look at ten separate data points and see the one pattern that connects them.

At the bottom, that means asking honestly whether you’re displaced or liberated. In the middle, it means figuring out whether your coordination skills translate to a new medium. At the top, it means asking whether you’re going deeper or coasting on a bar that’s about to rise.

What’s one part of your work that felt like judgment five years ago — and feels like pattern-matching now?

Previously in Ground Truth: The Leash Length Problem explored how much autonomy to give AI systems — and the architecture required to extend it. The consensus machine reframes the question: the leash length problem is really the middle layer’s translation problem, applied to one firm at a time. The Structural Divide explored why enterprise AI productivity lags individual breakthroughs — the reorganization bottleneck, before I had a name for it.

At a Lunar New Year party last weekend, I was telling another parent about the app I built for our kids — a Chinese character learning tool I made with Claude Code, Anthropic’s AI coding agent. She’d been a professional before staying home with her kids, and she asked the question I think everyone wants to ask about AI but doesn’t know how to frame:

“But how do you know it’s right? Don’t you need to check every character against a dictionary?”

I gave her the answer that I’ve realized is the most honest one I have: “The same way you’d know any work your junior people did was right. You don’t check every line. You ask them about their plan, you evaluate whether the plan makes sense, and you observe what happens in production.”

I’m not going to manually verify every dictionary pair in the database. But I’ve accepted the trade-off: this is a low-stakes production environment, I’ll catch mistakes through use, and the alternative — building everything by hand — means the app doesn’t exist at all.

That answer didn’t come naturally to me. It took six months of working with an AI agent to develop the mental model behind it. And I think the framework that emerged — thinking about AI delegation the way we think about people management — has implications well beyond my little app.

You’re reinventing management — whether you realize it or not

That answer I gave at the party — “the same way you’d manage a junior employee” — turns out to be more than an analogy. As Ethan Mollick has argued in “Management as AI Superpower”, working with AI agents is fundamentally a management problem. The same skills — clear delegation, knowing what “done” looks like, checking work at the right level of detail — are what separate effective AI users from frustrated ones.

I’d take it a step further: we’re not just reinventing management. We’re recapitulating the entire history of how organizations learned to delegate. The toolkit is remarkably parallel — up to a point.

Subscribe now

My accidental management journey

I am not an engineer by training. I helped scale a company from 20 people to IPO as a product leader and spent eight years evaluating startups as an investor. Now I work daily with Claude Code across everything from building apps to automating investment workflows to developing product strategy. It’s become a general-purpose work partner, not just a coding tool. When I started, watching every step was the point. I’d read Claude’s reasoning, see what commands it chose and why, observe how it handled errors. Like sitting next to a senior engineer and learning by watching.

Eventually I got comfortable and turned on “accept edits” — letting Claude read and write files without asking me each time. But here’s the thing about Claude Code: it can do anything on your computer that you can do. Open any file, run any command, install any package. That power is exactly why it asks permission before every action — and anyone who’s used it knows that means dozens of approval prompts per session.

There was an option to skip all permission checks entirely. But I didn’t have the security guardrails in place, and I’m not the person who instinctively knows which commands can damage a system. So I lived in a middle ground that satisfied nobody: I couldn’t walk away for ten minutes without coming back to find Claude waiting on a permission prompt, the whole session stalled.

Then, six months in, I tried something different: I asked Claude to audit its own permissions.

The human management stack

Before I describe what happened, consider how organizations actually solved the delegation problem with humans. It wasn’t one big decision to “trust people.” It was a stack of infrastructure that built up over decades:

Observation: You watch the new hire’s work closely. Not because you don’t trust them — because you’re calibrating. Learning their strengths, their blind spots, where they need guidance.

Processes and artifacts: Checklists, SOPs, templates, style guides. These aren’t bureaucracy for its own sake. They’re externalized judgment — the organization’s way of saying “here’s how we think about this” so individuals don’t have to reinvent it.

Graduated trust: Fewer mistakes → more responsibility. The new hire who handles small projects well gets bigger ones. This is empirical, not theoretical. You’re not deciding to trust them. You’re observing that trust is warranted.

The social contract: And here’s the piece that makes everything else work. A human employee has skin in the game. Their reputation, their career, their livelihood depends on doing good work. If they make a catastrophic error, there are consequences — for them. This accountability creates a feedback loop that self-regulates — which is why people internalize the standards even when nobody’s checking. Their identity is tied to their performance.

AI agents are building the same stack

AI development tools are recapitulating this pattern with surprising precision — every layer of the management stack has a direct equivalent:

Observation → Extended thinking. Claude Code has a mode that lets you watch the AI’s reasoning process in real time — not just its output, but how it approaches problems. This is the equivalent of sitting next to your new hire and seeing how they think, not just what they produce.

Processes and artifacts → CLAUDE.md, memory files, hooks. These are literally externalized judgment for AI. A CLAUDE.md file tells Claude “here’s how we think about this project.” Memory files persist learnings across sessions. Hooks automate compliance checks. These are SOPs for machines.

Graduated trust → Permission tiers. When I asked Claude to audit its own permissions, it came back with three tiers that any manager would recognize:

• Auto-approve (reversible, read-only): File reads, directory listings, running tests — the equivalent of letting your hire read company documents without asking permission.

• Gate but don’t block (visible changes): File edits, new files, installing packages — like letting your hire draft documents. Review the output, not the process.

• Always require approval (destructive or irreversible): Force pushes, database deletions — the decisions where a senior person should always weigh in.

This is role-based access control, but arrived at through the same logic managers use: categorize by reversibility, not by fear.

What made the difference, by the way, wasn’t learning to code — it was learning to ask. Instead of being directive — “allow this command, block that one” — I asked Claude to analyze the gap and recommend a framework. AI’s strength isn’t just executing; it’s researching and planning. By evaluating its plan rather than micromanaging its actions, I was doing exactly what good managers do: judge the thinking, not just the output.

Where the analogy breaks — and where it doesn’t matter

The first three layers of the human management stack — observation, processes, graduated trust — translate almost perfectly to AI. But the fourth layer doesn’t: the social contract.

When you delegate to a person and they fail, there are consequences — for them. Their reputation takes a hit. Their next project gets more oversight. In extreme cases, they lose their job. People internalize standards because their identity is tied to their performance. When you delegate to an AI agent and it fails, the consequences land on whoever deployed it. The AI has no reputation to protect, no career to jeopardize, no reason to be more careful next time beyond whatever you’ve configured in its instructions.

Researcher Fabrizio Dell’Acqua calls the risk of over-delegation “falling asleep at the wheel” — in a field experiment with 181 professional recruiters, those given high-quality AI actually performed worse than those given lower-quality AI. They spent less time on each case, blindly followed AI recommendations, and became “lazy, careless, and less skilled in their own judgment.” I think part of the reason is structural: the social contract that keeps human delegation honest doesn’t exist in human-AI delegation.

What I’ve come to believe is that for a large category of work, architecture can substitute for the social contract entirely — and it might actually be better.

My three-tier permission model doesn’t need Claude to “care” about its reputation. It makes destructive actions structurally impossible without approval. Git gives me version control. Hooks catch rogue configurations. The environment is safe not because the agent is accountable, but because mistakes are reversible. This is why software engineering is the natural starting point for AI agents — the infrastructure to make mistakes cheap and recoverable already exists.

And this architectural approach has an advantage the social contract doesn’t: it prevents damage rather than punishing it after the fact. With a human employee, if they make a catastrophic error, the social contract means there are consequences for them — but the damage to the organization is still done. With an AI agent operating inside a well-designed permission structure, the damage never happens in the first place.

The last mile

So the leash will get longer — it already is. Dan Shipper, the CEO of Every, has proposed that the real proxy for AI progress is how long an agent can run independently before a human needs to intervene. Researchers at METR have been measuring this empirically — on standardized benchmarks, the autonomous work horizon for frontier AI agents has been doubling roughly every seven months.

For most knowledge work — writing, coding, analysis, administration — the combination of improving models and maturing infrastructure will steadily extend the leash. We’ll build better permission tiers, better audit trails, better rollback mechanisms. Architecture will substitute for accountability, and it’ll work.

But there’s a category of work where it won’t be enough. When the stakes are irreversible — a critical medical decision, an autonomous weapons system, a trade that moves markets — no amount of permission infrastructure fully solves the problem. Even if the AI is statistically better than the human, there’s still a nonzero probability of error. And for irreversible errors, you can’t undo the damage no matter how good your rollback system is.

This is where the social contract becomes the binding constraint. We’ve seen this play out already with driverless cars. A Swiss Re analysis of 25 million autonomous miles found Waymo vehicles had 88% fewer property damage claims and 92% fewer bodily injury claims than human drivers. But people still feel less safe in them — and I think a key reason is the accountability gap, not the capability gap. When a human driver causes an accident, someone is responsible. When an autonomous vehicle causes one, the absence of a blameable agent feels fundamentally wrong, even if the outcome is better on average.

That response isn’t rational, but it’s deeply human. And I think it’s the real frontier of the leash length problem: not whether AI can do the work, but whether we can accept outcomes from a system that has no skin in the game.

The leash length problem

The leash will get longer in two phases. First, through architecture — permission tiers, memory systems, audit trails, reversibility infrastructure. This is happening now, and it works. My own experience is proof: the right framework turned six months of babysitting into a productive partnership.

The second phase is harder. It requires either inventing accountability mechanisms for AI that satisfy the same psychological need as the social contract — or accepting that for some categories of decisions, AI will be statistically better than humans but we’ll still want a person making the final call, simply because a person can be held responsible.

We solved delegation in human organizations by building infrastructure and relying on a social contract. For AI, the infrastructure is being built. The social contract isn’t — and for most work, it might not need to be. But for the work that matters most, the last mile of the leash isn’t a technical problem. It’s a question of whether we can accept better outcomes from a system that can’t be held responsible for worse ones.

Previously in Ground Truth: The Snapshot Problem explored why smart people can look at AI and see completely different realities. The leash length problem is one reason those snapshots diverge — the people who’ve configured their AI thoughtfully are experiencing a fundamentally different tool than those still running defaults.