Chapter I: The Sand Hill Simulation

The glass wall overlooking Sand Hill Road hummed with a faint electronic dampening field. Inside the conference room, three partners at a venture firm watched a holographic telemetry feed displaying the financial pulse of the modern artificial intelligence landscape. The numbers were staggering, almost surreal. By late May 2026, Anthropic had surged to a breathtaking $47 billion annualized revenue run-rate, driven by massive developer adoption of autonomous coding agents like Claude Code. OpenAI held firm at a $25 billion run-rate. Across the global infrastructure grid, the five major hyperscalers—Microsoft, Alphabet, Amazon, Meta, and Oracle—were deploying an unprecedented $660 billion to $690 billion in capital expenditure in 2026 alone, carving out megawatt data centers across desert basins and polar fringes.

Yet, when Elena sat down to present her thesis on the future of enterprise software, she didn’t open with a product roadmap or a valuation slide. Instead, she brought up a dark, quiet map of global commerce. Outside the insulated bubble of software development and frontier tech startups, the operational penetration of artificial intelligence into actual enterprise workflows—into procurement, supply chain logistics, regulatory compliance, and corporate finance—remained stubbornly below five percent. Ninety-five percent of the global economy still ran on human eyes staring at static spreadsheets, manual data entry, and tired office workers copy-pasting text between disconnected browser tabs.

This story reveals why the greatest technological expenditure in human history yielded such a profound adoption disconnect. The industry spent four years building synchronous chat windows under the assumption that enterprise workers wanted to spend their days conversing with an AI assistant. But corporate work isn’t a real-time conversation. Corporate work is asynchronous, negotiated, and slow. The collective net profit of the Fortune 500 and S&P 500 sits at roughly $2 trillion every year. Capturing even ten percent of that profit pool through operational automation represents a $200 billion annual software opportunity. Winning that market won’t happen inside a chatbot; it will happen inside the oldest, most resilient protocol in digital history: asynchronous email.

Chapter II: The Protocol That Refused to Die

Elena tapped her terminal, bringing up a single message header dated 1971. When Ray Tomlinson sent the first network email over ARPANET, he created a protocol that would outlast the World Wide Web, the desktop computer, the smartphone, and generations of enterprise software suites. Over fifty years, wave after wave of tech visionaries announced the imminent death of email, promising that internal chat platforms or social workspaces would replace the inbox. Yet email endured as the undisputed nervous system of global business.

Why did email survive? The answer lies in the physics of human organization. Synchronous real-time interaction imposes severe cognitive friction on corporate workers. As explored in The Chatbot Myth: Why Enterprise AI Still Needs the Dashboard on semi◦diffusion, chat products demand immediate human presence, prompt engineering, and continuous context switching. Chatbots interrupt human focus; email respects asynchronous human time.

Read more

Every morning, everything starts again. The sales rep relearns which customers hate phone calls. Support rediscovers that one account always pays fifteen days late, and always pays. The same pricing debate happens every quarter, with the same conclusion, because nobody remembers reaching it. Every employee is permanently new.

No real company operates this way. An institution is, more than anything, accumulated memory: conventions, relationships, and lessons that outlive any single conversation and any single employee.

Yet this is exactly how most companies have deployed AI. Each chat begins at zero. The context you patiently explained yesterday is gone today. The correction you made last week gets unmade this week. We hired the smartest intern in the world, and we wipe its brain every night.

I have spent ten years as a B2B product manager, from 2016 to 2026. The last four were spent building AI products, and today I lead chat memory for a B2B agent platform. What follows is my field notes: two stories that changed how I build, and the principles I now refuse to ship without.

What memory actually is

Memory is what carries over between conversations.

Not the transcript. Storing every message and stuffing it back into context is not memory, any more than a security camera archive is a brain. Memory is extraction: the system reads a conversation and decides what it means. “This user wants totals as CSV.” “This buyer disputes freight charges, so check before autopay runs.” “Legal reviews any quote above fifty thousand.” The transcript is evidence. Memory is the verdict.

In B2B, that extraction applies at two levels, and the distinction matters more than any other design choice you will make.

Personal memory is applied at the user level: your preferences, your working style, your current projects. It makes the assistant feel like it knows you.

Collective memory is shared: conventions, policies, and skills, learned across all members of the company. When one person teaches the assistant how the company categorizes invoices, everyone’s assistant should know it the next morning. This is the layer that turns a chat tool into an institution. It is also the layer almost nobody builds, because it is the harder one.

A test I like: if the assistant gets smarter for one user but stays a stranger to the teammate sitting three feet away, you have built a consumer product wearing an enterprise badge. The morning after any conversation, ask what the company now knows that it did not know yesterday. If the answer is nothing, you have a chat log, not a memory.

Why Chinese companies like OpenClaw

There is a Chinese essay making the rounds on why companies there have taken so warmly to OpenClaw, the viral open source agent people run on their own machines. Beneath the memes, I think the affection has a simple root: OpenClaw treats memory as plain files. Markdown you can open, read, edit, and carry. When the agent remembers something wrong, you delete a line. When you want it to know something, you write a line.

That is not a sophisticated memory architecture. It is something better: a legible one. People trust memory they can see and touch, and are unnerved by memory that lives as an invisible blob behind an API. Hold that thought, because every expensive lesson below comes back to legibility.

A confident wrong memory is worse than forgetting

Three weeks after we shipped memory, the assistant greeted a user with a warning about a credit hold on her account. The hold had been lifted twenty days earlier. Stale state, recalled as fresh fact, delivered in the confident tone these models use for everything.

Her support ticket said it precisely: “It’s worse than forgetting. It remembers wrong and sounds sure.”

Humans forgive forgetting. We all forget, and we have social rituals for it. Nobody has a ritual for a colleague who asserts, warmly and without hesitation, something that stopped being true three weeks ago. Confident misremembering reads as lying or broken, and nothing in between. Unmanaged memory is just hallucination with a longer fuse.

The fix was not better recall. It was humility, engineered in three parts.

First, provenance. Every remembered fact now carries its source and its age. The assistant does not say “you have a credit hold.” It says the account showed a credit hold as of June 3, and anything time sensitive gets verified against the live system before it is asserted. Memory becomes a hypothesis to check, not a truth to announce.

Second, decay. Old context does not sit in the store at full strength forever. It gets hedged first (”last I knew...”), then retired. A fact about payment behavior from eight months ago should not speak with the same voice as one from last week.

Third, an edit path. When memory is wrong, the user can see why the assistant believed what it believed, and correct it in one step. The OpenClaw lesson again.

Graceful forgetting took longer to design than remembering did, and it earns more trust. If your roadmap says “add memory” on one line, split it into two: remember, and forget. Budget more time for the second.

Read more

The promise lasted about ninety seconds. Over the next seven minutes, Karp described the dominant mode of enterprise AI adoption as companies “chillaxing” with tokens. He accused the industry of a plan to “triply oversell” its product. He likened AI spending to “a wealth tax that does not help the poor,” called a piece of Silicon Valley consensus “effing insane,” and described himself as “the neurodivergent crazy person that apparently is on drugs, the one thing I don’t do.” When an anchor observed that he sounded angry, Karp corrected her: “This is the voice of American business that is being channeled through me.”

It is tempting to file the whole thing under Karp Being Karp, the philosopher-CEO with a Frankfurt doctorate on aggression and jargon, whose career has been a longitudinal study of both. The eccentricity is not incidental to Palantir’s brand; it is the brand, and it has been since the years when the company was dismissed as a consultancy in a software costume.

But I want to make a different argument, and I want to make it as a practitioner rather than a spectator. Before I edited this newsletter, I spent a decade as a product manager building and selling B2B AI systems, pre-LLM machine learning, then the generative wave. I have run the pilots Karp is mocking. My honest reaction to his CNBC performance was not amusement. It was recognition. Strip away the theater and Karp said, in public, the thing that frontier-lab CEOs will not say and that every enterprise buyer already believes: “something has gone completely wrong” with how AI is sold, and the wrongness is not about capability. It is about trust.

Capability compounds with scale. Trust does not. You cannot fix a trust deficit with a bigger training run, and that asymmetry, models improving faster than anyone’s willingness to depend on them, is the defining economic fact of this cycle. Call it the AI trust recession: a period in which the technology gets monotonically better while committed adoption stalls, because the buyers being asked to bet their businesses on AI do not believe the sellers are on their side.

Karp made three claims that morning. Each is testable. Each maps onto a mechanism I’ve watched operate from inside the deal. Together they amount to a theory of where the money in AI actually goes, and it is a better theory than the one embedded in current market prices.

Claim one: the pricing is a confession

The frontier labs charge for tokens, metered units of usage, like kilowatt-hours. Karp’s knife: “If it was so valuable, let’s say I can make you a billion dollars right tomorrow, wouldn’t I say, I’ll make you a billion dollars and I want 30 percent? Why are they charging for tokens if it’s so valuable?”

Economists have a dry name for this, revealed preference, but the sales floor version is blunter: watch how something is priced and you learn what its seller privately believes. A litigator certain of victory takes the case on contingency. A gym, certain of nothing except your January optimism, sells you a membership and hopes you never show up. Outcome pricing is the tell of confidence; usage pricing is the tell of doubt. The AI industry talks like the contingency lawyer and bills like the gym.

I want to be fair to the labs here, because I’ve priced AI products and it is genuinely hard: outcomes are contested, attribution is a nightmare, and usage pricing is the only model that scales without a services army. But the buyer doesn’t grade you on difficulty. In every enterprise deal I’ve worked, the sophisticated customer runs exactly the inference Karp describes: if the people who built this thing won’t stake their revenue on its value, why should I stake my company on it? That inference, not model quality, not GPU supply, is the real bottleneck in enterprise AI. Karp says he hears it in “every single enterprise” he deals with. So did I, for ten years, about far less capable systems.

His other two claims explain what those enterprises are actually afraid of, and why the fear is structural rather than paranoid. One is about where AI’s durable profit pools sit, and Karp backs it with an admission against his whole industry’s interest. The other is a fear that, in his telling, Fortune 500 executives will only voice in private, and it ends with the Pentagon’s favorite software salesman reaching, on live television, for Karl Marx.

Below the paywall: the “chillax economy” and the precise mechanism by which enterprise pilots die in committee, from someone who has watched it happen a dozen times; the electricity analogy that reframes the entire capex boom; the strongest case against Karp, part of which he made himself, possibly by accident; and the four signals that will decide, within eighteen months, who captures AI’s value. If this newsletter sharpens how you underwrite the AI trade, this is the piece to upgrade for.

Read more

In 2017 I was sure the screen was about to lose.

I was working on voice products in Beijing then, in the first serious wave of conversational AI to come out of China. At Mobvoi we were building systems you talked to. Down the road, Xiaomi was shipping XiaoAI and the Mi AI Speaker, and for one strange moment the whole industry seemed to agree on where this was going. The future was a voice in the air. You would talk to your home, talk to your car, talk to your phone, and the grid of icons we had been tapping for a decade would quietly retire. The interface itself would dissolve into conversation.

It did not happen. Not then.

The speakers sold and the demos dazzled, and then most of us went back to tapping glass. For a long time I filed this under failure of technology. The speech recognition was brittle, the language understanding was shallow, the systems could set a timer but could not hold a thought. Give it better models, I assumed, and the conversational future would arrive on schedule, a little late but inevitable.

The models did get better. They got staggeringly better. And here is the thing I keep turning over as I watch enterprise software get rebuilt around large language models in 2026. Now that the technology genuinely works, conversation still is not eating the world the way we promised it would. It is eating something. But the shape is different from the dream, and that difference is the most interesting design problem of this cycle.

There is an old idea from linguistics worth borrowing here. Noam Chomsky built a career on a deceptively simple observation: human language is infinitely generative. With a finite vocabulary and a finite set of rules, you can produce an unbounded number of sentences, most of which have never been said before and never will be again. Conversation is open at the top. There is no final sentence.

Business is not like this. A food distributor chasing an overdue invoice is not performing an infinitely generative act. There is a customer, a balance, a due date, a payment, a credit limit, and a small, finite set of things that can legitimately happen next. The surface of the conversation is wide open. The space of valid outcomes is firmly closed. Almost all of the hard, unglamorous work of building conversational software for real companies lives in that gap, mapping an open linguistic surface onto a closed set of consequences without frustrating the human or letting the machine improvise its way into a liability.

When the models were weak, we never reached this problem. We were stuck one floor below it, fighting transcription errors. Now that the models are strong, the gap is the whole game. And in enterprise B2B, where the consequences are money and contracts rather than song requests, I have watched a clear pattern take shape.

Here is the short version, and then I want to walk through how to actually design for it, because this is where the real decisions live.

Chat is becoming the front door to enterprise products. It is not becoming the house. The dashboard did not die. The admin panel did not die. They changed jobs. And the teams shipping conversational software that people actually keep using are not the ones who replaced their interface with a chat box. They are the ones who worked out precisely which parts of the work belong in a conversation and which parts belong behind glass, on a screen, in a table you can sit and stare at.

Chat owns the easy 80%. The screen owns the consequential 20%.

Read more

I hope to defend and complicate that thesis from many angles over the coming weeks — this is the first piece in that series. And the question I want to start with is the one most of the current discourse is skipping past: if context is the thing, what format does it live in?

The fashionable answer right now — most loudly from Foundation Capital, who recently invested multiple companies in this space — is the context graph. Pull every entity, every relationship, every piece of metadata your company touches into a beautiful knowledge graph. Hand it to the LLM as a structured object. Magic happens.

I want to argue, gently but firmly, that this is the wrong picture.

Not because graphs are useless. They’re great. But “context graph” as the marketing term, the company-defining bet, the venture thesis — it’s a category error. Context isn’t a graph. Context is hybrid intelligence. The graph is one ingredient, and not even the hardest one.

Let me explain why this matters, what I think the actually-hard work looks like, and which companies I think are quietly winning while the graph crowd cheers.

The graph illusion

Foundation Capital’s pitch — and they’re not alone, several brand-name funds have variants of this — runs roughly: enterprise data is messy and siloed. Pull it into a knowledge graph. Now the LLM has clean, structured context.

The problem is that a graph database, by construction, prefers deterministic relationships. “Acme Corp is a customer.” “Invoice 4471 belongs to Acme.” “Sarah is the AP contact at Acme.” Beautiful nodes and edges. Queryable in milliseconds.

But the context that actually matters when an AR (account receivables) executive decides whether to chase a 30-day-late invoice from Acme isn’t in the graph. It’s in:

• The Slack thread where the CSM mentioned “Acme is going through a leadership change, give them a quarter.”

• The email from Sarah six weeks ago that said “We’re switching ERPs, expect delays.”

• The Gong call where their CFO half-admitted they’re raising bridge financing.

• The dunning history showing Acme always pays at day 47, not day 30, and always in full.

• The fact that Maria, the rep, knows Sarah personally and would never call her cold.

None of that fits cleanly in a graph. Some of it is deterministic (the dunning history, the invoice amount). Some of it is conversational and anecdotal (the Slack thread, the Gong snippet). Some of it is implicit social knowledge (Maria’s relationship with Sarah). Some of it is source of truth (the ERP balance). Some of it is probabilistic — the CFO’s hint about bridge financing might be true, half-true, or theatre.

Context, in any operationally useful sense, is the union of all of this. It is hybrid. The graph is one slice. Treating the graph as the substrate is like trying to capture a city by mapping only its streets — you get the topology and lose everything that makes the city worth living in.

This is why the Foundation Capital thesis gives me pause. They’ve made two investments in this space. Both are excellent graph-shaped companies. Neither, by itself, solves the user’s problem. The bet only pays if the portfolio gets stitched together into something much bigger than a graph — and that stitching is the work, not the graph.

What a16z got right

The frame I keep returning to is the a16z piece on the move from system of record to system of intelligence. It is the most useful single essay I’ve read on this transition.

The argument, briefly: for thirty years, enterprise software has been about recording things. CRMs record customer interactions. ERPs record transactions. HRIS systems record employees. The whole industry has been one giant database with a UI on top. The job of the human was to take the recorded data and do something with it — judgment, action, follow-up.

The shift now underway is from systems that record to systems that act on the record. The AI doesn’t just store the customer interaction; it follows up. It doesn’t just file the invoice; it dunns the deadbeat. It doesn’t just log the support ticket; it resolves it. Record becomes intelligence.

What a16z got exactly right is that this transition is not primarily a model problem. The frontier models can already do most of these tasks. What’s missing is the context layer that makes the model’s actions legitimate and competent in a specific business.

What a16z understates, in my reading, is how brutally hard that context layer is to build. And this is exactly where the “context graph” thesis quietly collapses.

Why GTM is the real moat

If “context graph” were the answer, company-building would be relatively clean: build a great graph product, sell it into enterprise, win. The graph database industry already tried this exact play in the 2010s. Neo4j is a real company. But it’s not a $100B company, and the reason isn’t technical — it’s that clean graphs don’t actually solve the user’s problem.

The user’s problem is a workflow problem. The AR executive doesn’t wake up wanting to query a knowledge graph. She wakes up wanting to know: which five invoices do I chase today, in what order, with what message, through which channel? She wants the answer, in the flow of her day, with the right tone for each customer.

To deliver that, the system needs:

Read more

The wall is not size. It is structure. Every company runs on two kinds of data: state — the closed deal, the approved invoice — and reasoning — the Friday-night call where the discount got approved, the precedent the support engineer remembered, the off-label note. State is what Salesforce, Workday, and ServiceNow were built to store. Reasoning lives in Slack threads, Zoom calls, and the heads of senior people most likely to leave.

A context graph is the missing layer that captures it. Foundation Capital calls it AI’s trillion-dollar opportunity. Neo4j’s Will Lyon calls it “the missing why.” I’d go further: it is an organizational world model — a structured, living representation of how a company actually thinks.

The full essay traces why incumbents structurally cannot build it, what it means for B2B product managers, and where the moats will form. Read on →

World Model

The Million-Token Mirage

There is a strange double rhythm to artificial intelligence right now. On one beat, the industry celebrates ever-larger context windows — a million tokens, two, four — as though capability were simply a matter of wider doorways. On the other beat, the people actually pushing AI into production keep walking into a wall that wider doorways do not break. The disappointment is rarely about a model's reasoning. It is about what gets lost on the way in: the relationships between the pieces you dropped into the prompt…

Read more

3 months ago · 1 like · Cong

Previous Highlights

A salesperson approves a nonstandard discount on a Friday-night call. A doctor writes an off-label prescription with a one-line note. A support engineer escalates a ticket because she remembers the same bug from a different customer two years earlier. A general counsel agrees to an unusual indemnification clause because, last quarter, a similar one held up in arbitration. Each of these is a decision. Each is the kind of decision that makes a company itself. And almost none of them are durably captured by the software the company runs on.

This gap has, in the last six months, quietly acquired a name. A small but growing chorus of investors, founders, and database engineers has begun calling it the context graph: a structured, machine-readable record of an organization's reasoning, not just its outputs. Foundation Capital, in a widely circulated essay this spring, called context graphs "AI's trillion-dollar opportunity." Aaron Levie, the CEO of Box, debated the thesis on his podcast with Foundation's Joanne Chen and PlayerZero's Animesh Koratana and ended up agreeing — somewhat against his initial reflex. Will Lyon, a product manager at Neo4j, has taken to describing context graphs in the most deliberately plain way possible: "the missing why." In his definition, a context graph is "a knowledge graph that contains all of the information necessary to make decisions throughout the organization."

That definition is calm by design. It is also, I suspect, the most consequential idea in enterprise software right now.

To see why, consider the shape of the problem. Every company is sitting on two fundamentally different kinds of data. The first kind — the easy kind — is state: the closed deal, the approved invoice, the resolved ticket, the shipped order. State is what Salesforce, Workday, ServiceNow, SAP, and Snowflake were designed to preserve. The second kind — the hard kind — is the reasoning that produced that state. Why this customer got a forty-percent discount when the published floor was twenty. Why this account received custom payment terms. Why this candidate was hired despite a weak case round. Why this incident was triaged the way it was.

That reasoning, today, lives almost everywhere except in software. It lives in Slack threads, deal-desk calls, Zoom recordings no one has rewatched, two-line follow-up emails (”approved per our chat”), and the heads of the senior people most likely to leave. The moment those moments end, the reasoning evaporates, and the company is left with a state record that — to a future employee, or to a future model — is uninterpretable without the human chain of memory that produced it.

A model with a million-token window does not solve this. It just gives you a larger room in which to be confused. As Emil Eifrem, the CEO of Neo4j, has been putting it lately: the question is not whether you have enough information; it is whether the information has any structure to its relationships. Without that structure, longer context becomes, in his blunt phrase, a larger pool of noise.

What systems of record were never built to remember

The most useful frame I have heard for this comes from Aaron Levie, and it is, of all things, a story about travel agents.

Read more

The AI economy runs on a three-stage conversion chain: electricity becomes tokens, tokens become productivity. Each stage has its own economics, its own bottlenecks, and increasingly its own geopolitics. Understanding this chain is the difference between building on a foundation and building on a bet.

Stage one is electricity. This is where the most underappreciated structural advantage in AI sits today. In March 2026, President Trump told the heads of Amazon, Google, Microsoft, and OpenAI that any new AI data center in the United States must source its own power. The American grid cannot absorb the load. Meanwhile, China crossed 10 trillion kilowatt-hours of annual electricity consumption in 2025, more than double the US figure, built on seventy years of treating power as public infrastructure rather than a market commodity. Cheap, abundant electricity is the floor of any AI cost structure, and not every country has the same floor.

Stage two is the electron-to-token conversion. Two competing strategies have emerged. The American approach is hardware-led: own the best chips, own the cost curve. The Chinese approach is increasingly algorithm-led: squeeze more intelligence out of less silicon through architectural innovation. DeepSeek collapsed training costs through engineering. Kimi demonstrated that you can split inference across data centers running mixed-generation chips and still achieve competitive economics. These two curves are not in competition. They are complementary, and they will converge. The frontier of cost-efficient inference will belong to whoever combines both.

Stage three is the one nobody has solved. Tokens become productivity through human judgment, not through physics. A corporate lawyer can turn ten thousand tokens into a billion-dollar outcome. A student can spend the same tokens on an essay no one reads. There is no fixed exchange rate between tokens and dollars. The bottleneck is no longer the model. It is the human’s ability to decompose problems, design precise prompts, and route the right model to the right task. The most important capability of the next decade is not prompt engineering. It is structural thinking.

The market is already encoding this reality into its pricing. Jensen Huang’s three-axis token pricing framework (intelligence, speed, context length) is not marketing. It is a mirror of the underlying economics. The top tier will be priced like a luxury good. The bottom tier will commoditize toward zero. The dangerous place is the middle, where undifferentiated resellers of someone else’s tokens get squeezed from both directions.

The strategic question for every builder, investor, and operator: which conversion in this chain are you actually capturing? Infrastructure scale, algorithmic innovation, or the productivity layer where domain expertise determines value? Each is a viable position. But you have to know which one you occupy.

I break down the full analysis in the video above.

P.S. If this reframe is useful, share it with a founder or operator who is making infrastructure or model procurement decisions right now. And if you want the deeper playbook on how to apply this framework to your own product and career decisions, that’s what the paid tier of World Model is built for.

Previous highlights

The center of gravity in AI is shifting from model capability to applied economics. The decisive question of the next decade is not which lab releases the smartest system. It is who can transform raw electricity into useful intelligence at the lowest cost, with the highest reliability, at planetary scale. That is a question of infrastructure, geography, and policy, far more than it is a question of research.

A useful way to see this is to think of the AI economy as a three-stage conversion chain. At one end sits the electron, the cheapest input modern society produces. In the middle sits the token, the unit of account for everything large language models do. At the other end sits productivity, the actual economic output that users and enterprises pay for. The full chain is electricity → tokens → productivity.

Each stage has its own economics, its own bottlenecks, and increasingly its own geopolitics. The cost of converting electricity to tokens depends on chips, algorithms, and data center design. The cost of converting tokens to productivity depends on model quality, prompt design, and human judgment. The two conversions are governed by entirely different forces. Treating them as one continuous “AI cost” obscures more than it reveals.

This matters because the last decade of AI commentary has been dominated by a single mental model: scale wins. Add more parameters, more data, more compute, and capability follows. That model is not wrong, but it is incomplete. It explains how the field moved from GPT-2 to GPT-4. It does not explain what happens next.

What happens next is determined by the slope of three different cost curves: the cost of electricity, the cost of compute, and the cost of converting both into usable intelligence. Each curve has a different shape in different countries. Each is shaped by industrial policy choices made years or decades ago. And each creates a different kind of competitive advantage.

For a builder, this reframe has practical consequences. The choice of where to deploy, which model tier to buy from, and how to structure a workflow is no longer a purely technical decision. It is a bet on which conversion stage will compress fastest, in which jurisdiction. For a policymaker, it means that the AI race is not won at the chip foundry alone. It is also won, perhaps more decisively, at the substation.

The rest of this essay walks through the three stages in turn. It starts with electricity, where the most underappreciated story is unfolding in China. It moves to the electricity-to-token conversion, where the contest between hardware and algorithms is reshaping global cost structures. It ends with the tokens-to-productivity stage, where the pricing architecture of the AI economy is quietly being set in stone.

The Power Floor

In early March 2026, President Trump met with the heads of Amazon, Google, Microsoft, OpenAI, and three other technology companies. The meeting had a single agenda item: any new AI data center built in the United States would have to source its own power. Public grid capacity could not be drawn down for private model training.

That meeting captured something important. The constraint on American AI is no longer talent, capital, or even chips. It is electrons. AI workloads are projected to consume a rising share of US grid capacity over the next several years, and the grid is not expanding fast enough to absorb them. The result is a slow, structural ceiling on how cheaply American AI can be produced.

The same story is playing out across most advanced economies. German power prices spiked to a yearly high. India is rationing electricity to industry. Spain and Portugal recently lived through the largest blackout in their modern history. The energy crunch is not a temporary supply shock. It is the predictable consequence of treating electricity as a market commodity in countries that did not invest enough in long-cycle infrastructure.

Then there is China. In 2025, total Chinese electricity consumption crossed 10 trillion kilowatt-hours, a threshold no country had previously reached. That figure is more than double American consumption. It exceeds the combined annual usage of the European Union, Russia, India, and Japan. The Financial Times described the moment as the arrival of “the first electricity empire in human history.”

This did not happen by accident. From the founding of the People’s Republic, electricity was treated not as a commodity but as public infrastructure, on the same legal footing as roads and water. That framing produced seventy years of consistent state-led investment, regardless of the political and economic cycle. The Three Gorges Dam, an idea first sketched by Sun Yat-sen in 1919, eventually became operational. The West-to-East Power Transmission Project, which moves electricity from the energy-rich interior to the demand-rich coast, became one of the largest infrastructure systems on earth.

The Three Gorges Project is one of the superprojects with the most significant overall benefits

Read more

Previous highlights

I thought about those years constantly when Granola started showing up in my workflow in 2024. The pattern was inverse. It asked for nothing. I opened my laptop, I joined a Zoom or a Google Meet or a Teams call, and Granola just sat there, doing its thing, invisible to everyone else on the call. No wake word. No bot avatar in the participant list. No link to paste into the chat. I didn’t have to tell anyone I was using it. I didn’t have to tell myself. It took me a few weeks to realize that this was the entire product, and that the entire product was also the entire strategy.

Last month Granola closed a $125 million Series C at a $1.5 billion valuation, led by Danny Rimer at Index Ventures and joined by Mamoon Hamid at Kleiner Perkins. Reported revenue growth in the preceding quarter was 250 percent. The cap table now includes Tobi Lütke, Amjad Masad, Karri Saarinen, and Guillermo Rauch, which is an unusually dense concentration of product-led founders voting with their own money. What I want to write about here is why I think any of this happened, and what any of us building AI products should actually take from it.

The Year They Cut Half the Product

Granola was incorporated in London in March 2023 by Christopher Pedregal and Sam Stephenson. Pedregal had founded Socratic, an AI tutor acquired by Google, and then built Stack inside Google’s Area 120 incubator before it was folded into Google Drive. Stephenson was a designer whose career ran through a digital ski coach, a swim coaching wearable, and a low-friction note-taking app called Ideaflow. Neither of them was a first-time founder. Neither of them was in a hurry.

Read more

Previous Highlights

Subscribe now

Here is a confession that will make me sound like a Luddite: the most valuable product insight I ever received came from watching a 58-year-old woman hold a phone.

Not from a dashboard. Not from an A/B test. Not from a Mixpanel funnel. From sitting in a windowless room in Shenzhen, behind a one-way mirror, watching her try to find the camera app.

She tapped the screen with her index finger, just one, like she was pressing a doorbell. She squinted. She rotated the phone 90 degrees, then back. When the moderator asked her what she thought of the 200-megapixel camera, she said: “I don’t know what that means. I just want the photos to look like what I see.”

That single sentence killed a feature that three teams had spent months building. And it saved us from shipping a product that solved a problem nobody had.

This is a story about focus groups, the oldest, least glamorous, most unfashionable tool in the product manager’s toolkit. And about why, paradoxically, they matter more now than they have in twenty years.

The Paradox of the Agent Era

We are living through the most capability-rich moment in the history of software. AI agents can now browse the web, write code, query databases, draft reports, and chain these actions together in multi-step workflows. The gap between “what is technically possible” and “what we can ship” has never been wider.

And that gap is precisely the problem.

When capability is cheap, taste becomes expensive. When you can build almost anything, the hardest question is no longer how but what, and more importantly, for whom. I wrote previously about how great products don’t change user behavior; they embed into existing muscle memory. WhatsApp didn’t teach people a new way to communicate. It digitized what they were already doing. The products that fail are the ones that ask users to develop new habits for the privilege of using them.

In the agent era, this principle is even more critical. Every founder I talk to right now is building some variation of “AI that does X for you.” The technical capability is real. But the user understanding is often paper-thin. They are building agents that automate workflows they’ve never actually watched a human perform.

This is where focus groups come in. Not as a relic from the Mad Men era, but as the specific antidote to the specific disease of 2026: building powerful tools for imaginary users.

Why Online Surveys Are Lying to You

I can already hear the objection. “We do user research. We run surveys. We have data.”

Let me tell you what your online survey data actually contains: noise. A tremendous, statistically impressive quantity of noise.

Here is what happens when you send a survey to 500 people. Some of them are multitasking. Some are answering on the toilet. A meaningful percentage are satisficing, clicking whatever answer gets them to the end fastest. The ones who do engage thoughtfully are self-selecting in ways that systematically bias your sample.

But the deeper problem isn’t data quality. It’s data type. A survey can tell you what people say they want. It cannot tell you why they want it. It cannot capture the moment of hesitation, the furrowed brow, the half-sentence they start and then abandon. It cannot show you the 58-year-old woman pressing the screen like a doorbell.

Surveys are closed-loop instruments. You define the questions, you constrain the answers, and you get back a reflection of your own assumptions. If you’re a founder trying to find your blind spots, a survey is like looking for your car keys under the streetlight because that’s where the light is.

A focus group is the opposite. It is an open-loop instrument. You put four or five real humans in a room, you ask them a question, and then you shut up. You let the conversation go somewhere you didn’t expect. You watch their faces. You hear the specific language they use to describe their problems, language that is almost never the language you use internally.

This is the part that cannot be automated and cannot be surveyed. And it is the part that separates products that ship features from products that solve problems.

How to Assemble the Room: Selecting Your Focus Groups

The rest of this article, including my exact framework for selecting focus group participants, the questioning technique I developed, and the feature prioritization method that consistently surfaces your product’s “wow factor”, is available to paid subscribers.

This is the first piece in The AI PM Playbook series. Upcoming installments will cover pricing research, competitive teardowns, and how to write product specs in the age of agents.

Read more

Previous highlights

In a previous post, I covered what OpenClaw is and why Tencent is going all-in on it with eight new enterprise agents. Today, I want to go deeper. I want to crack open the lobster and show you what's actually inside—not at the code level, but at the conceptual level. Because understanding how these agents work under the hood is the difference between using one effectively and watching it delete all your emails.

The Lobster Is Not the Brain

Here is the single most important thing to understand about OpenClaw, and honestly, about every AI agent you’ll encounter in 2025 and beyond: OpenClaw is not artificial intelligence.

OpenClaw is not a language model. It doesn’t think. It doesn’t reason. It doesn’t understand your commands. It is, as one researcher put it, a crustacean—a simple creature running on hardcoded rules, sitting between you and the actual AI.

The architecture is straightforward. You send a message to OpenClaw through WhatsApp, Telegram, or a web interface. OpenClaw takes your message, wraps it in a massive block of context—who the agent is, what tools it can use, what it remembers about you—and passes that entire package to a cloud-based language model like Claude, GPT, or Gemini. The language model does the actual thinking. It generates a response. OpenClaw receives that response, checks if the model wants to use any tools, executes those tools on your computer, and sends the result back to you.

That’s it. OpenClaw is a middleman. A very sophisticated, very useful middleman.

Why does this matter? Because the intelligence of your agent depends entirely on which language model you plug into the back end. The professor discovered this the hard way. When he first set up his lobster, he connected it to a cheaper, older model. The result was abysmal. The agent couldn’t complete basic tasks, got confused constantly, and felt like a toy. He was ready to dismiss the entire concept. Then he switched to a newer, more capable model, and the difference was night and day. Suddenly the agent could plan multi-step workflows, write code, navigate web pages, and manage files with genuine competence.

Same lobster. Same software. Completely different brain.

This is the first decision you need to get right if you’re considering putting Claw into your workflow: the model you choose is the agent you get.

How It Fakes Having a Personality

If OpenClaw is just a dumb relay between you and a language model, how does it feel so much like a personal assistant? How does it remember your name, your preferences, your ongoing projects?

Read more

Subscribe now

Today I’m announcing a brand new addition to my Substack publication: World Model subscriber chat.

This is a conversation space exclusively for subscribers—kind of…

Read more

I turned my recent post “Hands-on Mercor Playbook” into a short video remix—hope you enjoy it.

Previous highlights

So here it is. The playbook I wish someone had handed me on day one.

But first, a mindset shift. Because if you walk into Mercor thinking like a traditional freelancer—or worse, like a salaried employee—you’re going to have a terrible time.

The AI-Era Uber

Let me give you the mental model that changed everything for me.

Mercor is Uber for AI training. Structurally.

Think about what Uber did. It sat between people who needed rides and people who could drive. It didn’t employ the drivers. It didn’t own the cars. It built the marketplace, handled the matching, and took a cut. The drivers showed up, completed trips, got rated, and either kept getting rides or didn’t.

Mercor does the same thing, except the “riders” are frontier AI labs—OpenAI, Google DeepMind, Anthropic, Meta, and others building the most powerful models on the planet—and the “drivers” are domain experts like you and me. The labs need human-generated data to train and evaluate their models. They need people who can spot where GPT-5 or Gemini or Claude falls apart, write better responses, and judge which outputs are actually correct. Mercor finds those people, organizes them into project teams, and manages the whole operation.

Once you internalize this, a lot of things that frustrate people suddenly make sense.

Projects ending abruptly? That’s normal. The AI lab finished that phase of training, or their evaluation goals shifted, or the model got good enough at that particular task that they no longer need human data for it. It’s not personal. It’s not a performance issue. It’s a ride ending because the passenger reached their destination.

I see people in community groups losing their minds every time a project gets terminated. “I just got off-boarded!” “They cut us without warning!” I understand the anxiety. Losing income is stressful. But panicking about project termination on Mercor is like an Uber driver panicking every time a passenger gets out of the car. That’s… how it works.

The better analogy might be commercial fishing. You go where the fish are. Some seasons are abundant. Some aren’t. You maintain your gear, keep your skills sharp, and stay ready for the next run. The fisherman who prospers isn’t the one who catches one big haul and retires. It’s the one who shows up consistently, reads the water, and adapts.

So rule number one of the Mercor playbook: get comfortable with impermanence. Don’t over-index on any single project. Don’t mentally spend money you haven’t earned yet. And don’t mistake a project ending for a career ending.

What You're Actually Getting Paid For

Here’s something that trips up a lot of new Mercor contributors, especially people coming from traditional tech jobs: you’re not getting paid to be smart. You’re getting paid to find where the model is stupid.

That distinction matters enormously. The AI labs aren’t hiring domain experts because they want you to demonstrate your knowledge. They’re hiring you because their model needs to get better, and the only way it gets better is if humans identify the gaps and fill them with high-quality data.

Your job, at its core, is quality control and gap detection. You’re looking at model outputs and asking: Where did this go wrong? What did it miss? What does it think it knows but actually doesn’t? And then you’re writing responses that show the model—or, more precisely, the training pipeline—what a correct, complete, expert-level answer actually looks like.

This requires a specific kind of thinking. You need to resist the urge to just “write a good answer.” Instead, you need to interrogate the model’s attempt first. Find the failure modes. Spot the hallucinations, the subtle logical errors, the places where the model sounds confident but is actually making things up. Then, and only then, craft the expert response that addresses those exact weaknesses.

The people who do this well become invaluable. The people who just bang out competent answers without really engaging with why the model failed get average ratings and wonder why they’re not getting staffed on the good projects.

The SPL: Your Most Important Relationship

Every Mercor project has an SPL—a Special Project Lead. If Mercor is Uber, the SPL is the dispatcher who also happens to be your local manager, client liaison, and quality gatekeeper rolled into one.

The SPL sits between you and the AI lab client. They translate the client’s requirements into actionable guidelines for the writing team. They communicate quality expectations. They handle escalations. They’re the reason you don’t have to deal directly with a Google DeepMind product manager who has very specific ideas about what “expert-level reasoning” looks like in organic chemistry responses.

Here’s what I learned about working with SPLs: treat this relationship like you’d treat a relationship with the best manager you’ve ever had. Communicate proactively. Ask smart questions early. Don’t wait until you’ve submitted 50 tasks to find out you’ve been interpreting the guidelines wrong. If something in the project playbook is ambiguous—and something always is—raise it immediately.

The SPLs I’ve worked with have been sharp, responsive, and genuinely invested in their contributors’ success. They want you to do well because your quality scores reflect on their project. This alignment of incentives is a gift. Use it.

But here’s the flip side: SPLs are also the people who notice when you’re not meeting requirements. They track your quality scores, your throughput, and your adherence to guidelines. If you’re consistently missing the mark, they’re the ones who’ll have to bench you. So the relationship cuts both ways. Earn their trust early, maintain it consistently, and you’ll find yourself getting first pick of tasks and early access to new projects.

Respect the AHT (Or Pay the Price)

Let’s talk about the metric that governs your life on Mercor: AHT, or Average Handling Time.

Read more

I turned my recent post “OpenClaw” into a short video remix—hope you enjoy it.

Previous highlights