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.

The Agent Arms Race Is Real

Something shifted in early 2026.
For two years, “AI agents” were mostly a buzzword.
Then, over the span of a few months, everything dropped at once:

• Databricks launched Custom Agents and the broader Agent Bricks stack.

• Salesforce announced Agentforce 360 with autonomous multi‑step workflows.

• Microsoft rolled out multi‑agent orchestration and enhanced governance in Copilot Studio and Azure AI Foundry.

• AWS expanded Amazon Bedrock into AgentCore with a more modular architecture.

• Google enhanced Vertex AI Agent Builder and its Agent Builder SDK with MCP and emerging agent‑to‑agent protocols.

Every major platform now offers a production agent framework. The messaging is nearly identical: “Build, deploy, and govern AI agents at scale.”

But the implementations are very different. And for enterprise teams trying to ship AI agents in regulated industries, where “move fast and break things” gets you a consent decree, those differences matter enormously.

Let me break down each platform, not from a feature‑list perspective, but from the perspective of someone who has to make these things actually work.

Databricks Custom Agents

The data‑first agent platform

Databricks Custom Agents let developers build, test, and deploy AI agents as fully managed Databricks Apps. It’s the centerpiece of the broader Agent Bricks suite.

Key capabilities

• Framework‑agnostic: Build with LangChain, CrewAI, or raw Python, and deploy via CI/CD without rewriting code. Most platforms force you into proprietary tooling; Databricks doesn’t.

• Lakehouse‑native memory: Agent state and conversation history persist across sessions directly in the Lakehouse, reducing the need for a separate memory database layer.

• MCP catalog and marketplace: Early Model Context Protocol (MCP) integration so agents can discover and use tools from a curated catalog and marketplace.

• Agent Bricks (no‑code): Natural language agent creation with templates for common enterprise tasks: the business‑user layer.

• Unity Catalog governance: Every agent, tool, and data access point governed through the same catalog that manages the rest of your data estate.

My take from the field

The strongest play is the data story. If your data already lives in the Databricks Lakehouse, Custom Agents give you one of the shortest paths from data to agent. No heavy ETL, no large‑scale duplication. The agent sits directly on top of the data it needs.

In pharma and manufacturing, this matters. When a quality management agent needs to access batch records, deviation reports, and supplier data in real time, the fewer hops between data and agent, the fewer things break.

The framework‑agnostic approach also means your ML team uses what they already know. That alone can cut time‑to‑production by weeks.

Salesforce Agentforce

The CRM‑native agent ecosystem

Agentforce is no longer just a feature. Salesforce has been rebuilding its architecture around agents. It is already the commercial leader in CRM‑native agents, with Agentforce contributing meaningful, fast‑growing ARR.

Key capabilities

• Atlas Reasoning Engine: Hybrid reasoning that balances LLM creativity with structured business rules. The agent doesn’t just generate text; it follows your business logic.

• Agent Script: JSON‑based scripting for conditionals, hand‑offs, and guardrails, making implicit process logic explicit.

• Data Cloud grounding: Agents operate on structured, unified CRM data. They know your customers, pipeline, and cases, not just what’s in the latest prompt.

• Agentforce Voice: Real‑time voice agents integrated with Amazon Connect, Five9, and Genesys.

• Flexible pricing: Usage‑based and per‑user models, typically combining per‑conversation charges, per‑action “Flex Credits,” and an optional per‑user/month tier for heavier or unlimited internal usage. (Exact numbers change frequently; check the current Agentforce pricing page or recent SaaS analyses rather than relying on static figures.)

My take from the field

For sales, service, and marketing, Agentforce is the most mature option right now. The CRM data grounding gives agents context that other platforms can’t match without massive integration work.

For pharma commercial teams, it’s compelling. An agent that pulls a physician’s prescribing history, checks compliance restrictions, drafts personalized outreach, and schedules follow‑up, all within Salesforce, is a real, shippable workflow.

The limitation is real, though. The moment your agent needs to do something outside Salesforce - query a manufacturing execution system, pull data from a LIMS, check OT network status, you’re in integration territory (MuleSoft or equivalent). That’s additional cost, complexity, and risk.

Microsoft Copilot Studio + Azure AI

The productivity suite agent layer

Microsoft’s approach is two‑pronged: Copilot Studio for low‑code agent building, and Azure AI Foundry for developers. The Microsoft 365 integration is the moat.

Key capabilities

• Multi‑agent orchestration: Agents can call other agents as tools. A “project manager” agent delegates to a “data analyst” agent and a “report writer” agent, coordinating a multi‑step workflow.

• Centralized governance: Entra ID‑based identities, policies, and monitoring for agents across Microsoft 365 and Copilot Studio.

• Natural language creation: Describe what you want; the platform scaffolds an agent and workflow, with no coding required for common patterns.

• Model flexibility: Support for Claude, a wide range of models through Azure AI Foundry, and bring‑your‑own‑model options.

My take from the field

If your organization lives in Microsoft 365, and most enterprises do, Copilot Studio is often the path of least resistance. The agent is already where your people work: Teams, Outlook, SharePoint, Excel.

For healthcare organizations on Microsoft infrastructure, an agent that pulls patient scheduling from Dynamics, checks formulary info in SharePoint, and drafts a summary in Word, all without leaving the ecosystem, cuts integration complexity significantly.

The challenge is cross‑application autonomy. The moment your agent needs to act outside the Microsoft stack (and in manufacturing or pharma ops, it almost always will), you’re back to custom integrations.

AWS Bedrock AgentCore

The infrastructure‑grade agent runtime

AWS has expanded Amazon Bedrock into AgentCore - a modular service architecture designed for production at scale. This is the infrastructure‑first play.

Key capabilities

• Modular services: Distinct components for runtime (serverless deployment), gateway (unified tool and model access), memory (context retention), identity (auth), policy (Cedar‑based access control), and observability (OpenTelemetry monitoring).

• Pay‑per‑use economics: No per‑seat licensing; you pay for actual consumption: models, calls, and underlying infrastructure.

• Cedar policies: You express access control in a human‑readable way, and the system compiles that into formal Cedar policies already used in other AWS security services.

• Broad model selection: Multiple foundation models through Bedrock, plus integrations with partner and open‑weight models.

My take from the field

AWS is the most “production‑grade primitives” option. If you need enterprise security, monitoring, and compliance at scale, AgentCore gives you granular control over how agents run, what they can touch, and how they’re audited.

For pharma companies that already run validated workloads on AWS, keeping agents inside the same security and compliance perimeter is a big advantage. Cedar is particularly interesting for regulated industries that need explainable, formalized access control.

The trade‑off: this is the most “build it yourself” option. You get powerful building blocks, but assembling them into a working agent system takes more engineering than Salesforce or Microsoft.

Google Vertex AI Agent Builder + SDK

The multimodal + interoperability leader

Google centers its agent platform on Vertex AI Agent Builder and its associated SDK. Two things stand out above everything else: multimodal capabilities and a strong bet on interoperability.

Key capabilities

• Native MCP and A2A‑oriented design: Among the big clouds, Google is the most aggressive on interoperability, with first‑class Model Context Protocol (MCP) support and early patterns for agent‑to‑agent communication.

• Multimodal agents: Gemini 3 Pro‑class models process text, audio, video, and images natively, with very large context windows. Agents can “see” and “hear,” not just read and write.

• Agent Engine for memory: Short‑term and long‑term memory with topic‑based organization so agents remember what actually matters across sessions.

• Human‑in‑the‑loop: Agents can pause mid‑workflow, request human input, and then resume with full state preserved.

My take from the field

Google’s interoperability story is the most forward‑leaning. When your pharma manufacturing agent needs to communicate with your supply‑chain vendor’s agent, protocol standards matter. Google is betting on being the Switzerland of agent interoperability.

The multimodal capabilities are uniquely valuable in manufacturing. An agent that processes real‑time video from a production line, detects visual defects, cross‑references quality specs, and triggers an alert requires native multimodal processing. No other platform does this as cleanly right now.

The downside is the usual one with Google Cloud: if you’re not already on GCP, the adoption friction is real.

The Comparison at a Glance

The Pattern You Can’t Ignore

Every single platform has lock‑in risk. That isn’t a bug; it’s the business model.

The real question isn’t whether you’ll be locked in, but which lock‑in you can live with given where your data and workflows already reside.

More on that in Part 2.

What I’m Not Telling You Yet

This comparison tells you what each platform does. It doesn’t tell you which one to pick, because that depends on factors the feature lists don’t cover:

• Where does your data actually live (Delta on Databricks, Salesforce Data Cloud, S3, BigQuery, on‑prem)?

• Who builds and maintains the agents in your org (central ML team, line‑of‑business admins, external SI)?

• Do your agents need to talk to agents outside your company (CDMOs, logistics providers, payers, partners)?

• What does “production” mean in your regulatory context (GxP validation, HIPAA, FDA scrutiny, internal audit)?

Those are the questions that matter. And that’s exactly what Part 2 covers.

Sources

1. Custom Agents now available on Databricks

2. Agent Bricks | Databricks Documentation

3. Agentforce 360 Announcements - Salesforce

4. Salesforce Agentforce Pricing (SaaStr)

5. 6 Core Capabilities to Scale Agent Adoption - Microsoft

6. Amazon Bedrock AgentCore

7. Vertex AI Agent Builder - Google Cloud

8. Enterprise AI Platform Guide 2026 (Sema4.ai)

Roughly 73% year‑over‑year revenue growth.

About $62.3 billion from the data center alone.

Guidance for next quarter: around $78–80 billion.

But behind the financials is something more interesting: an organizational story most analysts miss entirely. I’ve spent the last month studying NVIDIA from two angles: as someone who ships AI workloads in production, and as a shareholder trying to understand whether this is a cycle or a structural advantage.

My conclusion: the real moat isn’t the hardware. Let me break down why.

1. Jensen Huang Runs a 40,000‑Person Company Like It’s Still a Startup

This is the part that doesn’t get enough attention.

Jensen Huang has been reported to have roughly 60 direct reports. Not six, sixty. He largely avoids traditional one‑on‑ones; instead, he prefers leadership sessions where everyone hears the same feedback at the same time. His reasoning: the more direct reports a CEO has, the fewer layers in the company and the more fluid the information flow.

Every couple of weeks, he personally reads “the five most important things” from people across the company, not just senior leaders. He’s known for reading emails at 5am and for staying personally involved in major acquisitions and exceptional hiring decisions.

He demands what he calls “speed of light” execution - benchmarked against the theoretical limits of the hardware, not just “fast” or “best in class.”

The culture follows: minimal silos, fluid teams, and people moving to whatever is most critical rather than clinging to permanent org boxes.

Operationally, that’s unusual at this scale. Most companies with NVIDIA’s footprint ($215.9 billion in annual revenue and 40,000+ employees) calcify. They add management layers, create review committees, and slow down. NVIDIA, by contrast, ships aggressive roadmaps like Blackwell on time while competitors struggle to land basic product timelines. That’s not an accident; it’s a direct consequence of this operating model.

Most CEOs at this scale choose comfort: fewer direct reports, more delegation, calendar buffer, layers between themselves and the work.

Jensen chose the opposite. The results speak for themselves. And that structural speed advantage flows directly into the next layer of NVIDIA’s moat: the way the hardware and software stack are actually used.

2. The Blackwell Number Everyone Misquotes

You’ll hear “Blackwell is 4x faster than H100.” That’s true only under specific, highly optimized conditions.

If you naively port an existing model from Hopper to Blackwell, you might only see something like a modest double‑digit uplift. You’re running new silicon with old assumptions, and the chip can’t show you what it’s really capable of.

Once you deeply optimize the stack: kernel‑level tuning, careful use of the memory hierarchy, advanced scheduling, and full use of lower‑precision modes like FP8 and FP4 where appropriate, the picture changes.

On some large‑model training and inference benchmarks, you can see roughly 3–4x speedups at the system level versus previous‑generation setups. At rack scale, with systems like the GB200 NVL72, you can see order‑of‑magnitude gains on certain inference workloads, not just from the GPUs themselves, but from the way the interconnect, networking, and software stack are co‑designed.

The exact numbers are workload‑dependent, but the pattern is consistent: the gap between a “drop‑in” port and a fully optimized deployment is huge.

That gap between naive and optimized is the moat.

NVIDIA does something here that’s hard to match at scale: they send engineers to work directly with key customers, hand‑ optimize kernels and end‑to‑end pipelines for specific workloads. When a hyperscaler like Microsoft or Meta wants to squeeze every last token per second from a Blackwell cluster, NVIDIA doesn’t just ship hardware and wave goodbye. What they do is they embed, they tune, and they co‑design the full stack.

The takeaway is simple: budgeting for hardware without budgeting for optimization is like buying a Formula 1 car and filling it with regular gasoline. The chip is only as good as the stack running on it and increasingly, that stack is where NVIDIA’s deepest advantage lives.

3. The Real Moat: CUDA and 20 Years of Software Infrastructure

Think of CUDA the way you’d think about Windows in its dominant era: if all the tools, libraries, and frameworks work best on your platform, switching becomes not just expensive but operationally risky.

CUDA isn’t a product. It’s an ecosystem. Thousands of libraries, highly optimized kernels, and frameworks so deeply integrated that the switching costs are enormous. In practice, the major ML frameworks - PyTorch, TensorFlow, JAX - tend to run best on CUDA paths today. The inference stacks that power real‑world deployments like TensorRT‑LLM, vLLM, SGLang and others, are deeply integrated with NVIDIA’s platform.

NVIDIA keeps feeding this flywheel. Open‑source families like Nemotron are released to the community, keeping developers anchored in their ecosystem. Thousands of engineers work on nothing but keeping CUDA, cuDNN, NCCL, TensorRT, and domain‑specific SDKs ahead of each new hardware generation. When Blackwell ships, the software stack is already tuned for it, you don’t wait years for the ecosystem to catch up.

Is anyone chipping away at this? Yes, and it matters.

• AMD has poured resources into ROCm, and framework support plus MLPerf participation shows the gap is narrowing, especially for buyers willing to invest in engineering.

• Compiler stacks inspired by Triton’s hardware‑agnostic philosophy are explicitly designed to make it easier to run the same kernels on AMD, Intel, and others without wholesale rewrites.

• Cerebras, pursuing a public listing, is pushing wafer‑scale systems that, on their own benchmarks, deliver over 20x higher inference throughput and around 32% lower cost per token than a DGX B200 Blackwell setup, while using roughly one‑third less power for those workloads. That’s genuinely interesting.

These are real developments. The era of NVIDIA’s near‑monopoly is shifting into a more competitive landscape.

But narrowing the gap on hardware is not the same as narrowing the gap on the ecosystem. You can design a chip that matches NVIDIA’s specs in a few years. You cannot, in two or three years, recreate the developer tooling, optimized libraries, framework integrations, and thousands of battle‑tested production deployments that live on CUDA. That takes a decade and by the time you’ve closed that gap, NVIDIA has typically moved the goalpost again.

4. The Risk That’s Real and Shared

NVIDIA now sits at the very front of TSMC’s priority queue, alongside Apple and a handful of the world’s largest chip buyers. That tells you everything about NVIDIA’s strategic importance and its single biggest exposure.

Taiwan concentration is a genuine geopolitical risk. If anything meaningfully disrupts TSMC’s operations, NVIDIA’s supply chain takes a hit.

But this risk is shared by every major AI and mobile silicon player. AMD, Apple, Qualcomm, and many others depend on TSMC’s leading‑edge nodes. If TSMC goes down, the entire advanced‑node industry is in trouble, not just NVIDIA. That means this risk is effectively priced across the sector, not unique to one ticker.

For shareholders, the more relevant question is: “In a world where TSMC keeps operating, who has the strongest structural position to capture AI economics?”

Right now, that answer still looks like NVIDIA.

5. On Competitors: A Blunt Assessment

Most NVIDIA analysis either ignores competitors or wildly overstates them. Here’s the more grounded view.

• AMD is the most credible challenger. The upcoming MI450 series is designed to go directly at Blackwell‑class workloads, and ROCm is genuinely improving. But AMD is fighting on NVIDIA’s terms, trying to close a hardware gap while also building out a software ecosystem. Playing catch‑up on both fronts simultaneously is a punishing strategic position.

• Cerebras has technically impressive wafer‑scale systems. The CS‑3 packs on the order of 4 trillion transistors and hundreds of thousands of AI‑optimized cores. On their published benchmarks, they show 21x faster inference and roughly 32% lower cost per token than a DGX B200 Blackwell system, with materially lower power, for specific LLM workloads. That’s serious, but going from standout benchmarks to hyperscale, cloud‑like ubiquity is a very different problem.

• Other players like Fireworks AI, Together AI, SambaNova, Graphcore, and more, are building useful products in specific niches, especially around serving, fine‑tuning, and verticalized stacks. They matter tactically, but they’re not yet structural threats to NVIDIA’s position at the platform layer.

Then there’s NVIDIA’s own M&A posture. The company recently struck a roughly $20 billion licensing and acqui‑hire deal for Groq’s deterministic inference technology, which it is integrating into its upcoming Rubin platform. When you’re already dominant and still spending at that scale to deepen your technology stack, not just defend it, that’s an offensive move.

For most companies, the smartest move right now is definitely not trying to compete with NVIDIA at the platform level, but building on top of NVIDIA, while keeping an eye on alternatives and maintaining enough portability to pivot if economics or geopolitics force your hand.

The Bottom Line

NVIDIA isn’t just selling GPUs. It’s selling a complete AI infrastructure stack: hardware, software, libraries, frameworks, optimization services, and a developer ecosystem that’s been compounding for roughly 20 years.

$68.1 billion in quarterly revenue. Around $78–80 billion guided for the next quarter. Mid‑70s gross margins. And a CEO who still reads emails at 5am and stays personally involved in the details that most leaders at his scale have long since delegated.

NVIDIA isn’t just winning the AI race.
It’s actually designing the track.

If this kind of practitioner‑level analysis is useful to you, it’s what I publish here. Subscribe to get the next one.

Are you building on NVIDIA infrastructure, or actively betting on an alternative? What are you seeing on the ground?

$10B+

AI investment by Big Four & McKinsey since 2023

75%

of McKinsey fees still billed by the hour

30%

research time saved by McKinsey’s AI chatbot Lilli

6-30%

drop in graduate recruiting at Big Four (2024-25)

The numbers are staggering.

PwC dropped $1 billion over three years and became OpenAI’s largest enterprise customer.
KPMG locked in a $2 billion Microsoft alliance.
Deloitte launched a $2 billion “Industry Advantage” program.
EY invested $1.4 billion and built its own proprietary LLM platform, EYQ.
McKinsey deployed an internal AI chatbot called Lilli to 72% of its 45,000 employees by 2025.

In total, the Big Four and McKinsey have poured over $10 billion into AI since 2023.

And yet almost nothing about how consulting actually works has changed.

A recent deep dive from Future of Consulting calls this out in brutal detail. I want to unpack it from the perspective of someone who actually implements AI in enterprises.

The Productivity Paradox

Here’s the number worth noting: McKinsey’s Lilli saves consultants 30% of their research time.

30%. That’s enormous. In an implementation project, a 30% efficiency gain changes your entire delivery timeline and cost structure.

But here’s what McKinsey did with that 30%: almost nothing visible to clients. The savings stay inside the firm. The billing rates don’t change. The project timelines don’t shrink. The efficiency gain is pure margin, captured by the firm, invisible to the buyer.

This isn’t a McKinsey problem. It’s a structural one. As long as most revenue is still tied to time, any tool that makes consultants faster is more likely to pad margins than to show up as better value for buyers.

When your revenue model is built on billable hours, any tool that makes your people faster is a threat to your top line unless you quietly absorb the gains.

We see this from the other side at Customertimes. When we deploy AI that makes a pharma company’s processes 30% more efficient, the client sees it immediately. They measure it. They expect it. Because we’re building solutions, not selling time.

The consulting model incentivizes hiding efficiency. The implementation model incentivizes delivering it.

Only 25% of McKinsey’s Fees Are Tied to Outcomes

The most prestigious consulting firm in the world, the one that advises Fortune 500 companies on “digital transformation,” still collects roughly 75% of its fees based on time spent, not results delivered.

Yes, about a quarter of fees are now outcome‑based and that’s real progress, but the core economics of the firm still runs on hours.

Everyone in enterprise AI knows the industry needs to move toward outcome‑based pricing. Every conference panel says it. Every thought‑leadership piece argues for it.

But the transition is stalled. And it’s stalled for a reason that anyone who’s worked inside large organizations will recognize: the people who would need to approve the change are the same people whose compensation depends on the current model.

If you’re a partner billing $500/hour and AI makes your team twice as fast, outcome‑based pricing means you now need to deliver twice the value to maintain your revenue. Or accept that the same work is worth less. Neither option is appealing when you’re two years from retirement.

The Junior Layer Is Disappearing And Nobody Has a Plan

This is the part that worries me most for the long term.

Graduate recruiting across the Big Four has been sliding, with double‑digit drops in 2024–2025 at several firms. Firms are cutting entry‑level positions because AI now handles the work juniors used to do: data gathering, initial analysis, deck formatting, research summaries.

On the surface, this sounds efficient. Why pay a first‑year analyst $85,000 to do work that GPT‑4 can do in seconds?

But consulting has always been an apprenticeship business. Juniors learned by doing the “grunt work.” They sat in client meetings. They built models that got torn apart by managers. They learned pattern recognition through repetition.

When AI drafts the first pass of every slide deck, junior staff lose the reps of structuring arguments, anticipating objections, and seeing which ideas survive partner review. That’s where the client’s judgment used to be formed.

Remove that layer, and you have a training crisis. In five years, who becomes the senior consultant? Who has the client instincts? Who can read a room and adjust a recommendation on the fly?

We face a similar challenge in enterprise AI implementation. When we automate validation workflows in pharma or quality checks in manufacturing, we need to deliberately design new learning paths for junior team members. The work that used to train them is gone. If you don’t create something to replace it, you end up with a bimodal workforce - senior experts and AI tools, with nothing in between.

In pharma implementations, for example, the junior who used to manually walk through validation logs now needs a different path to learn how deviations actually show up in the data and why QA pushes back.

PowerPoints Don’t Deploy Themselves

Here’s my biggest frustration with the current state of consulting AI: firms are using AI to produce recommendations faster, not to deliver solutions.

A consulting engagement in 2026 still ends the same way it did in 2016: a slide deck. Maybe a nicer one. Maybe it was drafted 30% faster. But the client still gets a PDF, a “roadmap,” and a wave goodbye.

Meanwhile, the client is left to actually build the thing. They hire implementation partners (like us). They discover that half the recommendations don’t account for their legacy systems, their regulatory constraints, or their organizational politics. They spend months translating strategy into working software.

The gap between “we made a deck” and “we shipped a system” is where most AI value now lives.

What This Means If You’re a Buyer

If you’re a healthcare executive, a pharma CTO, or a manufacturing leader evaluating whether to engage a Big Four firm for your AI initiative, here’s what I’d ask:

1. What are you actually buying?
   Are you buying a strategy deck or a working solution? If it’s a strategy, can your internal team execute it, or will you need another partner?

2. How is the engagement priced?
   If it’s time‑and‑materials with no outcome guarantees, you’re paying for both the consultants’ learning curve and the AI‑driven efficiency gains they’re keeping.

3. Where’s the implementation plan?
   Not just a “roadmap,” but an architecture, integration points, and a timeline that reflects your real systems and constraints.

4. What happens after the engagement ends?
   The most expensive consulting engagement is the one that produces a strategy nobody can implement. Ask who will own, monitor, and evolve the AI systems once the consultants leave, and what budget and skills that requires on your side.

The Real Opportunity

The article from Future of Consulting calls these firms “hollow cathedrals” - impressive from the outside, empty at the core. That’s a provocative phrase, and I think it’s partially right.

But here’s the opportunity: the gap between consulting recommendations and real‑world AI implementation is massive. And it’s growing.

Enterprises are increasingly building internal AI teams. They’re questioning why they’re paying consulting rates for AI‑augmented work. They’re looking for partners who deliver working systems, not slide decks.

This is exactly the shift we’ve been building toward at Customertimes for years: AI solutions that run in production, survive audits, and actually move the metrics that matter in pharma and manufacturing.

The $10 billion that consulting firms invested in AI? Most of it went toward making consultants more productive. Very little went toward making clients more successful.

That’s not an AI revolution. That’s an AI optimization of the same old model.

What are you seeing on your end?

Are consulting firms delivering real AI value in your organization: running systems, measurable lift or just better‑produced versions of the same advice?

If you’re comfortable sharing details, I’m especially interested in where a consulting AI “strategy” died in implementation, or where an implementation partner actually rescued a stalled initiative. Reply or drop a comment below.

What are you seeing on your end?

Are consulting firms delivering real AI value in your organization, or are you getting better-produced versions of the same advice?

I’d love to hear your experience, reply or drop a comment below.

On a parallel track, I experimented with voice messages: instead of cloud-based ElevenLabs, I ran local TTS models on a beefy gaming PC. For speech synthesis, the quality is surprisingly solid.

OpenClaw is not “one smart bot”

Here’s what most people miss. OpenClaw is essentially an agent orchestration framework - a construction kit with a growing ecosystem of third-party skills and an app store. You don’t get a single chatbot. You get an environment where you wire together models, memory, tools, automations, and even multiple separate OpenClaw nodes into one system.

Think of it as the difference between buying a pre-built PC and having a full electronics workbench.

And the implications are bigger than most realize. Gokul Rajaram, product veteran from Google, Facebook, Square, and DoorDash, investor in 700+ companies, just posted a thread that nails the core question: did OpenClaw + Skills fundamentally change the architecture and math of AI?

His framing is sharp. Can perpetually running agents that train themselves on new capabilities via SKILL.md files reach the same level of expertise as the hand-crafted fine-tuned models that AI startups have spent years building? If the answer is even “partially yes” and from my weekend experiments, it’s trending that way and the downstream effects are massive.

Rajaram asks what this means for horizontal AI agent builders like Glean, ServiceNow, and Sierra. What about verticals: legal, finance, healthcare? Can we have an “OpenClaw for Legal” agent trained on a contract drafting skill file that’s as capable as what a specialized AI startup offers today?

And here’s the kicker he flags: if this self-learning agent paradigm makes expensive post-training less critical, it reshapes the entire economics of the AI startup ecosystem. The pricing models, the data companies, the venture math, all of it gets rewritten.

From what I’ve seen hands-on this weekend, I’d say the shift is real. Not finished, not polished but structurally real.

Big tech noticed. And they’re not happy.

What’s telling: last week Anthropic restricted Claude Code usage inside OpenClaw. Then Google reportedly pulled Gemini access too. The reasoning is transparent - autonomous development without human-in-the-loop feels too risky to the big players, and it undermines the role of their walled-garden ecosystems.

But the genie is out of the bottle. If the major players lock down, more open alternatives will emerge. That’s how this always works.

RAG changed everything for my assistant

For my AI assistant Katrina, I added Postgres and a vector database. RAG drastically cut token consumption and kept large context windows far more stable than the old approach of stuffing everything into markdown files.

This is starting to look like a prototype of a living institutional knowledge system with semantic search, always evolving, not a dead Jira / Confluence / SharePoint graveyard where information goes to die.

Rajaram has been saying that in an agentic future, infrastructure companies become application companies because agents don’t need a software UX. What I’m seeing in practice confirms this. The database layer is the product now. The vector store is the knowledge base. There’s no UI in between, just the agent talking to the data.

The honest take

For the mass market, the product is still raw. You have to dig into code, manage security, isolate environments, fix things when they break.

But as a sandbox for experiments and for understanding how future agent systems will actually be built and this is an incredibly powerful experience.

The paradigm that previous-generation companies were built on? It already looks like the last century.

A new era of agent orchestration is starting. And it’s not waiting for permission.

If you’re experimenting with agent frameworks, local models, or building your own AI infrastructure, I’d love to hear what’s working for you. Drop a comment or reply to this email.

Databricks just raised $7 billion at $5.4 billion in annual revenue and 65% growth. Impressive numbers, sure. But what caught my attention isn’t the fundraise but what the company has quietly become.

And more importantly, what that transformation tells us about where all enterprise software is heading.

From Data Warehouse to Operating System for AI

If you still think of Databricks as a data warehouse with dashboards, you’re looking at a two-year-old snapshot.

Today, Databricks is an infrastructure platform of an entirely new class. It’s a place where you can store and process data, host modern LLMs, talk to your data in natural language, and most critically, build agentic solutions. All under one roof.

For large enterprises, this is a fundamentally different category of system. We’ve been working with Databricks in enterprise projects at Customertimes for a while now, and we see this shift from the inside every day. The platform isn’t just evolving, it’s being rebuilt around a new paradigm.

The Real Difference: Architecture Built for Agents, Not Humans

Here’s the thing that separates Databricks from legacy platforms like SAP or Oracle.

Old enterprise systems were designed for humans clicking through menus. Screen by screen. Form by form. The user interface was the product. If you wanted to automate anything, you had to reverse-engineer the UI layer, build fragile integrations, and pray nothing broke on the next update.

Databricks is built differently:

• API-first: every capability is accessible programmatically

• Open architecture: no vendor lock-in traps, no proprietary black boxes

• Agentic-ready: designed so that software can interact with it as a first-class user

This isn’t a minor technical distinction. It’s a philosophical one. The platform assumes its primary user might not be a person at all, it might be another program.

The Experiment: Zero Knowledge, Full Results

I recently ran an experiment that proved this point to myself.

I connected to Databricks through Claude Code, loaded a test dataset, and assembled dashboards with only surface-level knowledge of the platform. No documentation deep-dives. No tutorials. No certification courses.

Just an AI agent and a CLI.

The combination of agent + command-line interface genuinely changes the rules of engagement. I didn’t need to learn the platform’s UI conventions or memorize where settings live in nested menus. The agent understood the API surface, figured out the right calls, and got the job done.

This confirms something I’ve been thinking about for a while: modern systems win not because of beautiful UIs, but because of interfaces that agents can work with. The prettier your dashboard, the less it matters, if your API is solid, an agent can build whatever view a human needs on the fly.

Matching Technology to Your Stage

This also connects to something I’ve written about before: the importance of matching your technology choices to your company’s stage of development.

Databricks is a platform built for the AI era. Organizations that understand this gain an enormous advantage. They’re building their systems not on yesterday’s principles, but on the architecture of the future.

They’re not asking “what tool has the nicest interface?”. They’re asking “what platform gives my AI agents the most leverage?”

That’s a fundamentally different question, and it leads to fundamentally different decisions.

What’s Still Missing

Let’s be honest about the gap that still exists: documentation.

Almost every platform today, including Databricks, writes its docs for human developers. Step-by-step guides. Screenshots. UI walkthroughs. That’s fine for people, but it’s nearly useless for AI agents.

What agents need is different: clean API references, consistent schemas, predictable error handling, and machine-readable specifications. The platforms that figure this out first will have a massive adoption advantage.

But this is a matter of when, not if. Platform builders will catch on fast once they realize their main user is becoming software.

$7 Billion Says the Market Agrees

The $7 billion raise isn’t just an investment in a company. It’s a bet that all enterprise development and analytics will be built around AI. Databricks currently sits at the center of this new economy, offering not just a tool but an entire operating system for intelligent applications.

The market sees what’s coming:

• Enterprise platforms will be agent-first, human-second

• The value shifts from UI polish to API depth

• The winners will be platforms that treat software as their primary customer

We’re at the beginning of this transition. Most enterprise software is still stuck in the old paradigm. But the signal is clear, and $7 billion of capital says the smart money agrees.

The Question for Your Business

Here’s what I’d challenge you to think about:

What platforms in your stack are agent-ready today?

Which ones could you hand off to an AI agent with a CLI and get meaningful results without deep platform expertise?

If the answer is “none” or “I don’t know,” that’s your starting point. The gap between agent-ready infrastructure and legacy systems is going to become the most important architectural decision of the next five years.

The platforms that are built for agents will compound in value. The ones that aren’t will become the new technical debt.

What platforms are you testing with AI agents? I’d love to hear what’s working and what’s not. Drop a comment or reply to this post.