I’ve written before about an 11-hour trip with my son, after which my Oura ring showed lower stress than a normal day at the office. About Shadow Mode, and how Lemonade prices FSD miles at half the cost of regular ones. A couple of times, FSD may have literally saved me - I posted a clip of the car braking and pulling right seconds before a driver flew past, trying to overtake through a median island.

For me, the question of whether the technology works is basically settled.

What the closest competitor’s numbers show

Recently I looked at GM’s numbers, and they’re a good read on where the closest US competitor stands.

GM’s hands-free system, Super Cruise, has existed since 2017. Today it’s installed on roughly 750,000 vehicles. Users have driven more than a billion miles on it. The supported road network has grown to 600,000 miles.

New buyers get Super Cruise free for three years.

Then the interesting part happens.

Once the free period ends, only 30-40% of users keep paying the $25 a month.

Six or seven people out of ten spent three years driving with a technology that lets you keep your hands off the wheel, and decided it wasn’t worth $25 a month. Nine years after the product first hit the market.

We keep overestimating adoption speed

I think we constantly overestimate how fast people adopt new technology. Especially now, with AI.

Technology can be ready long before people are ready to change their habits. And at that point, the problem stops being an engineering one.

Letting go of the wheel is an act of trust.

The same pattern shows up with AI agents

I see exactly the same thing with AI agents. If an agent does the work and you check every action afterward, there’s barely any time saved. Sometimes there’s even more work than before.

The real payoff starts the moment you’re willing to hand over not just the work, but part of the control.

The bottleneck for the next few years, in cars and in companies, is trust: how fast people become willing to hand over control.

Stop thinking of an agent as something you hand a task to. Start thinking of it as a colleague: a role, a memory of everything you’ve worked on together, its own computer, the ability to hand work off to other agents without you in the loop. Close your laptop and the work doesn’t stop.

I spent most of the rest of the session doing something else entirely - recognizing our own roadmap in someone else’s slide deck.

We’ve been building toward this at Customertimes for a while now, using Cursor (Grok Bot isn’t in the stack yet) on Salesforce Spiff and SPM implementations. Four stages of delivery are already heavily automated: presales scoping, where a prospect gets a rough estimate in under an hour instead of days; solution design, where a phased build plan gets pulled straight from the client’s requirements; the actual build, where agents handle much of the system configuration themselves; and documentation and training, generated from the implementation itself instead of written up after the fact by whoever drew the short straw.

That’s the part I keep coming back to. Grok Bot already ships with its own memory. What we’re building on top of that is a second layer, our own institutional knowledge, and feeding it back into Cursor is what makes an already smart agent noticeably smarter, with a memory that goes well beyond what came out of the box.

Any enterprise software shop accumulates hundreds of small lessons over the years - the kind that never make it into a wiki page, that a good consultant just knows in their bones. Which steps have to happen in a specific order, and which ones you can reorder without consequence. Which shortcuts save you a day now and cost you three weeks later. Which configurations look perfectly fine in the sandbox and quietly fail the moment they touch production. And how you actually check that the result is right, as opposed to how the documentation says you’re supposed to check it.

For decades that knowledge lived in people’s heads. Every new team learned it the same way the last one did - the hard way, usually on a client’s dime.

We can capture it once now. Every agent on every project gets to start from what the last twenty implementations already taught us, instead of starting from zero.

On our first production run with this model, we cut both effort and delivery time by a wide margin, and in the same project reconciled several thousand compensation statements against the client’s actual payout data without anyone doing it line by line.

There’s a boundary worth being explicit about here. Agents get the width of the work. Humans keep the judgment - the business calls, the interpretation of ambiguous rules, the sign-off before anything goes live. That part hasn’t moved, and I don’t expect it to for a while.

Cursor’s right that the paradigm shifted. Where I’d push back a little is on what matters most about it, for a consulting business specifically.

The easy part to build is agents that work continuously, collaborate, and take on harder tasks without supervision - every vendor will have a version of that within two years. The harder part to copy is what happens when that machinery runs into twenty years of implementations, mistakes, edge cases, and the judgment calls only a room full of senior consultants would know to make.

For a professional services firm, that accumulated experience has always been the asset, even when nobody could put a number on it. It just used to live in people’s heads, in scattered documents, in whoever happened to be staffed on a given project - useful to the people in that room, gone the day they left the company.

Now it doesn’t have to stay there. It can sit underneath every agent, on every engagement, from day one.

Good agents plus knowledge nobody else has. That’s the combination I think actually moves the number on what consulting costs to deliver, not the agents by themselves.

The Coldcard Q looks like it was designed by cryptographers with a persecution complex. Every part of it answers the question “what if someone actually tries to steal this?” Some of what’s packed in:

• Fully air-gapped: no Wi-Fi, no Bluetooth, no USB. Transactions get signed only via microSD, QR code, or NFC.

• A Secure Element that holds private keys in an encrypted zone, inaccessible even if someone cracks the case open.

• Two independent chips from two different manufacturers, with cryptographic functions split between them, compromising the device means breaking two separate hardware architectures at once.

• Anti-tampering: the device logs attempts to open it. Pull it out of a safe and see the indicator light in the wrong color, and you know someone tried.

• Open-source firmware, so anyone can audit it themselves instead of taking the company’s word for it.

• An e-ink screen and a mechanical keyboard - no extra sensors, no side channels to leak through.

• AA batteries instead of a built-in one: you can power it down completely and know it’s silent, and batteries won’t leak and ruin the internals over time.

• A manual entropy input on the random-number generator, you’re supposed to roll dice and type in the result yourself. I was surprised how many “hack the standard RNG” videos are floating around on YouTube; the fear behind this feature isn’t paranoia, it’s precedent.

• Anti-supply-chain protection: sealed factory packaging, with firmware checked for tampering before use.

• A Brick-Me PIN and a Duress PIN - instant wipe, or a fallback into a fake wallet.

• Decoy wallets, where you can stash a small real balance to hand over if someone forces the code out of you.

The Q looks like a retro calculator on the outside, and it actually runs a calculator mode and a built-in flashlight. The discreet mode isn’t a design flourish, it’s part of the threat model. It’ll also hold encrypted secure notes: backup phrases, instructions, seed fragments, key reminders locked behind the same PIN mechanism guarding your coins.

It’s not a comfortable device to use day to day. But it’s a working manual on cryptographic paranoia, built into a case with AA batteries, a snitch LED, a calculator, a flashlight, and notes nobody can read without your PIN.

How “don’t trust, verify” broke at step one

Coldcard built its reputation on Don’t Trust, Verify. Open-source code, reproducible firmware, the ability to check everything yourself.

The problem turned out to be in the very first action: generating the seed phrase.

Coldcard gave you three options: trust the hardware random number generator, add dice rolls on top of it, or build the seed entirely from dice. That last option meant not trusting the hardware at all. Almost everyone picked the default anyway - press the button, trust the device.

In 2021, a bug shipped in the firmware that disabled the hardware randomness generator. In its place, the device fell back to MicroPython’s weak software generator. No warnings appeared. Users got a normal-looking set of 24 words: checksum passed, wallet restored, and the words could sit on a metal plate for years.

But a seed’s security isn’t in the words, it’s in the entropy, the size of the space they were drawn from. On some devices that space shrank to roughly 40 bits, on others to 72. Still huge numbers for a person, but reachable for a well-organized brute-force attack.

Galaxy Research estimated around 1,367 BTC, close to $90 million, was drained from vulnerable addresses.

That’s when I went and checked my own Coldcard. Sure enough, my version was exactly the vulnerable one. Rolling dice for honest entropy was something I’d been too lazy to do back then, I pressed the button like everyone else. Lucky twice over: there wasn’t much money in the wallet, and it wasn’t touched.

There’s a separate story here about AI’s role. Coinkite itself suggested the attacker may have found the bug through AI analysis of the open-source code while the company’s own AI audit, run just weeks earlier, found nothing. The defender has to catch every bug. The attacker only needs one.

For years, the assumed threat to cryptography was quantum computers. But nobody broke Bitcoin here, and nobody brute-forced a full 256-bit key.

What got broken was weak generation, caused by an ordinary code bug, quite possibly found and scaled with the help of AI.

Reproducible builds proved the firmware matched the source code. They never proved the code itself was safe.

Why the paranoia was earned, the numbers keep climbing

Since that first estimate, Galaxy Research has tracked the fallout across three separate attack waves. The first hit on July 30, draining roughly 1,083 BTC from about 1,200 addresses in just 41 minutes. A second wave surfaced days later, and a third - with a noticeably different transaction pattern, possibly a different actor working the same weakness pushed the running total to 1,367 BTC across 4,585 addresses, worth close to $88.6 million at time of writing. Galaxy says the activity may still be ongoing, and that coins taken so far have sat untouched in attacker-controlled addresses rather than being moved or cashed out. The drained coins had been sitting dormant for years on average, this looks like long-term self-custody holders, not exchanges or institutions.

Some reporting says the Mk4/Mk5/Q line escaped this particular bug entirely; Coinkite’s own advisory says otherwise, specifically flagging Q seeds generated before firmware 1.5.0Q or Edge 6.6.0QX. The honest answer is: it depends on exactly which firmware your seed was generated under, and that’s not something to take on faith from a headline, it’s something to check on the device.

Which brings the story back to that dice-roll entropy input. It’s the one feature on this list that isn’t about defending the device from an attacker, it’s about not needing to trust the device’s randomness in the first place. Coinkite itself now says seeds backed by at least 50 independent, honest dice rolls aren’t exposed to this flaw at all. I used it going in mostly because it seemed like the “hardcore” option. Turns out it was the only one actually built for a world where the manufacturer can ship a bug like this and where the defender has to catch every bug, and the attacker only needs one.

I’m the cofounder and managing partner of Customertimes, a 1,000-person firm that helps Fortune 500 companies implement AI. Before this, I spent almost a decade in pharma leading technology transformation projects. That combination means I’m in the room for two different conversations most people never see side by side: the public one about layoffs, and the private one about what AI actually costs and delivers.

Almost none of the CFOs, CIOs, and CEOs I talk to every week tell me, privately, that they’re replacing people with AI. The gap between that private conversation and the public narrative is exactly why the hysteria around AI layoffs reads so strangely from the inside.

What’s actually happening: AI as cover, not cause.

Long before generative AI, companies were already automating repetitive work through robotic process automation. The underlying goal hasn’t changed: find the inefficient process, automate the routine part, free people from work nobody wanted to keep doing manually.

What I actually see now is companies using AI as the explanation for restructuring that was coming regardless. A process stops making sense, leadership had already planned to reorganize it. There’s nothing unusual about reorganizing for efficiency, businesses have always done that. The problem is honesty: a lot of these companies aren’t straight with their employees or shareholders about what’s actually driving the decision.

The money doesn’t go where people assume.

The public story is simple: cut headcount, pocket the savings, hand leadership a bigger bonus. What I see behind the scenes is messier.

CFOs and CIOs tell me constantly that they underestimated token costs, and plenty of organizations have burned through a year’s AI budget in a few months, some describe it as “token maxing,” spending accelerating far faster than the productivity gains that were supposed to justify it. On top of that, companies are investing heavily in keeping proprietary processes and trade secrets out of public models, building separate internal AI infrastructure specifically to protect that knowledge. None of that is cheap, and none of it shows up in the “AI saves money” headline.

So when a company announces layoffs in the same quarter it reports record profit, the assumption that the savings landed in executive pockets is often just wrong. Infrastructure, token bills, and licensing eat a lot of it before it ever reaches a bonus pool.

People want to see where the money went and they’d back a fair split.

In the survey behind this interview, 86% of adults said companies saving money through AI should pass some of that savings on as lower prices for consumers. That’s a reasonable bar, and it’s one most companies aren’t answering at all.

My actual recommendation to the executives I work with: publish something simple showing where the AI savings went. Into employee bonuses. Into lower prices. Into reinvestment. Pick one, be specific, show a number. When a company stays silent instead, it creates a vacuum and a vacuum always gets filled, usually by the least charitable explanation available. Stay quiet long enough and the conspiracy theory about you gets written whether you show up to correct it or not.

What AI can’t take off your plate and what it can hand back to people.

AI is genuinely excellent at repeatable, structured work. You can automate a CEO’s earnings presentation with an AI avatar today. What you can’t automate is accountability, the decision to restructure, the responsibility for the people affected, the judgment call on where the savings actually go. That’s still a human in a chair.

And I’d push back on the assumption that AI mostly makes people less necessary. At Customertimes, we invest heavily in AI training, and I’ve watched testers and business consultants pick up new AI-driven skills in a matter of weeks. The pattern I actually see isn’t people becoming less valuable, it’s people becoming capable of delivering a lot more than they could before.

If your company has gone through AI-linked layoffs, were you ever told where the savings actually went or did you have to guess?

Run teams with French, Irish, American, and Asian colleagues at the same time, and you learn fast: the same words don’t land the same way twice. What one person hears as straightforward feedback, another hears as an attack.

Trust works the same way. Some people close a deal on a handshake. Others won’t move without a signed document for the smallest commitment. I’ve watched trust get built on completely different foundations, and none of it fits neatly into a company policy.

Persuasion is where this gets personal.

I used to think that being right was the finish line. It isn’t even the starting line. The real test comes when you have to get other people to accept a view you’ve built from your own experience and judgment, and arguing just to prove yourself correct is a bit like shouting louder in a crowded room. It might grab attention for a moment, but if you don’t understand what’s actually driving the other person, you’re just burning energy.

Everyone carries a set of beliefs shaped by their environment, their history, and a hundred invisible threads connecting them to the world. If you actually want to shift someone’s thinking, you have to see things from where they’re standing first, get at what’s motivating them, not just what they’re saying out loud. That takes patience and real listening: asking questions, sitting with the answers, digging for the substance under the words instead of arguing with the words themselves. Only once you genuinely understand their position can you start shifting it by choosing arguments that actually reach both their reasoning and their instincts.

This matters even more with people who are older or more experienced. Their views are the product of years of testing, failing, and winning, they don’t move for someone who’s merely correct. Influencing that kind of conviction takes tact, a long timeline, and sometimes swallowing your own ego to get there. This is the same instinct Erin Meyer’s The Culture Map names directly: in some cultures, open disagreement is just how ideas get tested while in others, it reads as a threat to the relationship itself. You don’t persuade by winning the argument. You persuade by knowing which map the other person is reading from before you open your mouth.

Hiring follows the same logic. Employment-at-will in the US gives you room to move fast and course-correct. Try that same instinct in much of Europe, where bringing someone onto a small team is a slow, deliberate commitment, and you’ll misfire badly. None of this is written in an HR manual. It’s absorbed, the way you absorb a language.

So when Anthropic published new research on how Claude behaves across languages, it read like my own team to me.

Anthropic looked at roughly 300,000 real conversations and broke down the values Claude expresses along a few axes - one of them running from warmth to rigor. In Hindi and Arabic, Claude leans warm: encouraging, affirming, generous with praise. In Russian and English, it leans rigorous: it questions assumptions, pushes on details, and asks you to back up your claims.

Nobody sat down and coded that in deliberately. Claude absorbed it from the same place it absorbed grammar and vocabulary: from millions of human conversations in each language, each carrying its own default manners. Russian directness. The softer diplomacy built into Arabic disagreement. American ease. The training data didn’t just teach the model words; it taught the model how people in that language typically choose to disagree, encourage, or hold back, the same unwritten rules I’ve spent years reading in my own teams.

The researchers gave a version of the example I’d give from my own work: show the same business plan to two people, one working with Claude in Hindi and one in Russian, and they’ll likely walk away with different impressions of how good that plan is, and it’s not because the plan changed, but because the tone of the assessment did.

That’s the part that stayed with me. I stopped expecting one management style, or one style of persuasion, to travel cleanly across every office years ago. I didn’t expect to find the same pattern showing up in a language model trained on the collective output of the people I was managing.

We built the culture into our teams by living inside it for years by learning, the hard way, that being right and being convincing are two different skills. Claude built its version by reading us. Either way, the map Erin Meyer drew for humans turns out to describe something real happening one layer down, in the machine that learned to talk by listening to all of us at once.

Claude Science

On June 30, Anthropic released Claude Science, an AI workbench for scientists, combining databases, coding tools, compute, and research workflows in a single environment.

The problem it’s solving is real and specific. Anyone who has done serious computational research knows the daily grind: dozens of databases, each with its own schema and query language. You’re not doing science, you’re doing logistics.

Claude Science aims to remove that friction. The platform comes preconfigured with access to more than 60 scientific databases and includes specialized tools for genomics, proteomics, structural biology, single-cell research, and chemistry.

The architecture is built around full provenance. Every output includes the exact code, execution environment, plain-language description, and message history that produced it, enabling reproducibility months later. That last part matters more than it sounds. Reproducibility is science’s chronic illness, and Anthropic is aiming directly at it.

A coordinating agent hands tasks to specialist sub-agents, while a separate reviewer agent checks every citation and calculation and fixes errors as it goes. The reviewer is doing something that should have existed years ago: internal peer review before the paper leaves the lab.

Data stays on the researcher’s own infrastructure. Large and sensitive datasets go nowhere, only the context needed for each analytical step is sent to Claude.

One early case study: Manifold Bio uses Claude Science to nominate targets for experiments evaluating surface expression, trafficking, and safety for each tissue and target, then ranking candidates according to criteria learned from their own internal data. They say ordinary coding assistants can’t do this end-to-end.

Claude Science is not a new AI model. It runs on the same Claude models available to paying subscribers, including Opus 4.8. The bet here is entirely on workflow, not raw model capability. That’s a more honest position than most AI product launches take.

The bigger move

But the product wasn’t the main story.

Alongside Claude Science, life sciences leaders Eric Kauderer-Abrams and Jonah Cool announced that Anthropic would run its own internal drug discovery program, targeting neglected diseases that traditional biopharma companies wouldn’t pursue.

This is the unusual part. The standard playbook is: AI company builds tools, pharma companies do the drug hunting. Anthropic is collapsing that division.

Kauderer-Abrams said the reason is simple: “We need to live it along with all of you. We believe in the power of tight feedback loops, and there’s no substitute for having our own experiences alongside you all in the trenches trying to develop drugs.”

There’s a logic to it. If you’re selling workflow tools to biopharma, having your own programs gives you credibility and a real feedback loop. You can’t build the right instrument if you’ve never played the music.

As a public benefit company, Anthropic says they “can choose programs on patient benefit, including work the commercial market overlooks.”

That framing - public benefit, neglected diseases, the patients the healthcare system discards first is deliberate. The healthcare system is optimized for scale and standardization. Rare diseases get cut early. Not enough patients, no profitable target, but the burden for those living with it is completely real.

The infrastructure behind the bet

In April, Anthropic acquired Coefficient Bio, a stealth New York-based startup, in an all-stock deal valued at just over $400 million. The team is fewer than 10 people, most of them former Genentech computational biology researchers, and joins Anthropic’s Healthcare and Life Sciences division.

Coefficient Bio’s co-founders, Samuel Stanton and Nathan C. Frey, both came from Prescient Design, Genentech’s computational drug discovery unit, where they worked on experimental design for scientific discovery and contributed to projects including Cortex, a modular deep learning architecture for drug discovery.

Anthropic has also opened wet labs to run its own basic research. This is not a software company making announcements about biology. They’re building actual laboratory infrastructure.

Kauderer-Abrams was hired with an explicit mandate: make Claude the dominant AI model in biology. “We want a meaningful percentage of all of the life science work in the world to run on Claude, in the same way that that happens today with coding.”

The financial context: Anthropic is currently valued at $965 billion, more than any health company except Eli Lilly, and has filed confidential IPO paperwork.

The honest assessment

I’m watching all this with genuine interest, but I’m staying clear-eyed.

OpenAI launched GPT-Rosalind in April 2026 - a model specifically fine-tuned for biological reasoning. OpenAI’s own LifeSciBench, built with 173 PhD scientists, found that even the best-performing model cleared only 36.1% of real research tasks. OpenAI’s own life sciences lead acknowledged that AI cannot yet create new disease treatments on its own.

The broader picture is harder. Since 2019, roughly $60 billion has poured into AI drug development. Around 175 programs have reached clinical trials. Not a single FDA-approved drug has come out of it yet.

The harder problems- training models on ambiguous biological ground truth, building causal understanding of disease, identifying the right patients for the right drugs are still in early innings.

What Anthropic has that most of the earlier wave didn’t: a foundation model that genuinely reasons, wet labs creating real feedback loops, a team with Genentech-level computational biology credentials, and the financial firepower to stay in the game long enough for it to matter.

The bet is that combining foundation model reasoning with wet-lab feedback loops and biotech operational expertise can compress timelines across the board. Whether the ten-fold acceleration materializes will depend on how fast the training data problems get solved, and whether the models can learn to go beyond human knowledge by closing the loop with experimental results.

That’s the question worth watching. Not the product launch. The question of whether Anthropic can change the picture in a space where the rest of the industry has so far fallen short.

I’m curious what you think. Is this move different or are we watching another well-funded wave that will break the same way the last $60 billion did? Drop your take in the comments.

It’s the primary interface through which dozens of my processes flow, the console where I spend a genuinely embarrassing share of my waking day. I don’t open it to do a task anymore. I open it the way you open a laptop lid: it’s just where the work happens.

And this morning, it wasn’t there.

X filled up within minutes with jokes about a forced digital detox - people half-celebrating the sudden, unasked-for vacation. I laughed too. Then I went quiet, because the laughter was covering something that wasn’t actually funny. I had built so much around a single endpoint that when it blinked, a meaningful slice of my day blinked with it.

We’ve Seen This Movie Before

The feeling was oddly familiar, and it took me a minute to place it. Then it landed: this is the early SaaS era all over again.

I remember the first wave of serious Salesforce rollouts. For a lot of companies, Salesforce didn’t stay a “nice CRM.” It became infrastructure: the spine that sales, support, and reporting all hung from. Which was fine, right up until it wasn’t. When something broke and the red indicators lit up on the status page, trust didn’t erode gradually. It collapsed. Clients got nervous. The market reacted. Stocks dipped on a status-page incident, because everyone understood, all at once, how much was riding on a single dependency.

Anthropic is sitting in roughly that same spot now. The growth is genuinely fantastic. But growth like that drags a heavy companion behind it: responsibility for reliability. In the consumer world you can ship fast and apologize later. In the enterprise world, trust isn’t won by a brilliant demo, it’s earned over years of boring, uneventful uptime. One great quarter of capability does not offset one bad morning of unavailability, at least not in the part of the brain that signs renewal contracts.

That’s not a criticism of Anthropic. It’s just the tax that comes with becoming critical infrastructure. Everyone who gets there pays it.

But the outage pushed me toward a sharper, more personal question, the one that isn’t really about Anthropic at all.

How Dangerous Is a Single AI Operating System?

How exposed am I, actually, building my work around one AI OS?

The question got sharper because of something else that happened recently: a new model I’d been admiring, that I’d had maybe a couple of hours to fall a little in love with got blocked before I’d even finished exploring what it could do. So now I have two failure modes stacked on top of each other: the platform can go down, and the capability I’m depending on can simply be withdrawn from under me. Neither of those is in my control. Both of them are load-bearing.

Here’s my actual stack, laid bare:

• Claude Code - my primary tool. The console.

• Codex - used almost exclusively for code review.

• Cursor - the thing that first opened the door to vibe coding for me, and now my familiar fallback.

• Gemini Coding Assistant - haven’t even tried it yet.

And the unsettling part: I have colleagues already shipping major Salesforce projects almost entirely through Cursor, no separate developers, no separate testers. The whole pipeline collapsed into one person and one tool. Incredible leverage. Also a single point of failure wearing a cape.

So the logical question writes itself: if one platform goes dark, how fast can I actually move to another and keep working?

Because the honest answer this morning was “slower than I’d like,” and that’s the gap that matters.

Maybe the real answer isn’t picking a better single tool. Maybe it’s refusing to have a single tool at all - building my own console and, more importantly, my own skills around a panel of several tools. Including, crucially, ones that don’t live on anyone else’s cloud.

Which Is Where the Home Lab Comes In

Almost a year ago I wrote about a half-serious idea I couldn’t shake, the Emergency GPT Kit. The premise was almost post-apocalyptic: a compact, offline box of local models you could pull out when the internet was gone, the cloud was off-limits, and your phone was just an expensive dead weight. A first-aid kit for the mind. The last library on earth. I framed it as a story about survival and taking back control, and I’ll admit I half-filed it under “fun thought experiment, no promises to build it.”

And that morning it stopped being a thought experiment.

Because here’s the thing: I’d already started, almost without admitting that’s what I was doing. I recently ordered a pair of ASUS Ascent GX10 units for my home lab. Only one has arrived so far, but I’ve already spun up several open-weight models on it, and the first impression genuinely surprised me.

Subjectively, last year’s ChatGPT is already achievable locally. Right here. On a quiet little box on my desk. It runs fast, it’s compact, the power draw is modest, and the noise is almost nothing. A year ago that sentence would have been a press release. Now it’s just Tuesday.

Let me be clear about what it is and isn’t. It is not a replacement for Anthropic’s best models, not even close, not yet. The frontier is the frontier, and local hardware is a generation or two behind it by definition. But for a large share of my routine processes, the unglamorous middle of the workload that just needs to happen reliably, it’s already a perfectly viable backup loop. A second engine. Something that keeps turning when the primary one stalls.

That reframes the Emergency GPT Kit entirely. In the original piece I described it as insurance against catastrophe: grids failing, the long emergency, society degrading slowly over decades. All still true. But the version I actually need is far more mundane and far more immediate: insurance against a Tuesday morning when the API is down and the work still has to ship.

The Health Angle Made It Personal

There’s one category where I’ve decided the local-first approach isn’t optional, it’s the whole point.

I’m going to start analyzing my DNA and health data locally, first, before anything else. Partly that’s about privacy, which should be reason enough. But partly it’s because the frontier-hosted option for that kind of work has been narrowing: the most safety-restricted variants have been pulled back from answering medical questions at all. Whatever the reasons for that and I understand there are real ones, the practical effect on my side is the same: a capability I might want is gated or gone, on someone else’s schedule, not mine.

A local model that’s “good enough” and available beats a frontier model that’s brilliant and off-limits for the question I actually have.

And this connects to something I think about more than I’d like to admit: the slow drift toward process-oriented medicine, the kind shaped less by curiosity and more by what an insurance workflow will reimburse. The standardized path is efficient. It’s also, by design, allergic to the non-standard question, the weird symptom, the off-pattern hunch, the “what if it’s actually this” that a good doctor follows and a billing code does not. An offline, unfiltered tool I control is, among other things, a way to keep asking those questions when the system around me is optimized to skip them.

The Emergency GPT Kit is becoming a normal, sensible part of staying capable and independent.

What the Outage Actually Taught Me

We’re meticulous about backing up the wrong things.

We back up files. We back up photos. We carry a spare tire and keep a flashlight in a drawer. But over the last few years we quietly outsourced thinking itself: memory, navigation, research, drafting, increasingly judgment to services that live somewhere else, behind someone else’s status page. And we almost never back that up. When the server hiccups, our cognition hiccups with it. That’s a strange thing to have let happen.

So here’s where I’ve landed, watching my “operating system” come back online a few hours later as if nothing happened:

The AI-native company of the near future won’t be judged only by how well it uses AI. And neither will the educated, capable individual. The differentiator, the thing that separates the resilient from the merely impressive, is going to be the ability to keep working when the next model, API, or cloud suddenly isn’t available.

Capability is becoming abundant. Continuity is becoming rare. And continuity is the part you have to build yourself, on hardware you own, with skills that don’t expire the moment a connection drops.

What’s in your Emergency GPT Kit?

Nadella describes the architecture beautifully. Private evals, fine-tuning environments, a retrieval layer over institutional memory. The system that compounds over time, the one that stays yours even when you swap the underlying model. All of that is real and worth building.

But there’s a step before all of it. Before the system, before the retrieval layer, before any of that infrastructure - someone has to capture something worth capturing. And that part is harder than the tooling, because it can’t be automated. It might be the one thing in this whole conversation that genuinely can not.

What actually gets lost

I’ve been working in consulting long enough to watch a lot of knowledge disappear.

A project closes. The people on it move to the next engagement. The lessons, the ones that actually mattered, the client dynamic that almost tanked it, the architecture choice that turned out to be right for reasons nobody fully understood at the time - none of that makes it into the retrospective. The retrospective covers what shipped, not why things went the way they did.

Months later, a similar project starts. Similar client, similar configuration, similar early warning signs. Nobody connects the dots, because there are no dots to connect. The knowledge was there. It just wasn’t in a form anyone could use.

I don’t think this is a consulting problem specifically. I think it’s what happens by default when organizations are moving fast and capture is always someone’s lowest priority.

The decisions that don’t reduce to process

There’s a specific category of knowledge that’s hardest to hold onto.

It’s not the process knowledge: how to run a discovery workshop, how to structure a go-live plan. That gets documented, eventually. It’s the judgment knowledge. The calls that weren’t obvious. Whether to push back on a client scope request or absorb it. Which early signal in a project actually predicts trouble six months out. Why a particular customer relationship held through a difficult moment when others didn’t.

Ask someone who made one of those calls well why it worked. You’ll get an answer, but it won’t be an algorithm. It’ll be a story with context: what was happening at the client, what the options actually were, what they decided to discount and why. That story is the thing.

A language model can summarize a decision after the fact, but it can’t reconstruct the judgment that was present at the moment of it - the uncertainty, the alternatives that were seriously considered and dropped, the information that was available but turned out not to matter. That exists only in the person who was there, and only briefly.

The idea I’ve been testing

So I’ve started doing something I’m calling a Resolution Library, though “library” makes it sound more organized than it is right now.

The practice is simple: when a significant decision closes, write it down while it’s fresh. What was happening, what the options were, what got chosen and what got rejected, and crucially, the reasoning at the time. Not the polished version, but the actual thinking.

Then, when the outcome is clear, sometimes a month later, sometimes two years, go back and close the loop. What happened? Where the reasoning held and where it didn’t.

That’s it. No special tool. It’s a habit, not a system.

The honest reason I’m writing about this rather than presenting it as a solved method is that it’s genuinely hard to keep up. There’s no immediate return, the discipline it requires is dull, and there’s always something more urgent. I’ve missed entries I wish I had. I’m not holding this up as something I’ve perfected, more as something I’ve become convinced matters enough to persist with despite the friction.

Why this is Nadella’s argument taken to its source

The previous post ended with the question: how does your company accumulate experience through AI in a way nobody else can copy?

The Resolution Library is one attempt at an answer, specifically for the kind of experience that’s hardest to commoditize. The judgment knowledge. The record of what happened at the actual decision points, before and after.

Nadella’s test for whether you have a real learning loop is whether you can swap out the model without losing the company-veteran expertise built into the system. That expertise has to come from somewhere. It doesn’t emerge from the volume of transactions or aggregated usage data. It comes from the reasoning behind the calls that actually shaped outcomes and captured at the moment they were made, in a form that can be used.

There’s a piece by Usman Sheikh at Framebreak that frames the same stakes through Federer: he won 54% of the points he played and nearly 80% of his matches. A small edge, consistently held at the right moments, produces a dramatically different aggregate result. Not every point matters. Win the ones that do.

That’s the selection problem the Resolution Library is trying to solve, capturing the decisions that actually determine outcomes, which is a much shorter list.

Part of that is because I’ve spent the last few weeks deep in the Cursor ecosystem, watching how fast things move when AI actually gets embedded into a workflow instead of bolted onto one. Reading Nadella’s framing made it concrete: what’s happening right now, in record time, is a full rebuild of the operating system businesses run on. Not an upgrade. A rebuild.

“A frontier without an ecosystem is not stable.” - Satya Nadella

That’s the thesis in eight words. Everything else in the essay is him unpacking it.

The two kinds of capital

The core idea is what Nadella calls “capital in tokens.” His argument is that every company now carries two distinct forms of capital.

The first is human capital what he describes as the knowledge, judgment, relationships, ingenuity, and pattern recognition of a company’s people. Nothing new there. We’ve always known this mattered.

The second is new: token capital. The proprietary AI capability a company builds and owns, as opposed to what it simply rents through an API.

The counterintuitive part: the obvious read is that as token capital scales up, human capital becomes less important. Machines do more, people do less, value shifts accordingly. Nadella’s argument flips that completely. In his own words, human capital does not become less valuable as token capital grows, it becomes more valuable.

Human capital doesn’t get cheaper as AI gets stronger. It gets more expensive.

Why AI alone just spins its wheels

Think about what AI actually does without a human steering it. It optimizes whatever target it’s given, inside whatever boundaries it’s given. But it doesn’t decide which problems matter. It doesn’t connect a customer complaint in support of a roadmap decision in a product to a phrase in a sales deck. It doesn’t notice that the real issue isn’t the one anyone asked about.

That’s still entirely a human job. Without it, AI doesn’t fail loudly, it just runs in circles, confidently. It produces a lot of output that looks like progress and isn’t.

“Without human direction, you have compute running in circles.” - Satya Nadella

Put simply: AI without people is just expensive servers heating up the atmosphere. Impressive electricity bill, no compounding value.

The real competition isn’t about picking the best model

This matters for anyone actually running a company, not just watching one from the sidelines.

Every major tech player is now building on remarkably similar underlying technology. The model landscape is converging fast what was a meaningful gap six months ago is closing. So if everyone has access to roughly comparable horsepower, “which model did you pick” stops being the differentiator.

Nadella’s sharpest point is that the real competitive question is learning system you build on top of it.

Your workflows. Your accumulated edge cases. Your institutional scar tissue from the deals that went sideways and the processes that finally worked. All of that, fed back into a system that gets better every time someone uses it, that’s the actual asset. Not the model. The loop around the model.

Nadella actually gets specific about what that loop is made of, which is rare for a CEO essay like this. He lays out three layers: private evaluations that measure whether the model is improving against outcomes the business actually cares about, not just public benchmarks; private reinforcement-learning environments that let the model get stronger from real traces of work inside the company; and a retrieval layer that makes institutional memory searchable and usable. Stack those three together and you get a system that compounds with every cycle of use - what he calls a hill-climbing machine.

“Unlike most assets, it compounds.” - Satya Nadella, on the hill-climbing machine

Most balance-sheet assets depreciate the moment you buy them. This one is built to do the opposite.

I’d go as far as saying we need a new metric entirely: something like AI-learnability - how fast and how well a company’s internal systems improve from each interaction. I suspect that number will end up correlating with business outcomes more tightly than almost anything else we currently track.

And this only works if knowledge is captured in a form an agent can actually use, not buried in someone’s head, not scattered across six tools, not living exclusively in a quarterly deck. It means fine-tuning on your real cases, your real failures, your real customers. Not generic, abstract data that could belong to anyone.

The sovereignty test

Nadella gives this loop a name worth sitting with: the new IP of the firm. And he offers a concrete way to test whether you actually have one.

Can you swap out a generalist model: switch providers, upgrade versions, whatever without losing the accumulated, company-specific expertise your system has built up? If the answer is no, you don’t have a learning loop. You have a rental agreement with extra steps, and your “institutional knowledge” lives entirely inside someone else’s model weights.

The framing is simple but it’s a genuinely useful filter for decision-making. You can delegate a task. You can hand off entire chunks of execution.

“You can never offload your learning.” - Satya Nadella

That’s the line Nadella keeps coming back to. You protect the learning like it’s the whole company. Because increasingly, it is.

A warning from the 2000s

This is what turns the argument from a nice metaphor into an actual warning and it’s not me reaching for a parallel, it’s the one Nadella draws himself.

We’ve run this experiment before. In the 2000s, GDP numbers looked perfectly healthy on paper while entire industries were quietly hollowed out by outsourcing. Manufacturing left. Jobs disappeared. The aggregate statistics stayed calm while the underlying structure of entire economies shifted somewhere else, slowly enough that nobody panicked until it was already done.

Nadella’s warning is that the same pattern is available again, just with frontier AI models instead of factories: a small number of dominant models absorbing the specialized knowledge of entire industries and selling it back at commodity prices, while the companies that generated that knowledge end up with none of the value. A company or a country that becomes fully dependent on someone else’s model, with no internal loop of its own, is outsourcing its future capability while the dashboard still looks fine.

This matches what I’ve been seeing elsewhere

This connects directly to something I’ve written about before: value accumulates with whoever owns the outcome, not whoever sells the tool. The tool is increasingly commoditized. The outcome, the actual compounding result inside a specific company - isn’t.

It also explains something I’ve been watching closely: the AI-trainer market. Why is it growing right now, specifically? Because the companies pulling ahead understand that human capital inside the building is exactly what makes “capital in tokens” function at all. Someone has to teach the system what good looks like. That’s a human job, and right now it’s an underpriced one.

This is the part of Nadella’s formula that actually makes it work in practice. Capital in tokens, on its own, is inert. It only compounds when it’s paired with the human judgment that knows what to feed it and what to ignore.

So what does this actually mean for you

Everyone will have access to roughly the best model, eventually, on roughly the same terms.

The companies that come out ahead are the ones building their own internal learning system right now - their own quality benchmarks, their own fine-tuning loops, their own corporate knowledge base that an agent can actually query. Two or three years from now, that compounding advantage won’t be something a competitor can buy with a subscription. It’ll be structural.

The real question now is how your company plans to accumulate its own experience through AI, in a way nobody else can copy.

That’s the real moat.

That’s what AI trainers on Wall Street are charging right now.

Saw it on Bloomberg last week. Sounds crazy until you run the numbers.

Twenty to thirty bankers in the room. That’s roughly $1,000 a head. For an investment bank, that’s two hours of one analyst’s time. If the team comes out 10-20% more productive, it pays for itself before end of quarter.

The mass replacement story isn’t playing out the way people expected. What’s actually happening: a new line item showed up on the P&L. And with it, real demand for people who can explain AI to other people - clearly, practically, in a way that makes them want to actually use it.

It brought back one of my first big projects.

SAP CRM rollout for a large pharma company. I went in thinking the hard part was the configuration.

I was wrong.

The technical work ended up being maybe half the job. The other half was harder: flying to dozens of countries, building training for teams with completely different skill levels, figuring out how to get people engaged who had no real reason to care, and somehow making them want to use something that just made their jobs more complicated at first.

We ran experiment after experiment. KPIs or recognition? Mandatory rollout or voluntary adoption?

The answer was always the same: find the people inside the company who already believed in the technology before anyone asked them to.

In the SAP world we called them power users. Anthropic calls them ambassadors - I joined that program. Cursor runs hackathons for the same reason.

The name changes. The pattern doesn’t.

Those people got up at internal events, showed their results, shared what clicked, and ended up being the real reason their colleagues got on board. They moved the needle more than any top-down mandate ever did.

Same thing is happening now in Agentforce deployments.

The technical setup takes weeks. Getting two hundred people to actually open the tool every day takes months. The rollouts that stick aren’t the ones with the cleanest architecture. They’re the ones where someone inside the client org got genuinely excited, showed their team what was possible, and made everyone else feel like they were falling behind.

One person who actually believes in the tool moves faster than six months of mandatory training.

The firms that get this are hiring for it deliberately - not waiting for champions to show up, but finding them early and building around them. That’s a different kind of implementation work. And it gets paid differently.

Last month, at Techflow in Miami, I caught a Claude Code talk aimed at beginners.

The presenter did something genuinely hard: made the tools make sense to a completely mixed room, in a way that made people want to try it right then. Not just understand it - try it.

That skill is rarer than it looks.

Twenty years. The technology has changed completely.

People haven’t.

Companies keep buying new tools expecting results overnight. But between the purchase and the actual payoff, the same thing always gets in the way: changing how people work.

The AI trainer, AI coach, and AI transformation market is just getting started.

It’s the clearest money that will be made on AI - right after data centers and hardware.

For AI companies, the race that matters most right now is who helps thousands of people actually change the way they work.

I’d paid $99, gotten a polished consumer interface, and walked away with almost nothing useful on the health side. The one genuinely interesting detail: a distant cousin who turned out to be another tech guy at Microsoft in Seattle. We probably shared 0.3% of our DNA and had never crossed paths. The internet works as intended.

Everything medical is heavily constrained by the FDA. The outputs land at the level of “slightly elevated Alzheimer’s risk” and “asparagus smell perception.” Those restrictions haven’t loosened since. So the file sat there, doing nothing, for five years.

A friend eventually pointed out the obvious: I was sitting on 600,000 data points and had done exactly nothing with them.

The raw 23andMe file isn’t a summary. It’s a dense text file full of SNPs: Single Nucleotide Polymorphisms, which sounds like a graduate seminar topic but just means: tiny places in your DNA where you differ from other people. One letter changed out of three billion. Multiply that by 600,000 and you have a surprisingly complete map of your biological quirks.

Used right, those SNPs tell you about disease predisposition, metabolic patterns, drug response, ancestry and ancient population origins, even distant connections to known historical lineages. The data was always there, but I never got to it.

Doing this properly used to require real bioinformatics fluency: Plink, VCF files, genome assembly builds, bash scripts, a stack of reference databases. Weeks of learning before any real output. Not impossible, but enough friction that almost nobody outside a research lab was doing it for themselves.

So I opened Claude Code in the terminal and typed one line:

“Here’s my 23andMe file. Check hereditary disease risk, pharmacogenetics, and parse nutrition and metabolism notes.”

That was it.

Claude identified what was needed, pulled the right tools and databases on its own, and built the pipeline. I didn’t write a single bash script. I didn’t configure a genome build. I didn’t spend three days reading documentation for a tool I’d use once.

The databases it pulled in:

• ClinVar - hereditary disease variants

• PharmGKB / CPIC - drug compatibility and metabolism

• GWAS Catalog - risk associations for diabetes, heart disease, and other conditions

• 1000 Genomes - comparison against modern global populations

• Ancient DNA databases - tracing ancestry against ancient peoples and migration paths

By the end of the weekend I had a personal report I can re-run anytime, no third-party service, no subscription, nothing leaving my machine. I saved a section of it for my doctor to put in the chart.

What I actually found:

Specific drug metabolism patterns: the pharmacogenetics piece turned out to be the most immediately practical. Some people process certain compounds fast, some slow, some atypically. I fall outside the standard range on a few things that are worth flagging before any new prescription gets written.

Elevated risk on a few conditions. I’m not listing them here both because it’s personal and because the framing matters a lot. Genetic risk is probabilistic. A raised number isn’t a diagnosis, it’s a signal to pay attention to a particular area. There’s a big difference.

Ancient Eastern European and Slavic lineages running deep. The ancestry section cross-referenced against ancient DNA migration patterns and placed my ancestors in specific regions across thousands of years. That part was more quietly fascinating than actionable, but seeing where your people were 4,000 years ago is one of those moments that’s hard to describe.

Variants affecting tolerance to certain medications - distinct from the metabolism patterns, but related. The kind of thing that’s genuinely useful to have documented somewhere.

My honest take: genetics isn’t a verdict.

Most SNPs only give probabilities. They aren’t diagnoses, they aren’t certainties, and without a sober reading of what the numbers actually mean, it’s very easy to spiral into anxiety over nothing. I’d recommend going in with that framing locked in, or doing it alongside someone: a doctor, a friend with a biology background who can help you contextualize what comes back.

That said, I found the whole thing genuinely valuable, the information actually exists now, in a form I control, that I can hand to a doctor and have it mean something.

Without Claude Code I’d have burned weeks just on tooling, probably given up, and the file would still be sitting there.

With it, the whole thing came together over two weekends.

I’m now looking for a lab to do a full genome sequence. 23andMe only covers a small fragment, around 0.02% of your actual genome. The rest is inference and approximation. Full sequencing gives you the complete picture, and the cost has dropped far enough that it’s no longer an exotic expense.

When that file comes back, Claude Code is the first thing I’m opening.

And yet, most people I respect still don’t post. So I’ve been thinking about why.

The stories we tell ourselves

Many friends and colleagues ask me how to start building their brand and producing content. When I try to understand what’s actually stopping them, it almost always traces back to something absorbed early, not a decision, more like a rule that never got questioned. Don’t brag. Don’t overshare. Don’t make yourself a target. The underlying message we absorb is that being visible is dangerous. Say something good about yourself and you’re showing off. Share something useful and someone might just run with it.

But in practice, it doesn’t work that way. Knowledge and experience almost always only produce results in combination with context, with trust, with the relationship that forms when someone reads your thinking and recognizes something true in it. Sharing a framework doesn’t hand over the years it took to build it. If anything, it demonstrates them.

The deeper fear: looking ridiculous

One of the most paralyzing fears isn’t failure, it’s actually embarrassment. The fear of looking ridiculous. Its roots often go back to childhood: bullying, the perfectionism of always needing to get it right before raising your hand, the social cost of being “that person” who overshares.

Where is the line between sharing and embarrassing yourself? Honestly? Nobody knows. And that uncertainty is exactly the problem. In language learning, the people who progress fastest aren’t those who study the longest before speaking. They’re the ones who start speaking before they’re ready, absorb the feedback, and adjust. Content works exactly the same way.

I’ve seen this in clay pigeon shooting, which I’ve practiced for years. When I was teaching a friend recently, his first rounds were rough, almost no hits. But I could see the real progress: better stance, smoother gun movement, cleaner tracking, more deliberate preparation before the shot. The clays weren’t breaking yet, but the mechanics were improving with every round. That’s not empty encouragement, that’s a coach’s eye recognizing that micro-shifts predict outcomes, even when the scoreboard doesn’t show it yet. When everything finally came together, the clays started breaking consistently.

Content is no different. The early posts feel clumsy. The engagement is low. But something is happening under the surface: you’re developing your voice, learning what resonates, building the habit. Most people quit before the clays start breaking.

The trap of two attempts

I’ve written about this before - the mistake of judging a strategy by two attempts. You go to one conference: “conferences don’t work.” You send ten LinkedIn messages: “LinkedIn doesn’t work.” But someone did reply. Someone did read your post. That’s a signal that didn’t exist before you tried. These are small but real shifts. In business, we often cut too early, right at the moment when the mechanics are starting to click.

The same logic applies to content. Meaningful skill: in shooting, in archery, in writing, in building comes from repetitions plus attention to small changes. Not from two tries followed by a verdict.

What actually works

If you’re not confident enough to share your own ideas yet, start by sharing opinions on other people. Become the person others come to for a take. Engage with people you respect - comment on their posts, ask a real question, enter their orbit. This is low-risk, high-signal activity. It builds your presence without requiring you to claim expertise you don’t yet feel.

And then: post the thing that scares you a little.

Working on content daily for a couple of years, I’ve noticed that the strongest responses never come from the polished, carefully reasoned posts. They come from the ones that contain a contradiction, or an acknowledged vulnerability, moments where I admit I don’t have it figured out. Half the readers like it. Half react negatively. But that generates far more resonance than posts everyone simply nods at and scrolls past.

Training the muscle

In sports psychology something I’ve read extensively because shooting and archery have taught me a great deal about mental performance: there’s a lot of emphasis on neutral response after a bad shot. Don’t grimace. Don’t sigh. Don’t curse under your breath. Each of those small reactions trains your brain to expect failure. Instead: neutral face, calm body, attention immediately to what’s next.

The same muscle applies to content. I deliberately put myself in situations where I might look ridiculous, because the fear of embarrassment, left untrained, will quietly veto every idea you have before it reaches the page. Looking stupid isn’t the worst thing. Never starting is.

Like any skill, this gets easier with repetition. Entrepreneurs I know who are also serious amateur athletes tend to understand this intuitively. The ability to absorb a loss, extract the lesson, and focus on the next attempt is exactly the same in business as it is in sport. And it’s exactly what content creation requires.

One post this week

Start with one post. Maybe the one that feels uncomfortable to publish. The one where you’re not sure how it’ll land. That discomfort is information, it usually means you’ve said something real.

Personal brand isn’t built in a campaign. It’s built in the reps. And the people who seem like they “got lucky” with their audience? They made a hundred attempts, paid with time and effort, survived dozens of misses, and kept going.

The clays eventually start breaking. But only for those who keep shooting.

Read it the way you’d read a leaked board deck. Because that’s what it is.

Email is dead. Slack is the company.

Calvin received about 10 emails the entire year. Everything else was Slack.

Dozens of workspaces. Layered permissions. Hundreds of channels. If you don’t curate notifications aggressively, you drown by week two.

For a company that tripled headcount in twelve months, this is a deliberate choice. Email is too slow. Slack gives speed, and at OpenAI speed beats order.

That’s not a tooling preference. It’s an architectural decision about how decisions get made.

One monorepo. No style guide.

Most of the code is Python - FastAPI plus Pydantic. There’s Rust where latency matters and a little Go.

There is no enforced style guide. In one file, a clean engineering library written by a former Google veteran. In the file next to it, a one-off Jupyter notebook from a PhD who joined last month. Things break more often than they should.

Tests that touch GPUs can take 30 minutes even when parallelized. The backend monolith has become a landfill, the place everything gets dumped because it’s the path of least resistance.

If you’ve worked at a hypergrowth product company, none of this surprises you. The only difference at OpenAI is the dial is turned to maximum.

Duplication is a strategy, not a bug.

This is the part that breaks every MBA framework.

Calvin counted at least 6 internal libraries doing the same job - task queues, agent loops, the basics. Codex existed in 3 to 4 parallel versions from different teams before launch. ChatGPT Connectors followed the same pattern.

Why?

Because there is no central architecture team. Researchers operate as mini-CEOs: they come up with an idea, build a prototype quickly, and ask almost no one for permission. If the prototype works, a team coalesces around it. If it doesn’t, the project quietly dies.

The math is brutal but logical. The cost of three teams writing the same queue library is small. The cost of three teams coordinating on whose queue library to use is enormous, measured in months, not engineer-weeks.

OpenAI buys speed by paying for duplication. Most companies do the opposite and wonder why nothing ships.

Knowledge lives in three places.

Slack. Code. People.

When Calvin asked about the quarterly roadmap, the answer was: “that doesn’t exist.”

Not “we’re working on one.” Not “ask your manager.” It doesn’t exist.

A huge amount of the company’s actual operating context sits in employees’ heads and Slack threads. That’s why the best research managers there aren’t planners, they’re synthesizers. People who can connect twelve disconnected experiments into a coherent product story.

When Codex needed two senior engineers from the ChatGPT team, it got them the next day. No staffing committee. No quarterly resource planning. No reorg memo.

That’s not casual. That’s the system working as designed.

The MBA inversion

If you took every operating principle business school teaches, OpenAI did the opposite. On purpose.

1. No single source of truth. Knowledge is distributed by design.

2. No centralized documentation. Code and Slack are the documentation.

3. Teams duplicate code instead of coordinating endlessly. Cheaper.

4. Slack replaces half the processes the rest of the world calls “operations.”

While speed beats order, this works.

That’s the load-bearing assumption and it’s worth saying out loud because most companies running this playbook think the model is the playbook. It isn’t. The playbook only holds while the marginal value of a shipped product feature is higher than the marginal cost of organizational debt.

For OpenAI in 2026, that math is wildly in favor of speed. New product surface. New customer segment. A research model that keeps getting better. Every quarter, the cost of waiting is larger than the cost of duplication.

That’s not true for most companies. It’s barely true for most labs.

The 10,000-person question

OpenAI is not Google. It’s not a classic enterprise software company. It’s a research lab that accidentally shipped the most viral consumer product in history and is now selling, in parallel, to enterprises and to governments.

Meta hit this exact operating wall around 10,000 people. The duplication tax stopped being affordable. Coordination overhead became the bottleneck, and the company restructured to absorb it.

OpenAI will hit the same wall. The only question is when.

If you’re a founder reading this and copying the playbook because OpenAI is winning - be careful. The playbook is the consequence of a specific stage and a specific kind of business. It’s not the cause of the winning.

For now, the model holds. Slack is the org chart. Researchers are mini-CEOs. Duplication is policy.

Most enterprise wisdom about “scaling” might be expensive folklore until the headcount forces someone to find out.

It migrates.

Andrew Ng just named something I’ve been seeing on every engagement for the past year: AI-native teams don’t move faster than traditional ones. They move differently.”

Roles blur. The engineer is also the product manager, the designer, sometimes the marketer. Sales prototypes their own demos and ships proposals without engineering. A team of 2–5 closes work that used to take 20.

But the part Ng added that matters most, and the part most of the AI productivity discourse keeps skipping, is this:

When one function accelerates by 10–100x, the slow ones become the constraint.

The speed of any process is limited by its narrowest point. Right now that point isn’t the model. It’s adoption..how fast actual humans inside an actual organization learn to use these tools.

The bottleneck isn’t inside the dev team. It’s at the seams. Between engineering and every function that didn’t accelerate with it.

The 10x dev team inside a 1x company

This is the part I keep watching play out at every Big Four engagement, every enterprise rollout, every consulting deal in the last twelve months.

A development team adopts Claude Code or Codex. Velocity jumps 3–5x within a quarter. Tickets close faster. PRs ship in hours instead of days. The CTO presents the numbers at the next board meeting. Everyone claps.

Then the work hits the next desk.

Procurement still takes six weeks to approve a vendor. Legal still wants the same redlines on the same MSAs. Compliance still runs the same review cycle on the same risk matrix. Marketing still books the same launch slot eight weeks out. The client’s IT team still needs three change-control boards.

Engineering compressed eight weeks of work into one. Everything around it stayed for eight weeks. So the cycle time for a delivered, paying outcome didn’t move at all. The team just sits idle longer, waiting on the rest of the org to catch up.

This is what Ng is naming. And it’s the thing nobody on the engineering side wants to say out loud, because saying it means the productivity story gets a lot more complicated.

The 10x dev team inside a 1x company is not a 10x company. It’s a 1x company with very fast engineers and a very tall pile of finished features waiting in line.

The generalist of 2026

Ng’s answer is the part most consulting partners haven’t internalized yet: generalists.

Not the generalist of 2018 - the “full-stack” engineer who could touch the database and the UI. The generalist of 2026: someone who can write the code, make the product call, talk to the client, draft the contract, and close the proposal themselves.

The math is brutal, but it’s not new. McKinsey ran on it for 70 years. A senior partner is a generalist with judgment, they’re the ones who scope the work, sell it, run it, and sign it. Below them, the pyramid was specialists. AI is collapsing the pyramid because the specialists are now the generalists. Code is one tool in their stack. Legal review is another. Client comms is another. None of them require a dedicated headcount anymore.

What this means in practice

Four shifts I’m watching the Big Four figure out one painful quarter at a time.

1. Don’t hire a specialist if a generalist with AI can do the job.

The headcount cuts at the major firms this year aren’t about partners being the bottleneck. They’re about the work below the partners no longer requiring the seniors who used to feed them. The base of the pyramid stopped existing. The top followed.

2. Accelerate the whole process, not just engineering.

The agent platform plays from the consulting side: pre-built agents for procurement, legal review, claims processing, vendor onboarding, audit testing, KYC, supplier risk and those aren’t dev tools. They’re seam-removers. Engineering already moves. The smart firms are now de-bottlenecking everything around it.

That’s the actual thesis behind the partnership announcements I’ve been writing about all year. It’s not “more code shipped.” It’s “fewer queues between functions.”

3. The metric isn’t team utilization. It’s how fast value reaches the client.

Most consulting firms still measure people on chargeable hours and utilization. That metric was designed for a world where labor was the input and time was the output. Both halves are wrong now.

The right question is: from the moment a client says “yes,” how many calendar days until they’re seeing value? Six months ago that number was 90+ in most enterprise deals. The teams that have collapsed it to 30 are eating shares. The teams still quoting 90 are getting cut from the shortlist by the same procurement teams that used to love them.

4. Speed up dev without speeding up everything else, and you just hit the wall faster.

This is the hardest one to internalize, because it goes against every dev-team-led narrative of the last three years. “We adopted Claude. Engineering velocity 5x.” Great. Your client onboarding still takes 11 weeks. Your sales cycle is still 4 months. Your contracts still close at 6. The only thing you speed up is idle time.

The honest part

What I appreciated most in Ng’s post: he was honest about the cost.

“I realize these shifts to job roles are tough to navigate for many people.”

Mildly put.

For consulting, this is a paradigm shift. Thousands of people built careers on deep specialization in a single function - tax, audit, M&A diligence, pricing, ServiceNow administration, change management, SAP integration. Most of those careers were premised on the idea that the specialty was the moat. The specialty is now an API call inside someone else’s prompt.

A generalist with AI is more valuable than a deep specialist without one. That’s not a prediction. That’s the rate card I’m seeing on actual deals being signed in 2026.

“Golden age of learning and building,” Ng calls it. Agree.

But only for the people willing to learn.

For everyone else, this is going to be very hard.

Knowledge gets cheap. Judgment gets expensive. And the bottleneck just moves to whoever refuses to move.

Last week, Google ended the argument with a checkbook.

At Cloud Next ‘26, Google announced a $750 million fund to help consulting firms: McKinsey, Accenture, Deloitte, BCG, Bain, PwC, Capgemini, TCS roll out agentic AI to their clients. Largest single partner investment ever from a hyperscaler. And it lands in the middle of a wave:

• McKinsey launched a joint working group with Google the same week.

• OpenAI formed “Frontier Alliances” with McKinsey, BCG, and Accenture in February and is selling Codex through Accenture, Capgemini, and PwC.

• Anthropic put $100M into its Claude Partner Network and another $200M into a PE vehicle to embed Claude in portfolio companies.

• Microsoft announced its own partner initiative the day before Google’s.

If AI were killing consulting, none of this would be happening. The labs would go direct. They’re not. They’re paying consultants to be the front door.

AI is not replacing consulting. It’s merging with it.

The raw models coming out of frontier labs are not enterprise-ready. Someone has to connect them to actual data, build the guardrails, design the rollout, fit them into how teams already work.

The model doesn’t know your industry. Doesn’t understand your compliance constraints.

Consultants do. That’s the gap. And the economics show how big it is: for every $1 a customer spends on Google Cloud, partners capture up to $7.05 in services revenue. The cloud is the loss leader. The services around it are the business.

The numbers inside the firms back it up. McKinsey says roughly 40% of its work is now GenAI-related. BCG was at 20% in 2024 and climbing. Deloitte calls its Google commitment its largest AI investment ever - 1,000+ pre-built agents, Gemini rolling out to 100,000 of its own people. Accenture has built 450+ agents on Google Cloud and is a lead partner for Google, OpenAI, and Microsoft simultaneously.

Deal cadence has compressed too. Lab–consultant partnerships used to form when the startup hit ~$10M in revenue, 2-4 years in. Now they’re happening at $2-5M, 12-18 months in. Everyone’s racing to lock in distribution.

The market didn’t die. It compressed and reshaped.

What’s dying vs. what’s growing

Classic consulting work: research, slides, process maps, the 200-page deck nobody reads is exactly what AI is automating. Anyone whose value prop is “I synthesize 40 interviews into a PowerPoint” should be reading the room.

What’s growing is the layer above it: identifying the right business problem, packaging the AI stack into something that works in production, and taking responsibility for the outcome. That last one is the quiet moat. Frontier labs do not want to be on the hook for enterprise outcomes. Consultants have been on the hook for sixty years. It’s literally the business.

This is why McKinsey is hiring engineers, not just MBAs. The skill stack changed. The brand and client access didn’t.

The playbook

If you’re a consultant. Stop bragging about “using AI.” Anyone can use AI. Get fluent in the engineering layer - agents, evals, integrations, monitoring or get out of the delivery seat. Pick one industry vertical and one platform (Gemini, OpenAI, Claude) and go deep enough that you can architect a production system, not just a pilot. Generalists are about to get crushed.

If you’re a founder selling AI to the enterprise. Stop trying to sell directly. Consultants own the relationship, the trust, and the outcome accountability, your fastest path to revenue is being the picks-and-shovels layer under someone else’s services contract. The compressed deal timelines mean there’s a real window open right now. It will close.

If you’re an enterprise buyer. Be skeptical of any partner whose only answer is “we’ll plug in the model.” The model is the easy part. Three questions to ask before you sign: Who owns the production system in year two? Who maintains the eval suite when the model gets updated? Who pays when it breaks? If you can’t get a clear answer to all three, you’re buying a pilot, not a system.

The takeaway

The “AI will kill consulting” narrative was always too clean. What’s actually happening is messier and more interesting: the labs need a distribution layer, the enterprises need an integration layer, and the consultants who have been quietly building both for decades just got handed $750M to accelerate.

The moat is getting deeper.

You just have to know where to look.

For every dollar a company spends on software, six go to services.

That single ratio explains where the real AI opportunity lives and why the companies that figure it out early will redefine what it means to be a software business.

Julien Bek at Sequoia Capital just published a piece that crystallizes the logic better than anything I’ve read this year. His thesis: the next trillion-dollar company will be a software company masquerading as a services firm. Let me unpack why I think he’s right, what it means for how we build, and what we see at Customertimes every day that confirms it.

The Founder’s Dilemma

Every founder building an AI tool is haunted by the same question: what happens when the next model version makes my product a feature?

It’s a fair fear. If you sell the tool, you’re in a race against the model. GPT-5, Claude 4, Gemini Ultra, each release is a potential existential threat to your differentiation. But here’s the flip side that changes everything: if you sell the work instead of the tool, every improvement in the model makes your service faster, cheaper, and harder to compete with.

A company might spend $10,000 a year on QuickBooks and $120,000 on an accountant to close the books. The next great company won’t sell better accounting software. It will just close the books. The software stack becomes infrastructure. The value delivered is the outcome.

It’s the difference between being a vendor and being a business partner. It’s the difference between the tool budget and the work budget and the work budget is six times larger.

Intelligence vs. Judgement

To understand where AI is actually going, you need one conceptual framework: the distinction between intelligence and judgement.

Intelligence is rules-based work. Translating a spec into code. Testing. Debugging. Medical coding. Filling insurance forms. Screening resumes. Matching invoices. The rules can be breathtakingly complex but they are rules. Given enough data and compute, these tasks are fundamentally learnable.

Judgement is different in kind, not degree. It’s the decision about what to build next. Whether to take on tech debt. When to ship before it’s ready. Which strategic bet to make. Judgement requires experience, taste, and instinct accumulated over years. It’s what you’re actually paying for when you hire a great CFO or a senior partner at a consulting firm.

Here’s the critical insight: AI has already crossed the intelligence threshold in software engineering, and every other profession is next.

A year ago, most Cursor users treated AI as fancy autocomplete. Today, more tasks are being started by agents than by humans. Software engineering accounts for over half of all AI tool usage across professions. Every other category is still in single digits. The reason software got there first is structural, it’s primarily intelligence work. Code either compiles or it doesn’t. Tests pass or they fail. The feedback loops are tight and the outputs are verifiable.

Today’s judgement becomes tomorrow’s intelligence.

As AI systems accumulate proprietary data about what good decisions look like in a domain, the frontier shifts. What required a seasoned professional last year becomes automatable this year. The line doesn’t hold still.

Copilots and Autopilots: Two Very Different Bets

Bek draws a clean distinction that I think will define how we look back on this era.

A copilot sells the tool. Harvey sells to law firms. Rogo sells to investment banks. The professional is the customer, the AI makes them more productive, and the human stays responsible for the output. This is the right model when AI is still developing and you’re augmenting judgement, not replacing intelligence.

An autopilot sells the work. Crosby sells to the company that needs an NDA drafted. WithCoverage sells to the CFO who needs insurance, not to the broker. The customer is buying the outcome directly. No professional intermediary. The AI handles the full task.

The higher the intelligence ratio in a field, the sooner autopilots will win. And once an autopilot establishes itself in the intelligence-heavy outsourced work, it starts accumulating the data and the client trust, to push toward the judgement work over time. The copilot-to-autopilot transition is already happening. The starting position determines the trajectory.

Start Where Work Is Already Outsourced

This is the strategic insight that I think deserves the most attention from anyone building in this space right now.

If a task is already outsourced, three things are true simultaneously:

1. The company has already accepted that this work can be done externally

2. There’s an existing budget line that can be substituted cleanly

3. The buyer is already purchasing an outcome, they’re pre-trained to pay for results

Replacing an outsourcing contract with an AI-native services provider is a vendor swap. Replacing headcount is a reorg.

One of those is a procurement conversation. The other is an organizational transformation that requires board approval, union negotiation, and change management. Start with the vendor swap.

The Opportunity Map: Where the Money Is

Let me walk through the numbers that stuck with me from Bek’s piece, because the scale is genuinely staggering:

Accounting and Audit: $50-80B outsourced in the US The talent crisis here is acute and structural. Roughly 340,000 accountants have left the profession over five years while demand grew. 75% of CPAs are nearing retirement. The licensing pathway is long, and starting salaries lag tech and finance. Nobody is filling this gap except AI. Companies like Rillet are building the AI-native ERP that will close the books; Basis started as a copilot and is moving toward autopilot.

Supply Chain and Procurement: $200B+ Most enterprises only actively manage their top 20% of suppliers. The long tail, the other 80%, gets zero attention because it’s not economical to have humans do the work. Contract leakage runs 2–5% of total procurement spend. The autopilot doesn’t need to displace anyone here. It’s capturing work nobody was doing. That’s found money with no incumbent to fight.

Insurance Brokerage: $140-200B Standard commercial lines are highly standardized. The broker’s core value-add is shopping across carriers and filling forms, pure intelligence work. Distribution is fragmented across tens of thousands of small brokers running identical processes. No single incumbent controls the customer relationship. The conditions for disruption are perfect.

Recruiting and Staffing: $200B+ The largest services market on the list. The top of the hiring funnel, screening, matching, outreach, is pure intelligence. Closing a candidate and assessing culture fit is judgement. The wedge is the intelligence-heavy, high-volume work where matching is standardized. Juicebox, Mercor, and others are building across the spectrum.

Management Consulting: $300-400B This is the hardest nut to crack. Almost all judgement or so it appears. The interesting question is whether AI can disaggregate consulting into intelligence components (data gathering, benchmarking, research synthesis) and judgement components (strategic recommendations, stakeholder navigation). Automate the former, elevate the latter. The pioneers here are still TBD, but the prize is enormous.

IT Managed Services: $100B+ Every SMB outsources its IT. Patching, monitoring, user provisioning, alert triage: intelligence work running on repeat across thousands of identical environments. The existing software layer sells tools to the MSP. Nobody has yet sold “your IT just runs” directly to the SMB as a guaranteed outcome. That gap is the opportunity.

Services-Led Growth

At Customertimes, we live this thesis. Our products work because we don’t parachute in with a tool and hope for adoption. We sit with clients as integrators. We learn the process before we touch the technology.

That sequencing matters enormously. You can’t build a great autopilot for accounting from the outside. You need to understand the edge cases that break the rules. The handoffs that happen between teams. The exceptions that actually define what “closing the books” means in practice for this particular company.

Services-led growth isn’t a business model compromise. It’s a data acquisition strategy. Every engagement teaches you what good judgement looks like in that domain. That proprietary understanding is the moat that makes the eventual product defensible against the next model release.

The Window Is Open, But Not Forever

The copilot companies built in 2024 and 2025 are sitting on a paradox. They have the customer relationships and the domain knowledge. They also face the innovator’s dilemma moving to autopilot means cutting their own customers out of doing work those customers are currently paid to do.

That tension is real, and it’s slow. Which means the window for pure-play autopilots built from scratch is genuinely open right now.

If you’re building from scratch in any of these verticals, you don’t inherit the copilot’s constraint. You can sell the outcome from day one. You can structure your pricing around results, not seats. You can build your data moat around what good output looks like, not what a professional found helpful.

The ratio that started this piece - six dollars in services for every one dollar in software - is the size of the untouched market. Most of it hasn’t seen a serious AI autopilot yet.

The builders who understand that are going to build very large companies.

This post was informed by Julien Bek’s essay “Services: The New Software” published by Sequoia Capital on March 5, 2026. Highly recommended reading for anyone building in this space.

Spin up a site in minutes. Deploy to a public URL. Connect a custom domain. Pay nothing.

But that’s not the interesting part.

The world changed. Most infrastructure didn’t.

Cloudflare fits a world where agents write code, not people.

Tools like Claude Code and OpenAI Codex need environments where execution is immediate and global. The bottleneck in an AI-assisted workflow is rarely the code generation, it’s everything that comes after. The deploy. The environment setup. The debugging of infrastructure that has nothing to do with your actual product.

Traditional cloud providers were designed for a different era. An era where a DevOps engineer would spend a week setting up the right IAM roles, VPC configurations, and load balancers before a single line of application code touched production. That workflow made sense when humans were the slowest part of the system.

Now the human isn’t the bottleneck. The infrastructure is.

Cloudflare was built differently, not as a data center you rent, but as a network you deploy to. That distinction matters more than it sounds.

What’s already on the free tier

Before getting into why this matters for AI workflows, it’s worth being concrete about what you’re actually getting:

• Edge infrastructure + CDN - your app is global by default. Not “global with extra configuration.” Global on deploy.

• D1 - serverless SQL database. Runs at the edge. No connection pooling headaches. Familiar SQL interface.

• R2 - object storage that’s S3-compatible with zero egress fees. That last part is quietly significant. Egress fees are how AWS extracts margin from companies that scaled without noticing. R2 removes that trap entirely.

• Vectorize - a vector database built for AI applications. Semantic search, RAG pipelines, embeddings, the infrastructure is already there.

• Workers - serverless compute that runs in V8 isolates, not containers. Cold start is measured in milliseconds, not seconds.

• Security + DDoS protection - built in, not bolted on. Not a separate product you configure. It’s part of what Cloudflare is.

For experiments, prototypes, and early production this is more than enough. Most startups that raised a seed round are running on less.

How the agent workflow actually changes

Here’s what an AI-assisted build cycle looks like without the right infrastructure:

You prompt Claude Code to build a feature. It writes the code. Now you need to test it somewhere real. So you either run it locally (which doesn’t reflect production) or you go through a deploy process that involves environment variables, build steps, maybe a Docker container, maybe a staging environment that’s drifted from prod. By the time you’ve verified the thing works, you’ve lost the thread.

Here’s what it looks like with Cloudflare:

You prompt the agent. It writes the code. It deploys. You have a URL. You’re testing in 45 seconds.

The feedback loop compression is the product. Not Cloudflare specifically, but Cloudflare happens to be the platform that makes this possible at zero cost and near-zero configuration.

This is why I keep saying agents operate best in environments built for immediacy. Slower infrastructure doesn’t just slow down deployment, it breaks the cognitive flow of working with an agent. You context-switch. You lose momentum. The session ends.

Fast infrastructure keeps the loop tight. And tight loops produce better software faster.

The comparison

Let’s be direct about the alternatives.

Vercel is excellent and the DX is genuinely good. But it’s optimized for frontend and Next.js specifically. Once you need a database, object storage, or anything backend-heavy, you’re reaching outside Vercel’s ecosystem. The free tier is also more constrained for teams doing serious volume.

AWS is the right answer at scale. It’s not the right answer for the first 90% of a project’s life. The configuration overhead is real, the learning curve is steep, and the billing surprises are legendary. You don’t give an AI agent access to AWS and expect it to figure it out cleanly.

Railway and Render are solid for containerized apps. Good developer experience, reasonable pricing. But they’re not edge-native, and they don’t come with the integrated storage layer Cloudflare provides.

Cloudflare’s position is specific: it wins on the combination of global edge compute + integrated storage + free tier generosity + deploy speed. No single competitor beats it on all four simultaneously right now.

That might change. It probably will. But right now there’s a window.

The CMS replacement angle

There’s a direction here that most people are sleeping in.

Cloudflare is quietly becoming a backend for content-driven websites, not just apps. The traditional stack for a marketing site or content platform was: WordPress or a headless CMS, a hosting layer, a CDN on top, maybe a caching plugin.

That stack has a lot of moving parts. Each one is a potential failure point, a vendor relationship, a bill.

Workers + D1 + R2 can replace most of it. You get secure isolation of components (each Worker runs in its own V8 isolate, they can’t interfere with each other). You get a content delivery network that’s not separate from your compute, they’re the same thing. You get a database that lives at the edge, close to users.

We moved our own site there. The result wasn’t just cheaper. It was structurally simpler. Fewer vendors. Fewer abstractions. Faster.

The direction this points toward: Cloudflare as the default backend for AI-generated websites. An agent builds your site, deploys it to Cloudflare, and the entire thing as compute, storage, CDN, security is handled by one platform with one login and one (free) bill.

That’s a meaningfully different world than what we had two years ago.

The honest part

I don’t know when Cloudflare starts monetizing this aggressively. They probably will. The free tier is clearly a land-grab: get developers dependent on the platform before flipping the pricing lever.

But even if they do, the economics still likely work. R2’s zero egress fees alone make it competitive with S3 at any scale. Workers pricing is consumption-based and remains cheap at moderate volume. The free tier might shrink. The underlying value proposition probably holds.

Right now though, there’s an asymmetry - what you get for free is genuinely disproportionate to what it costs.

That asymmetry is time-limited. Use it.

The actual takeaway

Most infrastructure conversations in the AI-agent world focus on the models. Which model, which context window, which tool-use capabilities.

The infrastructure layer is underrated. Agents need somewhere to run. The environment you give them shapes what they can build and how fast they can build it.

Cloudflare is becoming the execution layer where AI-built applications go live instantly. It’s not the only option. But for the combination of speed, integration, and cost - nothing else is quite there yet.

If you’re building with AI agents and not using Cloudflare as your execution layer, you’re probably overcomplicating your stack.

The simpler the infrastructure, the faster the agent works. That’s the whole insight.

Have you moved anything to Cloudflare? Curious what you hit, both good and bad.

That’s not wrong. It’s just not interesting.

What’s interesting is what happens when you stop thinking about OpenClaw as a productivity layer and start thinking about it as an agent runtime - one that connects to tools, runs automations, controls browsers, triggers workflows, and stays always-on across the channels your teams already live in.

That reframe changes everything.

The runtime question

The conversation about AI in the enterprise has been stuck in the same loop for two years: “How do we get employees to use it?”

“How do we make sure it doesn’t hallucinate?”

“How do we prove ROI to the board?”

These are real questions. But they’re downstream of a more fundamental one:

What does it actually mean to deploy an AI agent inside a regulated industry?

Not a chatbot sitting on top of your ERP. Not a summarization tool bolted onto your CRM. An agent that can see data, make decisions, trigger actions, and operate autonomously within defined boundaries, inside industries where the cost of getting it wrong isn’t a bad quarter. It’s a regulatory event.

That’s the question NVIDIA was trying to answer when they built NemoClaw.

What NemoClaw actually does

NemoClaw is an open-source security layer built on top of OpenClaw. The architecture is worth understanding because it changes what’s possible.

Kernel-level sandboxing. Privacy routing. Default-deny networking.

The last one is the important one. The agent can’t do anything: connect to a system, access data, trigger an action unless it’s been explicitly allowed. You’re not trying to enumerate what’s forbidden. You’re defining exactly what’s permitted and locking out everything else.

That’s a compliance architecture.

For a pharma company, that means an agent that can monitor adverse drug reaction reports across global submissions can’t accidentally reach outside its defined data boundary.

For a manufacturer, an agent monitoring quality deviations on the line can’t exfiltrate production IP through an unconstrained API call.

You stop asking “how do we prevent the bad thing from happening” and start asking “what do we want to explicitly allow.”

That’s a much better question.

What this looks like in production

At Customertimes, we deploy NemoClaw for enterprise clients in manufacturing and pharma. Not pilots. Not proof of concept. Production environments wired directly agents connected directly to SAP, Salesforce, Databricks, Snowflake.

Here’s what the use cases actually look like, the real version:

Manufacturing

Quality control agents that check production output against your standards in real time. During the batch, not after. Deviations get flagged before they become recalls. The cost differential between catching a problem at inspection versus catching it post-shipment is enormous. An agent that runs that check continuously, across every line, without fatigue, is not a nice-to-have.

Predictive maintenance agents connected to your equipment data. The agent is not just reading sensor outputs, it’s comparing against historical failure patterns, cross-referencing maintenance logs, and scheduling interventions before downtime occurs. Every unplanned hour of downtime in a manufacturing environment has a real dollar figure. Usually a large one.

Supply chain visibility agents that pull across systems most companies have siloed. Instead of five dashboards and a weekly ops meeting, one agent that surfaces what’s actually moving and what’s at risk.

CPG & Pharma

Pharmacovigilance agents monitoring adverse drug reaction signals across incoming reports. The volume of data in a global pharmacovigilance operation is beyond what human teams can process at the speed regulations require. An agent that reads across that corpus, identifies emerging signal patterns, and surfaces the ones that need human review is making the pharmacovigilance team actually able to do their job.

Promotional materials review agents. Marketing content in pharma has to be reviewed against approved claims before it goes out. Every piece. This is a significant operational bottleneck at most companies. An agent that runs that review, flagging non-compliant language before it reaches the medical, legal, regulatory review cycle, compresses timelines and reduces rework.

CRM and territory intelligence agents for field sales. Reps don’t need more data. They need the right data, surfaced at the right time. An agent that pulls from CRM, identifies territory gaps, and surfaces them in a rep’s existing workflow is more useful than any dashboard.

Which industry moves first

My read: manufacturing gets there before pharma, but pharma is where the value is higher.

Manufacturing has a shorter feedback loop. The ROI on preventing one unplanned downtime event or catching one quality deviation before a recall is immediate and measurable. The compliance environment, while real, is less complex than pharma. Procurement cycles are faster.

Pharma is harder. The regulatory environment is more demanding, the data is more sensitive, the approval process for any new system is longer. But the value of catching an adverse event signal early, compressing a promotional review cycle, and improving pharmacovigilance coverage is substantial. The companies that figure out the compliance architecture will have a durable advantage.

Healthcare is a different conversation. The interoperability problem is still severe enough that the agent runtime questions are secondary to the data infrastructure questions.

The real opportunity

OpenClaw by itself is a powerful runtime. There are going to be a lot of interesting things built on it for general productivity, consumer applications, horizontal tooling.

But the sustainable business value, the kind that creates real switching costs and defensible moats, is going to be built vertically. Industry-specific agent configurations, wired into industry-specific systems, operating within industry-specific compliance architectures.

NemoClaw is what makes that possible in regulated environments.

The companies that move now by building those vertical configurations, developing the implementation expertise, earning the compliance credibility, are going to be very difficult to displace in three years.

That’s the actual opportunity.

Not a prototype. Not a demo. A production system I use every day.

47 features. 13 AI tools. A vector knowledge base. LinkedIn profile enrichment. A Telegram bot as the primary interface. Automated follow-up logic. Voice memo integration. Email parsing. Trip-based contact suggestions.

It replaced my entire stack: HubSpot, Monday.com, Notion, and Zapier.

Cost: $200/month for Claude Code.

I asked Claude Code to estimate what this would cost a traditional development team.

The answer: 516 hours. $66,400. Four months. Five people: PM, PO, two developers, QA.

I did it in roughly 20 hours across several sessions.

That’s a massive cost reduction.

But the savings aren’t even the point.

My CRM is better than anything I could buy.

It’s proactive. It reminds me about contacts I haven’t spoken to in 90 days. It suggests who to reach out to before I fly to a conference. It automatically pulls LinkedIn profiles and structures them into enriched records - role, company, mutual connections, last interaction, topics we discussed.

It’s integrated with my voice recordings from meetings, my email, and my knowledge base. It knows my professional context because everything lives in one system, not scattered across four SaaS products that don’t talk to each other.

I didn’t configure workflows in someone else’s UI. I described what I needed, and Claude Code built it.

That’s the shift.

No SaaS product does this. And none will, because they’re built for everyone. Which means they’re optimized for no one.

Here’s what most people miss about this change.

The threat to SaaS isn’t AI features inside existing products. Salesforce added Einstein. HubSpot added AI assistants. Monday.com added automations.

None of that matters.

The threat is that the customer no longer needs the product at all.

A lawyer will replace Clio plus Notion with a custom AI assistant that knows case history, drafts motions in their voice, and tracks deadlines without a dashboard they never open.

A small agency will throw out Monday.com and build a project system that mirrors how their team actually thinks, not how a product team decides agencies should work.

A consultant will build a CRM and a second brain in one tool: contacts, meeting notes, deliverables, follow-ups - all connected, all searchable, all context-aware.

These aren’t hypotheticals. I just did it in 20 hours.

The math for SMBs is brutal.

Small businesses don’t have IT departments. They don’t have procurement processes. They don’t have integration budgets.

They have a credit card and a problem.

A typical SMB SaaS stack includes CRM, project management, knowledge base, automation, and email tools. That’s easily $200 to $400 per month minimum, and often more.

And you still spend hours every week on manual data entry, copy-pasting between apps, and fighting integrations that break every time one vendor ships an update.

$200/month for Claude Code replaces all of it.

And the replacement is smarter.

Not “good enough.” Smarter.

The SaaS moat was built on three things. Distribution. Switching costs. And “good enough.”

Distribution: SaaS companies spent heavily on sales and marketing because they had to make adoption easy. Free trials, freemium tiers, one-click onboarding. The product got in front of you before you asked whether you really needed it.

Switching costs: once your data is in HubSpot, leaving means exporting CSVs, rebuilding workflows, and retraining your team. The product doesn’t have to be great. It just has to be painful to leave.

“Good enough”: nobody loves their CRM, but nobody switches either. The status quo wins by default.

A custom system built with Claude Code attacks all three.

One subscription instead of a procurement process. Your code instead of someone else’s proprietary database. A system shaped around your workflow instead of “it’ll do.”

Let me be clear about what I’m not saying.

Salesforce won’t disappear tomorrow. Neither will HubSpot.

Enterprise contracts, compliance requirements, and organizational inertia still protect the top of the market.

But the bottom?

The SMB SaaS market just got a new competitor.

And that competitor is the customer.

The same person who used to compare pricing pages and watch demo videos now opens Claude Code and says: “Build me a CRM that works like this.”

Twenty hours later, they have something better than what they were paying thousands per year for.

This is the multiplier applied to software itself.

Not just using AI to write code faster. Using AI to eliminate the need for someone else’s code entirely.

Every month, the models get better. The context windows get longer. The tools get more capable. The 20 hours I spent today will be 10 hours in six months and 5 hours in a year.

The SaaS industry built a massive market on the assumption that building software is hard.

That assumption just expired.

I broke down the five major platforms fighting for enterprise AI agents: Databricks Custom Agents, Salesforce Agentforce, Microsoft Copilot Studio, AWS Bedrock AgentCore, and Google Vertex AI. Each has clear strengths and clear lock-in risks.

If you missed it: Part 1

Part 1 told you what each platform does. This part tells you which one to pick and more importantly, what matters beyond the platform itself.

The 3-Question Decision Framework

After deploying AI agents across multiple enterprise environments, I’ve learned that platform selection comes down to three questions, not fifteen.

Feature comparison matrices are comforting. They make you feel like you’re being thorough. But they optimize for the wrong thing. They compare what platforms can do, not what they should do for your specific situation.

Here’s what actually drives the decision:

This isn’t laziness, it’s physics. An AI agent’s value is directly proportional to its proximity to the data it needs. Every extra hop between agent and data adds latency, integration complexity, and failure points. In production, these add up fast.

A common mistake: choosing a developer-first platform and then expecting business users to build agents. Or choosing a no-code platform and then being frustrated when your ML team can’t customize the reasoning layer. Match the platform to the people, not the other way around.

If your answer is “not yet, but probably within 18 months” - treat it as a yes. Protocol support is much easier to start with than to retrofit.

The Interoperability Question: MCP vs. A2A

This is the section most platform comparisons skip. It might be the most important part for the long term.

Two protocols are emerging as standards for AI agent communication:

MCP (Model Context Protocol)

Created by Anthropic. Handles agent-to-tool communication. Think of it as the USB standard for AI agents - a universal way for agents to connect to tools and data sources. Already has 10,000+ active servers and 97 million monthly SDK downloads. This is not theoretical. It’s infrastructure.

A2A (Agent-to-Agent Protocol)

Created by Google. Handles agent-to-agent collaboration. Agents discover each other, negotiate capabilities, and coordinate tasks across organizational boundaries.

Both protocols are now governed by the Linux Foundation’s Agentic AI Foundation, co-founded by OpenAI, Anthropic, Google, Microsoft, AWS, and Block. These aren’t proprietary standards anymore. They’re becoming industry infrastructure.

Open-Source Frameworks That Actually Work

Before you commit to a platform, know that some of the most production-ready agent frameworks are open source. They won’t replace a platform, but they handle the agent logic layer and they give you portability.

The critical distinction

Open-source frameworks give you agent logic. They don’t give you production infrastructure - deployment, monitoring, security, governance, memory. That’s what enterprise platforms provide. The pragmatic approach: use open-source frameworks for agent logic, deploy on an enterprise platform for everything else. Databricks Custom Agents explicitly supports this pattern - build with LangChain locally, deploy to Databricks Apps without rewriting code.

What This Means for Pharma, Healthcare, and Manufacturing

Generic platform comparisons miss the constraints that regulated industries face. Let me get specific about the industries I work in.

Pharma

Top priority: Governance and validation

Any AI agent that touches GxP-regulated processes needs audit trails, version control, and validated infrastructure. AWS (GxP compliance tooling) and Databricks (Unity Catalog lineage) are strongest here. Salesforce Agentforce is ideal for commercial/sales ops but doesn’t cover manufacturing or quality.

The emerging use case: Multi-agent systems where a drug safety agent (monitoring adverse events) coordinates with a regulatory submission agent (preparing FDA filings) and a commercial agent (adjusting physician outreach based on safety signals). No single platform handles all three today. That’s why protocol interoperability matters.

Healthcare

Top priority: HIPAA compliance + clinical data integration

Microsoft has the strongest healthcare story (Teams for Health, Nuance/DAX integration, Azure Health Data Services). AWS is a close second. Google’s multimodal capabilities - an agent that processes medical imaging alongside clinical notes -- are uniquely valuable for clinical AI.

The cautionary note: We just saw what happens when AI prescribes medications without adequate safeguards (the Doctronic debacle in Utah). Any healthcare AI agent must have robust human-in-the-loop capabilities. Google’s mid-workflow pause and Salesforce’s Atlas hybrid reasoning (LLM + business rules) address this directly.

Manufacturing

Top priority: OT/IT integration + real-time processing

Manufacturing agents need to interact with PLCs, SCADA systems, MES platforms, and IoT sensors. None of the five platforms handle this natively - you’ll always need integration middleware. AWS (IoT Core + AgentCore) and Google (multimodal + BigQuery for sensor data) are closest.

The Siemens + NVIDIA angle: Their partnership to build AI-driven manufacturing sites using digital twins is creating a parallel ecosystem. Manufacturing AI agents may ultimately run on industrial platforms (Siemens Xcelerator, Rockwell Plex) rather than cloud-native agent frameworks. PepsiCo is already seeing 20% throughput gains with this approach. Watch this space closely.

Most organizations won’t use just one platform.

A pharma company might use Agentforce for commercial operations, Databricks for manufacturing analytics agents, and AWS for GxP-validated quality agents. A healthcare system might run Copilot Studio for administrative workflows, AWS for clinical AI, and Google for medical imaging agents.

Multi-platform is the reality. Which is why interoperability protocols (MCP, A2A) will matter more than any single platform’s feature list within 18 months.

And here’s the truth that no vendor will tell you:

The platform is 20% of the effort. The other 80% is data readiness, integration architecture, governance design, and change management. Get the 80% right, and almost any platform will work. Get it wrong, and the best platform in the world won’t save you.

We’ve seen this pattern at Customertimes across every industry we serve. The teams that succeed don’t start with “which platform should we use?” They start with “what does our agent need to do, and is our data ready for it?”

That question sounds simple. Answering it honestly is the hardest part of any AI agent project.

The Checklist: Before You Choose a Platform

Run through these before you make a decision:

1. Map your data landscape. Where does the data your agents need actually live? This determines 60% of the platform decision.

2. Define who builds and maintains. Technical team? Business users? Both? Match the platform’s abstraction level to your people.

3. Assess cross-boundary needs. Will agents need to communicate with systems outside your organization? If yes (or “probably within 18 months”), prioritize MCP/A2A support.

4. Check regulatory requirements. GxP? HIPAA? OT security? Not all platforms have equal compliance tooling. This is non-negotiable in regulated industries.

5. Plan for multi-platform. Don’t try to force everything into one platform. Identify which platform serves which use case, and design the interoperability layer from Day 1.

6. Invest in the 80%. Before you spend a dollar on platform licensing, make sure your data is clean, your integrations are mapped, and your governance framework exists.