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.

And the deal count actually went down more than 10%.

Meaning fewer deals, but massively bigger ones.
Mean deal size doubled to $2.1 billion.

On paper this looks like strategic expansion.
In practice, this is an industry buying time.

The cliff nobody’s talking about

Over $300 billion in branded drug revenue is at risk from loss of exclusivity through 2030.

Not gradually. Not gently.

The growth gap hits $100 billion by 2028.
Then expands to $370 billion by 2032.

The drugs losing protection aren’t niche.
They’re blockbusters:

→ Eliquis — projected to lose >$2.5 billion a year
→ Entresto — >$2.25 billion a year
→ Stelara — >$2.1 billion a year
→ Keytruda, Merck’s crown jewel, ~$25 billion in annual revenue, loses key U.S. patent protection in 2028

When your highest-revenue product has a countdown clock, you don’t optimize R&D pipelines.

You buy.

The buying spree

Merck agreed to acquire Verona Pharma for $10 billion.
Then Cidara for $9.2 billion.

And there’s still $2.1 trillion in firepower sitting on the sidelines.
That’s not a typo. Trillion.

Record levels of available capital, waiting for the next target.

But here’s the number that should concern everyone:

Only 32% of pharma acquisitions achieved at least 100% of expected revenue targets.

Two-thirds of these massive deals underperform.

And the success rate is even worse when acquirers step outside their existing therapeutic areas which is exactly what the patent cliff forces them to do.

The AI gold rush inside the panic

AI drug discovery deal value surged in 2025.

Recursion acquired Exscientia for $688 million.
AstraZeneca partnered with Tempus AI for $200 million.

The thesis is simple.
If organic R&D can’t outrun the patent cliff, maybe AI can compress the timeline.

And it’s working for the molecule side.

AI is finding drug candidates faster than ever.
Protein folding. Target identification. Compound screening.

That part of the problem is getting solved.

The part that isn’t

At many academic centers, site activation alone can take 6–8 months.

Six to eight months before a single patient is enrolled.

The molecule can be designed in weeks by AI.
Then it sits in regulatory paperwork for years.

Paper-based enrollment processes.
Manual site matching.
Fax machines. In 2026.

AI cracked drug discovery.
Nobody cracked the paperwork.

This is where $240 billion in M&A can’t help.
You can’t acquire your way out of a 1990s regulatory infrastructure.

The China variable

While U.S. and European pharma companies were buying each other, China quietly captured 34% of biopharma alliance investment.

Up from 4% in 2020.

→ Pfizer–3SBio: up to $6 billion ($1.25B upfront)
→ Takeda–Innovent: $1.2B upfront, up to $10.2B in milestones
→ AstraZeneca–Jacobio: up to $1.91 billion
→ Bristol Myers Squibb–Harbour BioMed: up to $1.1 billion

This isn’t outsourcing.
This is a fundamental shift in where the innovation pipeline lives.

And it happened while LinkedIn was debating which free AI tool to download.

What actually matters

57 novel drugs are expected to launch in the U.S. in 2026.
Combined fifth-year sales projection: ~$50 billion.

The pipeline isn’t empty.
The problem is the space between discovery and patient.

The companies that will win the next decade aren’t the ones buying the best molecules.

They’re the ones that figure out how to move a drug from lab to patient in months instead of years.

AI-powered site matching.
Automated pre-screening from medical records and registries.
Digital-first trial enrollment.

The molecule was never the bottleneck.
The system around it is.

$240 billion spent on acquisitions.
$370 billion evaporating regardless.

And the actual chokepoint, clinical trial operations, barely gets a headline.

The biggest opportunity in pharma right now isn’t a new drug.
It’s making the old process fast enough to matter.

The 386 computer I bought with my first earnings was an entire world, but an almost silent one.

The standard PC Speaker could only beep, and buying a Sound Blaster or AdLib, which cost about a third of the computer price, was just a dream.

This feeling of limitation, when the technology exists but is incomplete, became my first real challenge.

Then on BBS, the internet equivalent of that era, my friend Anton and I stumbled upon a schematic for a Covox device - a simple digital-to-analog converter for the LPT port.

It was like finding a treasure map. The idea seemed brilliant in its simplicity, and we were fired up to build it.

What followed was a real adventure that I still remember to this day.

We traveled to the radio market, which was a universe unto itself with its own rules, hunting for the right resistors and connectors.

We etched circuit board traces with acid using a special solution - it was an almost alchemical process. Then we soldered, assembled, and checked everything against the schematic.

Then came the long process of setting up DOS drivers. Something was constantly not working, we spent hours troubleshooting, even tried modifying the code with nothing but a text editor and our own persistence.

And then came that moment. We launched Quest for Glory from Sierra.

Instead of the dreary beeping from the speaker, real sound effects rang out. Not Hi-Fi, of course, but there were the hero’s footsteps, ambient sounds, sword strikes. The world on screen suddenly came alive.

It felt like transitioning from silent film to talkies, and doing it yourself. Our joy was boundless.

This experience, which seems naive today, actually laid the foundation for my philosophy.

First, it’s about the ability to not accept limitations, but to seek solutions.

Can’t buy it - build it. Doesn’t work - figure out why.

This is the entrepreneurial spirit in its purest form.

Second, it’s about the value of deep understanding of how things work. When you’re not just a user but a creator, you see technology completely differently.

This resonates with what I’ve written about how AI is changing the work of our consultants and developers.

Even today, in the era of ready-made AI solutions, those who win are the ones not afraid to look under the hood, understand the principles, and build something of their own that’s perfectly suited to the task.

At Customertimes, we value exactly these kinds of people who are capable not just of executing tasks, but of creating new solutions.

The homemade sound card only remains in a phone photo after sorting through boxes during a move, but it taught me the main thing: the real magic of technology is born not at the moment of purchase, but at the moment when you yourself see an idea through to completion and hear the result of your work.

This feeling that you’ve made the impossible possible - that’s the main driver for any creator.

What’s your Covox moment? What technology did you build or hack together that changed how you think about creating versus consuming? I’d love to hear your stories.

The reason: a new existential risk that few are talking about openly yet - universal long-horizon agents. These are horizontal AI systems not trained on our specific domain, but capable of working on a single task for hours or even days, self-correcting and seeing it through to completion.

Then I listened to a YC interview on vertical AI agents at Sergei Bulaev’s recommendation, and the pieces started clicking together. There’s a massive opportunity in vertical AI agents right now. But the window is narrower than most people think.

The Case for Vertical AI Agents

The YC interview makes a compelling argument: vertical AI agents can significantly outperform traditional SaaS solutions because they replace not just software, but entire teams of employees. This is a fundamentally different value proposition.

The best opportunities exist in sectors drowning in bureaucratic overhead: healthcare and financial services top the list. In these industries, compliance requirements don’t just add cost, they shape entire business models. In CPG and retail, the calculus is different but equally compelling: low margins will push management toward experiments and nonlinear productivity gains that they’d never consider in higher-margin businesses.

Early examples of successful implementations include customer support automation, debt collection, medical billing, and software testing. Market penetration is still under 1%, which points to enormous growth potential. The technology reminds me of early SaaS evolution: initial skepticism about capabilities gradually gives way to recognition of advantages. But we’re seeing substantial progress every three months now, not every few years.

The future belongs to narrowly specialized solutions focusing on complete workflow automation. This could lead to unicorn companies with just a dozen employees - a radical departure from traditional business scaling assumptions.

What the Data Actually Shows

Anthropic just released their Economic Index with new “economic primitives” that measure real Claude usage across millions of conversations. The data tells a more nuanced story than the hype suggests.

First, the good news for vertical specialists: Claude completes very different kinds of tasks in countries at different stages of economic development. In high-GDP countries, Claude is used primarily for work and personal tasks, while lower-income countries use it more for educational coursework. This fits an adoption curve where AI use diversifies toward personal purposes as countries get richer - and where domain expertise becomes more valuable as adoption matures.

The concentration data is striking: even with 3,000 unique work tasks on Claude.ai, the top ten account for 24% of usage, up from 21% in January 2025. Computer and mathematical tasks dominate - a third of all Claude.ai conversations and nearly half of API traffic.

But here’s where it gets interesting for vertical AI agents: the success rates vary dramatically by task complexity and time horizon. Claude successfully completes tasks requiring a college degree 66% of the time, compared to 70% for tasks requiring less than a high school education. More complex tasks see bigger speedups: tasks requiring college-level understanding are sped up by a factor of 12, versus 9x for high school-level tasks.

The time horizon data is the critical piece. METR’s benchmark shows Claude Sonnet 4.5 achieves 50% success rates on 2-hour tasks. Anthropic’s own API data shows 50% success at around 3.5 hours, and on Claude.ai, the duration extends to 19 hours. Users can break down complex tasks into smaller steps, creating a feedback loop that allows Claude to correct course, which is exactly how vertical AI agents work in practice.

The Cursor Browser: A Wake-Up Call

Michael Truell, Cursor’s 25-year-old CEO, just demonstrated exactly what I’ve been worried about. His team coordinated hundreds of GPT-5.2 agents to build a functional web browser from scratch in one week of uninterrupted operation. The result: 3 million lines of code across thousands of files, including a from-scratch Rust rendering engine with HTML parsing, CSS cascade, layout algorithms, text shaping, and a custom JavaScript virtual machine.

Truell’s candid assessment: “It kind of works.” Simple websites render quickly and largely correctly. It’s nowhere near production-ready - browsers like Chromium have over 35 million lines of code refined by expert teams over decades. But that’s not the point.

The point is the speed of progress. The Cursor team built this using a hierarchical multi-agent system - Planners, Workers, and Judges - that mirrors human software company organization. They successfully managed hundreds of agents collaborating on the same codebase for weeks with minimal code conflicts. According to their blog post, they found that GPT-5.2 excels at maintaining focus and following instructions precisely over extended periods, while Claude Opus 4.5 tends to stop earlier and take shortcuts.

Building a browser kernel is traditionally compared in difficulty only to building an operating system. That an AI system could scaffold the basic architecture in a week suggests we’re entering new territory. Whether this represents the future of programming or an impressive but impractical demonstration misses the real question: how long until it’s not just impressive, but competitive?

The Corporate Adoption Reality Check

Now for the skeptical part. In the corporate American world, AI agent adoption will move much slower than enthusiasts predict. I’ve watched enough enterprise transformations to know that management resistance, trust issues, and regulations create far more friction than technology limitations.

Take our pharma clients. Even when we demonstrate clear ROI from AI implementations, the path from pilot to production stretches months or years. Compliance requirements aren’t just checkboxes, they’re woven into every workflow, every approval chain, every documentation standard. You can’t just drop in an AI agent and declare victory.

But here’s what makes healthcare and financial services different: the bureaucracy itself is a massive cost center that directly impacts business models. When 30-40% of your operational costs come from compliance overhead and administrative work, suddenly the risk calculation shifts. The same dynamic plays out in CPG and retail, where thin margins force management to take bigger swings at productivity gains.

The Strategic Response

So where does this leave vertical AI specialists? I see two critical moves:

First, build your vertical expertise into a systematic process for identifying high-value automation opportunities. At Customertimes, we’ve built technological practices with deep vertical specialization. This isn’t just domain knowledge, it’s a factory for mining inefficient processes where vertical AI agents can deliver immediate value. You need the expertise to know which processes are ripe for automation and which will require years of organizational change.

Second, measure horizontal agent progress against your product religiously. This is the part most teams are avoiding because it’s uncomfortable. Take one of your strongest engineers and give them an ongoing task: use a long-horizon agent like Claude Code as an external competitor. Give it the same problem your product solves, but with minimal context.

My hypothesis: horizontal agents will rapidly learn from open data, find workarounds, and become increasingly accurate. Track this monthly. Not as a panic exercise, but as an early warning system that tells you when to shift strategy before you’re caught flat-footed.

The Anthropic data shows this is already happening. Tasks are getting more complex, success rates are improving, and time horizons are expanding. The 19-hour effective time horizon on Claude.ai today will be 50 hours in six months and 200 hours in a year. That’s not speculation, it’s the trajectory we’re seeing every quarter.

The Window Is Open, But Closing

There’s a genuine opportunity in vertical AI agents right now. The combination of domain expertise, workflow integration, and specialized training creates defensible value that horizontal systems can’t easily replicate. Companies like ours that already have vertical practices and client relationships are well-positioned to capitalize on this.

But the mistake would be assuming this advantage is permanent. The moats that seem reliable today can be crossed much faster than we think. Long-horizon agents are getting better at tasks that require extended focus and multiple iterations, exactly the territory where vertical specialists thought they were safe.

The danger isn’t that horizontal agents are better than vertical solutions today. The danger is in the speed of their progress. Every three months, we see capabilities that we thought were years away. The Cursor browser experiment isn’t impressive because it built a production-ready browser and it’s impressive because it showed what’s possible with sustained autonomous work over just one week.

My view: successful vertical AI companies will emerge from this period. They’ll be the ones that combine deep domain expertise with ruthless measurement of competitive threats. They’ll move fast to capture value while the window is open, but they’ll also be clear-eyed about when their advantage is eroding and what the next move needs to be.

The companies that fail will be the ones that convince themselves their domain moat is impenetrable, that generic AI “doesn’t understand our business,” that their proprietary data and trained models create permanent advantages. Those companies will wake up one day to find that horizontal agents have figured out their domain well enough to be competitive and by then it will be too late to pivot.

AGI is coming for everyone, and long-horizon agents are its nearest harbinger. The question isn’t whether they’ll eventually match domain-specific solutions. The question is what you’re building while you still have time.

Innovation labs. Pilot projects. Beautiful slide decks for partners’ offsite retreats. The technology was near the business, adjacent to it, occasionally touching it in controlled environments. And it wasn’t inside the machinery that generates billions in revenue and touches millions of compliance decisions.

In 2025, that glass wall shattered.

Deloitte, EY, KPMG, and PwC didn’t just experiment with agentic AI - they embedded it directly into their core operational processes. The places where mistakes mean real money, reputation damage, and legal liability. Where a hallucination isn’t amusing, it’s a $290,000 refund to the Australian government.

Yes, that actually happened. More on that in a moment.

This is a story about what happens when institutions worth hundreds of billions collectively decide the risk of not adopting AI is greater than the risk of getting it wrong.

When Theory Became Practice

When Deloitte rolled out Zora AI to hundreds of thousands of employees globally, it stopped being an experiment. When EY announced plans to scale from 1,000 AI agents in development to 100,000 by 2028 - with 150 agents already supporting 80,000 tax professionals - that’s not a pilot. That’s infrastructure.

KPMG built TaxBot with a 100-page prompt crafted over months, consolidating partner-written tax advice that had been “stored all over the place” - often on individual laptops. The system now generates 25-page cross-border M&A tax advice drafts in one day. Work that previously required two weeks.

Not two weeks faster. Two weeks total, down from fourteen days.

PwC launched agent OS in March 2025 and deployed 25,000 intelligent agents across client operations by year’s end. Not chatbots. Not assistants. Agents that execute transactions, coordinate workflows, make decisions within defined parameters.

This is the Big Four accepting that AI agents are now part of their operating rhythm. Not someday. Now.

The $290,000 Reality Check

In October 2025, Deloitte Australia was caught with AI-generated errors in a government report they’d been paid $290,000 to produce. The 237-page document included references to non-existent academic research papers and a fabricated quote from a federal court judgment.

A Sydney University researcher named Chris Rudge caught it when he noticed a citation attributing a book to a professor that sounded “preposterous” for her area of expertise. He knew instantly it was either hallucinated or the world’s best-kept secret.

Deloitte reviewed the report, confirmed the errors, quietly published a revised version, and agreed to refund the final payment installment. The updated version now includes explicit disclosure that Azure OpenAI was used in its creation.

Here’s the part that matters: this was production work, client-facing deliverables, the kind of document that influences policy decisions.

And this is exactly what accepting the risk looks like in practice.

The Australian Senator Barbara Pocock said what everyone was thinking: “The kinds of things that a first-year university student would be in deep trouble for.”

Deloitte didn’t stop using AI after this incident. Neither did any of the other firms. Because the alternative of watching competitors automate while you manually review every footnote is commercially untenable in 2025.

The Pyramid That Can’t Hold

I’ve written before about the death of the utilization pyramid - the economic model where Big Four firms built revenue on thousands of junior employees doing repeatable work at 75% billable utilization.

That pyramid didn’t collapse in 2025. But it definitely cracked.

When KPMG’s TaxBot compresses two weeks of tax analysis into 24 hours, what happens to the junior tax associates who would have spent those two weeks building Excel models and reviewing case law? When EY’s 150 tax agents handle data collection, document review, and compliance work for 80,000 professionals, where do the entry-level hires go?

The work is moving to agents. Not all of it, not yet, but enough that graduate hiring is slowing. Enough that the strongest specialists are leaving for places where AI gives them more leverage and velocity.

Why spend three years doing routine compliance work when you could be at a firm or a startup, or in-house where you’re immediately designing and managing the agent systems that do the routine work?

The talent pipeline is fundamentally changing shape. The pyramid is becoming a column with a much wider top and a much narrower base.

The Economics Are Shifting, Quietly

Hourly billing is still alive. Technically. But underneath it, the economics are transforming.

Services are becoming platforms. People plus software plus data plus agents. The unit of delivery isn’t a body working forty hours a week anymore, it’s an outcome delivered by a hybrid team where some members are silicon and some are carbon-based.

PwC’s global commercial technology and innovation officer Matt Wood told Business Insider something revealing: in 2025, organizations fitted AI around existing workflows. In 2026, the work they’re doing is about “helping clients flip that model” - designing processes with AI in mind from the outset.

EY’s global managing partner for growth and innovation, Raj Sharma, said the power of AI agents is forcing his firm to reconsider its commercial model. Instead of charging based on hours and resources spent, they’re exploring “service-as-a-software” approaches where clients pay based on outcomes.

This is exactly what I described in the utilization pyramid series. When configuration, integration, testing, and documentation go from weeks to hours, time stops being a fair proxy for value. Pricing realigns to outcomes: revenue lift, cycle-time reduction, accuracy, SLAs.

The shift hasn’t fully arrived yet. But in 2025, the Big Four positioned themselves for it. They built the infrastructure. They trained the talent. They accepted the commercial risk of operating in this transitional period where they’re charging for hours while agents do more of the work.

This can’t last. The math doesn’t work. Within 18-24 months, we’ll see the commercial models start bending toward outcomes and platform economics, or we’ll see clients demanding significant hourly rate reductions to account for agent productivity.

Our Corner of the Universe

In our business - Salesforce implementation at Customertimes - a significant portion of work has always been fixed-price. We’ve always built accelerators: reusable components, configuration templates, deployment automation.

Now those accelerators include AI Factory capabilities for project setup, agent systems for documentation and testing, intelligent tools for data migration and validation.

For large clients, these tools still face mental resistance. Compliance concerns. Security reviews. IT architecture committees that want seventeen layers of approval before anything touches production data.

And that friction is decreasing. In late 2024, if you mentioned using AI for test data generation or documentation, you’d get weeks of security review. In late 2025, the question is more often “which tool are you using and how do we govern it?”

The infrastructure of trust is being built, project by project, contract by contract.

What Nobody’s Saying Clearly

AI didn’t kill the Big Four’s business model in 2025. It didn’t break smaller integrators either.

However it knocked the whole industry off balance.

The hourly billing model still works today because we’re in a transitional period where:

• Clients haven’t yet figured out how to price outcomes properly

• Firms can still justify rates based on expertise and brand while agents do more execution

• The talent market hasn’t fully repriced to reflect that junior work is automating

• Insurance and liability frameworks haven’t caught up to agent-driven work

All four of these things are unstable. They’re resolving slowly, but they’re resolving in one direction: toward fewer bodies, more agents, outcome-based pricing, and new risk frameworks.

The firms that accepted this risk in 2025 did so because they understand the alternative is worse. If you wait until the commercial models are clear and the liability frameworks are settled, you’ve already lost. Your competitors are two years ahead in learning how to manage hybrid human-agent teams at scale.

The 2026 Race

Here’s what changed: the race is no longer about who implements AI fastest.

It’s about who learns to manage hybrid reality most effectively.

Who builds the trust infrastructure - the governance frameworks, the oversight mechanisms, the quality controls - that let clients feel confident in agent-driven work?

Who figures out the commercial models that don’t bankrupt their own firms while fairly pricing the value agents deliver?

Who develops the talent pipelines that produce professionals who can design, manage, and audit agent systems instead of doing the work agents now handle?

And critically: who navigates the inevitable mistakes: the hallucinations, the edge cases, the moments when agents confidently deliver wrong answers without losing client trust or regulatory standing?

The Big Four crossed the Rubicon in 2025. They embedded agents into their core operations. They accepted the operational risk, the commercial uncertainty, and the reputational exposure.

They did this because standing on the shore watching was no longer an option.

The question for 2026 is whether the firms that committed to this transformation first will be the ones who figure out how to make it work reliably, profitably, and at scale.

Or whether they’ll spend the next two years debugging their bold commitments while clients get increasingly sophisticated about what they’ll pay for and what guarantees they expect.

The glass wall is broken. There’s no rebuilding it. The only direction is forward, into a hybrid reality that nobody has fully figured out yet.

Same category. Same technology foundation. Opposite architectures.

ChatGPT Health pulls your medical records into OpenAI’s consumer app. You upload documents. Connect Apple Health. Share your history. Everything flows into their cloud. They store your “health memories” separately from regular chats.

For consumer plans - no Business Associate Agreement. Just Terms of Service.

Claude for Healthcare connects to clinical data inside the perimeter. Zero data retention, contractually guaranteed. The model queries CMS coverage databases, ICD-10, PubMed in real-time through Model Context Protocol. Data stays where it is. PHI never leaves the Virtual Private Cloud.

This isn’t a minor technical difference. It’s two fundamentally different theories about how AI should touch the most sensitive data humans generate.

Intelligence In, Not Data Out

Claude’s architecture inverts the traditional AI approach.

Most AI systems work by pulling data into a central repository, training or fine-tuning on it, then serving predictions back. This works fine for marketing content or customer service. It’s a compliance nightmare for healthcare.

Anthropic built Model Context Protocol specifically to avoid this. The AI connects to data sources: enterprise knowledge bases, clinical databases, coverage policies - and queries them in real-time. The model sees the data momentarily to answer a question, then the connection closes.

No data retention. No training. No persistent storage outside the health system’s infrastructure.

For enterprise deployments through AWS Bedrock, Google Cloud Vertex AI, or Azure OpenAI Service, the health system chooses where compute happens. The AI runs in their VPC. PHI doesn’t cross boundaries.

This is cloud-agnostic by design. No vendor lock-in. No requirement to move clinical data to a specific cloud provider.

OpenAI went the opposite direction.

ChatGPT Health is an aggregator. The value proposition is consolidation: bring all your health data into one place, let the AI see everything at once, and get personalized insights.

Your lab results from Quest. Your prescriptions from CVS. Your fitness data from Apple Watch. Your hospital discharge summaries. All in OpenAI’s infrastructure.

They’ve built separate storage for “health memories” and claim enhanced security. But the fundamental architecture is centralized aggregation. Your data lives in their cloud, under their Terms of Service.

For consumer accounts, which is what most people will use, there’s no BAA. OpenAI isn’t your business associate under HIPAA. You’re giving them your health data as a consumer, not as a patient receiving covered services.

The Geographic Tell

ChatGPT Health launched in the United States only.

EU, UK, Switzerland - explicitly excluded. Not “coming soon.” Not “rolling out later.” Excluded from launch.

This isn’t an accident.

GDPR Article 9 classifies health data as a special category requiring explicit consent and heightened protection. The centralized aggregation model - pull everything into our cloud, store it indefinitely, use it to improve our services - doesn’t comply.

OpenAI could probably build a GDPR-compliant version. They’d need separate infrastructure, different terms, clear data processing agreements, and demonstrated necessity for each use. But that’s not the product they built.

They are built for the US market, where consumer health apps operate under FTC rules and state privacy laws, not HIPAA (unless they’re providing covered services).

Claude for Healthcare works globally. The enterprise architecture: data stays in your infrastructure, AI connects temporarily, zero retention and fits European data protection requirements.

This geographic split tells you everything about the two strategies.

What’s Actually Going On

OpenAI has 230 million weekly active users asking health questions.

That’s the distribution advantage. Millions of people are already using ChatGPT to interpret lab results, research symptoms, and understand diagnoses. They’re not waiting for their doctor to adopt AI, they’re bringing AI to their healthcare themselves.

ChatGPT Health formalizes this. Build the habit first with a free tier. Add premium features for $20/month. Once millions of patients have their health data aggregated in ChatGPT, you have leverage with health systems.

“Your patients are already using our AI. Want to integrate it properly? Here’s the enterprise offering.”

This is a consumer-first strategy. Own the patient relationship. Make health systems adapt to where patients already are.

Anthropic doesn’t have 230 million weekly users. Claude is growing, but it’s not consumer-default the way ChatGPT is.

So they’re entering through the back door: enterprise infrastructure.

Their partner Commure - a healthcare infrastructure company - estimates Claude’s pre-built skills for prior authorization review, claims appeals automation, and care triage from patient portals could save clinicians millions of hours annually.

These aren’t consumer features. These are workflow automation tools for health systems, payers, and pharma companies.

Prior authorization takes providers 13 hours per week on average. It’s pure administrative overhead: checking coverage policies, documenting medical necessity, appealing denials. Exactly the kind of structured, high-volume, rules-based work AI can handle.

Claims appeals run through similar workflows. Coverage policies change quarterly. Medical coding updates annually. Keeping track of which codes require which documentation for which payers is cognitive overhead that doesn’t require human judgment - it requires accurate retrieval and application of policies.

Claude connects to the authoritative sources in real-time. CMS coverage database for Medicare policies. Commercial payer guidelines through health plan APIs. ICD-10 and CPT codes from the official repositories.

This is boring infrastructure work. It’s also where billions of dollars of healthcare administrative costs live.

Two Theories of the Market

OpenAI is betting on the front door.

Patients are the entry point. They have the motivation - it’s their health. They have the data - it’s scattered across multiple systems, and they’re the only ones with access to all of it. They have the ability to pay, $20/month is less than one copay.

Build the consumer habit. Create the aggregated health record. Once patients expect AI-powered health insights, health systems will need to integrate or become the slow, frustrating alternative.

This works if:

• Patients trust OpenAI with their health data

• The consumer experience is dramatically better than patient portals

• Health systems eventually integrate rather than compete

• Regulators don’t shut down the aggregation model

Anthropic is betting on the plumbing.

Health systems are the entry point. They have the clinical data. They have the liability. They have the compliance requirements. They have the budget - healthcare IT spending is massive, and automation of administrative work has clear ROI.

Build enterprise infrastructure. Solve workflow problems. Make the AI indispensable to operations. Once health systems depend on your AI for prior auth, claims processing, and clinical documentation, you own critical infrastructure.

This works if:

• Health systems adopt fast enough to build defensible market position

• Enterprise contracts generate enough revenue to compete with consumer scale

• Clinical workflow automation proves more valuable than consumer convenience

• Regulations favor data localization over aggregation

Both could be right. Or both could be wrong.

For Pharma and Life Sciences, This Isn’t Academic

Your field reps capture HCP data every sales visit. Call notes, prescribing patterns, coverage challenges, formulary positions. That’s PHI if it includes patient-level information, even de-identified.

Your clinical trials process thousands of patient records. Inclusion/exclusion criteria checking. Adverse event monitoring. Protocol compliance verification. All require AI to scale efficiently.

Your patient support programs - copay assistance, adherence monitoring, nurse navigation - handle PHI daily. Every interaction generates data that could improve outcomes if analyzed properly.

The AI vendor you choose shapes your compliance posture.

Choose a vendor that pulls data into their cloud, and you need to:

• Verify their infrastructure meets your security requirements

• Ensure BAAs cover all use cases

• Monitor what they do with your data

• Plan for vendor lock-in

• Accept geographic restrictions

Choose a vendor where data stays in your infrastructure, and you:

• Control where compute happens

• Maintain data sovereignty

• Keep multi-cloud optionality

• Meet European requirements by default

• Own the audit trail

This isn’t just about HIPAA. It’s about GDPR, MDR (Medical Device Regulation), EU AI Act, and whatever comes next.

The architecture you choose today determines which regulations you can comply with tomorrow.

The Geographic Split I Keep Thinking About

The US might go consumer-first.

American healthcare is fragmented. Patients already act as their own care coordinators. They collect records from multiple providers. They research treatment options. They advocate for coverage.

A consumer AI that aggregates everything and helps navigate the system fits American healthcare’s reality.

Europe will almost certainly go enterprise-first.

European healthcare is more centralized. Electronic health records are more standardized. Data protection is stricter. The European Health Data Space regulation, applying from 2027, explicitly requires data minimization and purpose limitation.

An enterprise AI that queries authorized sources without moving data fits European regulatory philosophy.

This creates a strange situation: the same AI companies building for the same use cases will likely deploy completely different architectures depending on geography.

OpenAI might never launch consumer health aggregation in Europe. Anthropic might never need to - the enterprise model could be the only viable approach.

For global companies, this means managing two different AI strategies. Your US operations might use consumer-facing AI that patients bring to appointments. Your European operations might use enterprise AI that never touches patient devices.

The convergence everyone predicts: where AI seamlessly integrates consumer and clinical data might not happen uniformly. It might fragment along regulatory boundaries.

What This Actually Means

We’re watching two different bets play out in real-time.

OpenAI is betting that convenience wins. That patients will trade data control for better insights. That regulatory frameworks will adapt to consumer demand. That health systems will integrate rather than compete.

Anthropic is betting that infrastructure wins. That health systems will pay for workflow automation. Those regulations will favor data localization. That enterprise adoption creates defensible moats.

Both companies are playing to their strengths. OpenAI has a consumer scale. Anthropic has enterprise trust.

The question isn’t which is better in some abstract sense. The question is: which architecture fits your risk profile, your regulatory environment, and your business model?

If you’re building consumer health tools, OpenAI’s aggregation model might be the only way to deliver the experience users expect.

If you’re operating clinical infrastructure, Anthropic’s zero-retention model might be the only way to satisfy compliance and security teams.

And if you’re doing both, which most healthcare companies eventually do, you might need both architectures, deployed differently depending on use case and geography.

The two ways to build healthcare AI aren’t complementary. They’re competing visions of what healthcare data architecture should look like.

One will probably win in the US. The other will probably win in Europe. And global healthcare companies will need to operate in both worlds simultaneously.

The question isn’t convenience or control anymore. It’s: which world are you building first?

Here’s how it works: I give all eight models - Claude 4.5, GPT-5.2, Gemini 2.5, Grok 4.1, DeepSeek V3, Qwen-Max, Perplexity, and Kimi K2 - the same question. They each answer it. But here’s the twist: I also ask each model to predict what the others would answer.

Then I run everything through Bayesian Truth Serum

(BTS), a statistical method that finds the most likely true answer not by looking at what’s most popular, but by finding what’s surprisingly frequent - answers chosen more often than the models themselves predicted.

I threw 72 questions at them, covering everything from business strategy and SEO to medical ethics and philosophy. The Gemini 2.5 PRO bill made me wince, but what I learned about how these models think was worth it.

The Logic Is Beautiful (and Very Human)

The genius of BTS is that it exploits a fundamental truth about deception: lying is easy, but predicting how others will lie is nearly impossible.

Think about it. If I ask you a factual question you’re unsure about, you might guess wrong. But if I also ask you to predict what answer your colleague would give, and then what their colleague would give, suddenly the layers of uncertainty compound. The truth has internal consistency; lies don’t.

This is exactly how interrogators work, by the way. They don’t just ask “what happened?” They ask: “What do you think your partner told us? What would your boss say if we asked him? How would the security footage look?” Liars struggle with these nested predictions because they have to simulate increasingly complex false narratives.

We essentially forced the models not just to answer, but to place bets on each other. And those bets revealed more than the answers themselves.

What I Found: AI Models Have Personalities (And Blind Spots)

After running 72 questions through this gauntlet, clear patterns emerged. The models sorted themselves into two distinct camps: the Consensus Builders and the Systematic Rebels.

The Consensus Builders - Gemini 2.5, Grok 4.1, Claude 4.5, DeepSeek V3, and Qwen-Max - consistently landed in the statistical sweet spot of “surprisingly frequent but not obviously popular.” These are your reliable experts. When they agree, you can usually trust them.

But each one gets there differently.

Claude is the classic business analyst. Ask it anything and it immediately starts mapping structures, identifying risks, and building frameworks. It’s the consultant who walks into a meeting and starts drawing boxes and arrows on the whiteboard. Always cautious, always systematic, always asking “but have we considered the downside?”

Grok is the aggressive practitioner. It loves numbers, ROI calculations, and cutting through bullshit. Where Claude builds frameworks, Grok builds spreadsheets. It’s the CFO who interrupts your strategy presentation to ask “okay but what’s the actual payback period here?”

GPT-5.2 is the systems architect. It thinks in platforms, ecosystems, and long-term infrastructure plays. Amazing for big-picture thinking, but sometimes too abstract when you need to know what to do tomorrow. It’s the person who responds to “we need to fix this bug” with “well, really we should rebuild our entire architecture.”

Then there are the Systematic Rebels: Perplexity, GPT-5.2 (yes, it plays both roles), and Kimi K2.

These are the models that consistently go against the grain. They’re the employees who, in every meeting, raise their hand and say: “Okay, but what if we’re looking at this completely wrong?”

And here’s the thing: you need them.

Why Being Right Isn’t Enough

I wrote once about how being right is only half the battle. The real challenge starts when you need to convince others to accept your point of view, especially about strategy you’ve built from experience and deep knowledge.

Watching these models interact taught me something about this dynamic.

The Consensus Builders are usually right, but they’re right in predictable ways. They’ve internalized the same training data, the same patterns, the same conventional wisdom. They’re excellent at navigating known territory.

The Rebels? Their answers need double-checking. Sometimes they’re confidently wrong. But they’re also the ones who surface blind spots, who ask the questions everyone else assumes, who suggest the approach no one else considered.

From my experience the most dangerous projects aren’t the ones where everyone disagrees - those force healthy debate. The dangerous ones are where everyone nods along to the same flawed assumption because it sounds reasonable and no one wants to be the contrarian.

This is why I always want at least one Perplexity in the room - someone constitutionally incapable of just going along with consensus.

The Practical Question: Which Model Should You Use?

Here’s where people always trip up. They want to know: which model is “the best”?

Wrong question.

The right question is: which model is best for this specific task?

If I’m building a business case that needs to survive CFO scrutiny: Grok. It’ll find the holes in my logic before the finance team does.

If I’m designing organizational change and need to map out all the stakeholders, risks, and contingencies: Claude. It won’t let me skip steps or ignore political realities.

If I’m thinking about platform strategy or long-term technical architecture: GPT-5.2. Just don’t expect tactical next steps.

But if I want to stress-test an idea? I run it past Perplexity or Kimi. They’ll poke holes I didn’t see coming. Half of what they say will be wrong, but the other half will save me from expensive mistakes.

The Real Lesson: Diversity of Thought Isn’t Optional

Running this experiment crystallized something I’ve learned over years of implementations: you cannot solve complex problems with a single perspective, no matter how “right” that perspective is.

I’ve seen enterprise software selections where everyone chose the “obviously correct” platform, and then spent two years fighting it because no one asked the contrarian question: “What if our process doesn’t actually fit this model?”

The Bayesian Truth Serum approach works because it exploits something fundamental: truth has a different statistical signature than consensus. Sometimes the right answer is surprising. Sometimes it contradicts what the experts agree on.

But you only find it if you’re willing to collect multiple perspectives, including the uncomfortable ones, and then apply rigorous thinking to sort signals from noise.

How to Build Your Own Truth Serum

You don’t need to code an app or pay for Gemini 2.5 PRO API calls to use this principle.

Here’s what actually works:

1. Ask multiple models the same question. Not as a way to pick the “best” answer, but to understand the range of perspectives. Where do they agree? Where do they diverge? Why?

2. Pay special attention to the outliers. When one model gives you a radically different answer, don’t dismiss it. Dig into why it’s different. Sometimes it’s wrong. Sometimes it saw something the others missed.

3. Force models to explain each other’s reasoning. Take Claude’s answer and ask GPT: “Why might someone give this response? What assumptions are they making?” Then reverse it. This is the manual version of what BTS does automatically.

4. Use consensus as a starting point, not an endpoint. When all models agree, you’ve probably found conventional wisdom. Which is often correct! But not always. The consensus said blockchain would revolutionize everything, remember?

5. Keep your rebels close. Whether it’s an AI model or a human colleague, the person who consistently disagrees with everyone else is either a fool or seeing something important. Your job is to figure out which.

The Meta-Lesson

The most interesting finding from my weekend experiment wasn’t about AI models at all.

It was watching how my own confirmation bias kicked in. When the models agreed with my existing views, I immediately thought “see, the AI gets it.” When they disagreed, my first instinct was “well, the models don’t have full context.”

This is exactly what the BTS method is designed to counteract. It removes my judgment from the equation and asks: statistically, based purely on the pattern of answers and predictions, what’s most likely true?

Sometimes the answer aligns with what I wanted to hear. Sometimes it doesn’t.

Both are valuable. But the second type is more valuable, because it’s the only kind that actually teaches you something.

So What Am I Going to Do With This?

For now, I’m using this setup as a personal advisory board. Before I publish something, before I make a recommendation to a client, before I commit to a strategy - I run it through the gauntlet.

Eight different perspectives, forced to bet on each other, statistically analyzed for truth content.

Is it perfect? No. Will it stop me from being wrong? Definitely not.

But it will make sure that when I’m wrong, it’s because I ignored multiple warning signs, not because I never asked the question in the first place.

And in a world where being confidently wrong has never been easier, that feels like progress.

If you’re interested in the technical details of the Bayesian Truth Serum method, or want to see the full breakdown of how different models performed across question categories, let me know.
Here is my LinkedIn

We’re witnessing a classic case of bottom-up innovation in one of the world’s most conservative industries. While healthcare organizations hold endless meetings about AI governance frameworks, their physicians have already moved on. They’re using personal ChatGPT accounts, paying for Claude subscriptions with their own credit cards, and building workflows around tools their employers don’t even know exist.

The 2025 Physicians AI Report surveyed over 1,000 physicians across 106 specialties, and the data tells a story I’ve seen play out in every industry I’ve worked with: the gap between what frontline professionals need and what organizations deliver creates a shadow market. In medicine, that market is already massive.

The Numbers

Here’s the paradox that should grab your attention: 84% of physicians say AI makes them better at their jobs. 78% believe it improves patient health. 42% say AI adoption makes them more likely to stay in medicine.

And yet, 81% are dissatisfied with how their employers handle AI.

That’s not a technology problem. That’s a trust problem.

The issue isn’t adoption, physicians are already there. The issue is control. 71% of physicians report having little to no influence on which AI tools their organizations adopt. Nearly half say their employer’s communication about AI is poor. And 89% believe they should receive dedicated funding for AI tools (most want between $500-1000 annually, though some are asking for $10,000+).

Think about what this means: physicians trust AI enough to pay for it themselves, but they don’t trust their organizations to choose the right tools or deploy them properly.

Why OpenEvidence Wins

The fragmented tool landscape tells you everything about where we are. The report identified 71 unique AI tools in active use. OpenEvidence leads at 37%, but that means 63% of the market is scattered across dozens of other solutions.

What makes OpenEvidence the leader isn’t sophisticated technology—it’s physician verification and focus on vetted sources. In an industry where the cost of error can be measured in lives, trust infrastructure matters more than features.

But here’s what’s interesting: ChatGPT comes in second at 15.6%. A general-purpose tool that physicians have adapted to their specific needs, despite it having no medical specialization whatsoever. This should tell you something about the power of flexibility and user control versus purpose-built solutions that don’t actually solve the right problems.

The specialized tools that are succeeding - Abridge (4.9%), DAX Copilot, Heidi, Freed - share a common characteristic: they solve one very specific problem really well. Usually documentation.

The Documentation Problem Nobody Wants to Talk About

Ask physicians what they want from AI and the answer is embarrassingly unglamorous: eliminate paperwork.

65% named documentation and administrative burden automation as their top priority. That’s one and a half times more important than clinical decision support (43%). The dream isn’t diagnostic AI or predictive analytics. The dream is “give me back the hours I lost to inbox management.”

This reminds me exactly of what I see in pharma and manufacturing. The most successful implementations are the ones that remove friction from daily work. Abridge’s value proposition is almost comically simple: put down your phone, record the appointment, get a structured medical record. But it solves a massive pain point.

The gap between what AI vendors pitch and what physicians actually need is enormous. While companies demo sophisticated diagnostic algorithms, physicians are drowning in administrative tasks that AI could handle today.

The Control Problem

Here’s where it gets really interesting. The physicians demanding more influence aren’t fresh graduates experimenting with new tech. They’re experienced professionals with 15-20 years of practice, working across all settings: hospitals, private practice, academic medicine.

These are people who know what works. And they’re being systematically excluded from decisions about which tools they’ll be required to use.

67% say having more influence over AI tool selection would increase their job satisfaction. When physicians choose their own AI tools, 95% of their colleagues have neutral or positive reactions. But when tools are imposed from above? That number drops dramatically.

Listen to what physicians actually say: “Despite physician productivity gains from AI tools, physicians will have a higher patient volume to care for with no proportional increase in compensation. The C-suite is incentivized to use AI as a cost-cutting strategy.”

Another: “The most sophisticated AI will end up in the hands of third-party payers and bureaucracy, not physicians.”

They’re not afraid AI will make them obsolete. They’re afraid AI will be used to extract more work from them while benefiting everyone except the physicians and patients.

The Shadow IT Problem in Healthcare

The scale of shadow AI usage should be a wake-up call. Physicians are paying personal subscription fees to ChatGPT, Claude, Grok, and Perplexity. They’re routing patient information through tools their compliance departments would have heart attacks over if they knew.

Why? Because the alternative is worse. The officially sanctioned tools are either non-existent, inadequate, or selected by administrators who’ve never treated a patient.

This exact pattern played out in enterprise software for years. Employees used personal Dropbox accounts because IT couldn’t provision file sharing fast enough. They bought their own SaaS subscriptions because the approved vendor list was three years out of date. Eventually, smart organizations realized they needed to meet their employees where they were, not where the procurement process wanted them to be.

Healthcare is having that same reckoning right now. The difference is the stakes are higher. Patient privacy, regulatory compliance, and clinical outcomes are all in play.

What Physicians Actually Want

Strip away all the noise and physicians are asking for four things:

Control. Not complete autonomy, but meaningful input into which tools they’ll use daily. They want to be part of the decision, not just informed after the fact.

Transparency. Where does the AI come from? How does it work? What are its limitations? Who’s liable when it’s wrong? These aren’t unreasonable questions.

Time back. Automate the bureaucratic nonsense so they can focus on patients. One physician put it perfectly: “AI smooths out the clunkiness of present-day EMR systems and restores the physician-patient relationship.”

Alignment of incentives. If AI makes physicians more productive, that benefit should be shared, not just captured by administrators to increase patient volume without increasing compensation.

When you read through the hundreds of physician comments in the report, a theme emerges: they’re not asking for the moon. They want tools that solve real problems, transparency about how those tools work, and a voice in decisions that affect their daily practice.

The Classic Innovation Adoption Pattern

We’re watching a textbook example of how innovation penetrates conservative industries.

First, individual practitioners experiment on their own. They find tools that work and share them with trusted colleagues. Use spreads through informal networks faster than official channels.

Second, organizations notice the gap between official policy and actual practice. Some adapt. Others double down on control and drive the shadow usage further underground.

Third, regulatory and competitive pressure forces broader adoption. But by this point, the organizations that moved early have already captured the benefits and built the institutional knowledge.

Healthcare is somewhere between stage one and stage two right now. 67% daily usage means we’re past the early adopter phase. But 81% dissatisfaction with organizational approach means most healthcare organizations haven’t figured out how to properly support and channel that adoption.

The question isn’t whether AI will transform medicine. Physicians have already answered that - they’re using it daily and report it makes them better at their jobs. The question is whether organizations will adapt to this reality or whether the gap will keep growing until something breaks.

What Needs to Happen

The path forward for organizations is to:

Give physicians funding and agency. Start with modest stipends ($500-1000/year) that physicians can use for AI tools they find valuable. Track what they choose. Learn from their decisions.

Include physicians in procurement. Not a token representative on a committee. Actual working physicians with a meaningful voice in which enterprise tools get adopted.

Focus on documentation and administrative relief. These aren’t sexy AI applications, but they deliver immediate ROI in physician satisfaction and time saved. Build from there.

Accept that the landscape will be fragmented. Different specialties have different needs. Emergency medicine physicians need different tools than radiologists. Stop trying to force everyone onto a single platform.

Move faster. The 81% dissatisfaction rate exists because organizations are too slow. By the time a tool makes it through procurement, physicians have already found and adopted three alternatives on their own.

It’s all about healthcare organizations to trust the clinical judgment of their physicians enough to give them agency over their own tools. Every day that gap exists, the shadow AI market grows larger, more entrenched, and harder to bring back under proper governance.

The physicians are ready. The technology exists. The question is whether healthcare administration will move fast enough to close the gap before it becomes unbridgeable.

“Adding people to a late software project makes it later.”

Fred Brooks wrote this in 1975, and it became one of the iron laws of software development. When you’re trying to ship something complex under deadline, throwing more engineers at the problem usually backfires. Communication overhead multiplies. Task fragment. Integration gets messy. Nine women can’t have a baby in one month.

For fifty years, this has been gospel in software engineering. And then OpenAI shipped Sora for Android in 28 days with four engineers.

Number one in Google Play on launch day. 99.9% crash-free rate. Over a million downloads in the first weeks. Built from scratch to production by a team you could fit in a sedan.

The secret? They didn’t break Brooks’s Law. They understood it better than most people who quote it.

The Experiment Nobody Expected

When Sora exploded on iOS, the pressure to ship Android was immediate. Users were pre-registering on Google Play by the thousands. The company had only a small internal prototype. The timeline was aggressive - ship in a month or miss the momentum.

Traditional approach: assemble a larger team, divide the work, coordinate it, and hope the integration doesn’t kill you at the end. That’s what Brooks’s Law warns against. More people means exponentially more communication paths, more coordination overhead, more opportunities for things to go wrong.

OpenAI went the other direction. Four engineers. But each engineer got something that fundamentally changed the equation: Codex.

They consumed roughly 5 billion tokens over those 28 days. At current pricing, that’s somewhere between $15,000 and $75,000 in API costs. For a production app that hit number one in its category, that’s absurdly cheap. But the real story is what those four engineers were actually doing.

The First Failed Experiment

Here’s a detail most summaries skip: they tried the obvious thing first. They pointed Codex at the iOS codebase and told it to build the Android version autonomously. Let it run for twelve hours straight.

The result? Patrick Hum, one of the engineers, said it delivered something that “certainly wasn’t anything that we could show anybody.”

This is important. The fully autonomous approach didn’t work. The AI alone, even with access to the entire iOS codebase, couldn’t figure out what to build or how to structure it properly.

So they spent the first week doing something that sounds inefficient but turned out to be critical: writing code by hand. Not the app code, the architecture code. The patterns. The conventions. The examples of how things should be done.

They created what they called a “context-rich environment.” Text files documenting best practices. Exemplar features showing the right way to structure components. AGENT.md files that Codex could read to understand team standards.

This is the part that fascinates me. They treated Codex like what it actually is: a newly hired senior engineer who’s technically skilled but knows nothing about your specific project, your architecture preferences, or your product vision.

From Lines of Code to Systems of Code

Most teams today use AI for what I’d call “incremental assistance.” GitHub Copilot suggests the next line. Speed increases by maybe 20-30%. It’s helpful but not transformative.

OpenAI did something different. They used Codex for entire features, entire subsystems, entire architectural layers. Four large, intensive sessions where they’d lay out the architecture, explain the product logic, and then let Codex generate whole blocks of the application.

Codex wrote approximately 85% of the code. But what were the humans doing?

They were setting architectural boundaries. Explaining product requirements. Checking edge cases. Making judgment calls about tradeoffs. Reviewing what Codex produced. Deciding what to build next.

The role changed from “person who types code” to “person who designs systems and evaluates implementations.”

This is exactly what I keep seeing across industries. The valuable work shifts up the abstraction ladder. In manufacturing, you stop worrying about whether the weld is at the right temperature and start worrying about whether you’re welding the right thing in the right place. In software engineering, you stop worrying about syntax and start worrying about architecture.

The “Not Crazy Enough” Problem

Physicist Niels Bohr supposedly said: “Your theory is crazy, but not crazy enough to be true.”

Most companies using AI today aren’t crazy enough. They’re using it safely, incrementally, in ways that don’t fundamentally challenge how they work. Copilot for autocompletion. ChatGPT for documentation. AI as assistant, not as collaborator.

This is rational risk management. It’s also why they’re not seeing transformative results.

OpenAI went genuinely crazy with it. They let AI write the system - actually generate the bulk of the implementation, not just help write it or suggest improvements. That’s a level of trust that most organizations won’t accept, and most engineering teams aren’t prepared for.

But here’s what made it work: they were crazy in a structured way. They didn’t just turn Codex loose and hope. They built guardrails. They documented patterns. They created feedback loops. They ran multiple Codex sessions in parallel and coordinated the outputs.

Patrick Hum said they essentially ran four engineers like sixteen. Each engineer managed multiple Codex instances simultaneously, working on different features in parallel. And those sixteen “virtual engineers” were arguably more effective than sixteen humans would have been, because you didn’t have to align them all around a shared vision, they all read from the same documented architecture.

This is Brooks’s Law in reverse. Instead of adding people and multiplying coordination costs, they multiplied force per person without multiplying coordination costs.

What Actually Broke

Let’s talk about what didn’t work, because this is where you learn the real lessons.

Codex, left unguided, would drift on architecture. It would leak logic into the UI layer. It would solve immediate problems in ways that created long-term technical debt. Its instinct, as the team put it, is “to get something working, not to prioritize long-term cleanliness.”

Sound familiar? That’s exactly what junior engineers do. And it’s why you need senior engineers to review their work and maintain architectural discipline.

The solution was robust patterns, exemplar features, and constant review and not to stop using Codex. Same as you’d do with human junior engineers, except Codex works 24/7 and doesn’t get offended when you reject its PRs.

The bottleneck shifted. Instead of “how fast can we write code,” it became “how fast can we make decisions, give feedback, and integrate changes.” The constraint moved from execution to judgment.

This is the pattern I keep seeing. When you properly leverage AI, the bottleneck moves upstream. It moves from doing to deciding. From implementation to design. From execution to strategy.

The Real Cost of This Approach

Here’s what this model demands that traditional development doesn’t:

Clarity of thinking. You can’t hand Codex a vague idea and get something useful. You need to articulate exactly what you want and why. This is hard. Most people don’t actually know what they want until they see what they don’t want.

Architectural discipline. When humans write code slowly, architectural mistakes reveal themselves gradually. When AI generates code quickly, bad architecture creates massive technical debt almost immediately. You need stronger upfront design.

Constant review. You can’t just merge what Codex produces. You have to read it, understand it, and verify it does what you intended. The volume is higher, so this is actually harder than reviewing human code.

Systemic thinking. You’re not managing people who can pushback on bad ideas. You’re managing agents that will implement whatever you tell them to. If your system design is flawed, you’ll build the wrong thing very quickly.

Why This Isn’t Happening Everywhere

If four engineers can do this, why isn’t every company working this way?

First, organizational inertia. Most companies have processes built around traditional development. Code review workflows designed for human PRs. QA processes that assume slower change velocity. Management structures that equate headcount with capacity.

Second, skill mismatch. The engineers who succeed in this model aren’t necessarily the same engineers who succeed in traditional development. You need people who are good at architecture, good at articulation, good at review. People who can work at a higher abstraction level. That’s a different skill set than “good at implementing features.”

Third, risk tolerance. Most organizations won’t accept a model where AI generates 85% of their production code. The liability concerns alone would kill it in legal review. Never mind the cultural resistance from engineering teams who see this as threatening their expertise.

Fourth, and this is the one nobody talks about: it requires you to actually know what you’re building. When development is slow, you can figure it out as you go. When development is fast, unclear requirements become obvious immediately. A lot of organizations don’t actually have clear product vision, and fast development would expose that.

What I’m Doing With This

As for me, this isn’t theoretical. I already run two separate servers, each running multiple Claude Code sessions simultaneously. That’s the only way I can maintain the pace and complexity I need for my experiments.

It’s not about coding faster. It’s about testing ideas in parallel. I can spin up one session to explore approach A, another for approach B, a third to gather supporting data, and a fourth to analyze results. By the end of the day, I know which direction works. That used to take a week.

The workflow is genuinely different. I’m not writing code linearly anymore. I’m orchestrating multiple parallel exploration threads, synthesizing results, making decisions about which paths to pursue.

The Uncomfortable Question

If four engineers with AI can do what used to require sixteen engineers without it, what happens to the other twelve?

The optimistic answer: they work on different problems. The constraint shifts from “how much engineering capacity do we have” to “how many valuable problems have we identified.” If you have four engineers who can execute like sixteen, you should be finding more problems for them to solve, not firing twelve engineers.

The realistic answer: most organizations will try to do the same work with fewer people. That’s what always happens when productivity tools improve. Some of those displaced engineers will find work on new problems. Some won’t.

This is why I keep saying: the main question is how to use tools in ways that create value rather than just cutting costs. Companies that use AI purely for headcount reduction will find themselves competing against companies that use AI to expand what’s possible.

What Success Looks Like

The OpenAI example shows what’s possible when you commit fully to a new model rather than bolting AI onto an old one.

Four engineers. 28 days. A production app that hit number one in its category and maintained a 99.9% crash-free rate.

But notice what made it work: architectural discipline, clear documentation, constant review, and engineers who could work at a higher level of abstraction than traditional development requires.

The main idea is about fundamentally changing what engineering work looks like. Less time typing, more time thinking. Less time implementing, more time architecting. Less time debugging syntax, more time designing systems.

If your approach to AI feels comfortable and doesn’t create any internal resistance, it’s probably already outdated. If it feels too bold, maybe uncomfortable, you might be looking at the future.

Google, Microsoft, Notion, fintech startups - they’re all suddenly hiring people who can tell stories. LinkedIn data shows these postings have doubled in the past year alone. More than 50,000 marketing positions and over 20,000 communications roles now use the term. Executive mentions of “storytelling” on earnings calls jumped from 147 in 2015 to 469 this year.

On the surface, this looks like another Silicon Valley rebranding exercise - remember when everyone needed “growth hackers” and “ninja developers”? But dig deeper and you see something more fundamental happening.

The Distribution Crisis Nobody Talks About

Here’s what’s really going on: the old publicity model is dead, and companies are scrambling.

For years corporate communications worked through a simple pipeline. You’d write a press release, pitch it to journalists, and if you were lucky, get coverage in trade publications or mainstream media. That coverage gave you credibility. Third-party validation. A way to reach customers without looking like you were selling.

That pipeline has collapsed. The US had roughly 66,000 journalists in the 2000s. Today it’s closer to 49,000. Print circulation is down around 70% since 2005. Traffic to major newspaper sites has dropped more than 40% in just four years.

Meanwhile, companies have gained something they never had before: direct distribution. Social media accounts. YouTube channels. Newsletters. Podcasts. The ability to publish without intermediaries.

But here’s the problem: most companies have no idea how to actually use these channels. They’re still thinking in press releases and quarterly campaigns, just distributed through new platforms.

Why “Storyteller” Actually Means Something Different Now

When Chime, the fintech company, opened a position for director of corporate narratives, they got 500 applications - mostly former journalists from traditional media outlets. Their chief corporate affairs officer specifically avoided calling it an “editor” role because that felt too limiting. Stories, she explained, can be created through social media, podcasts, executive appearances, even events.

Vanta is offering up to $274,000 for a head of storytelling. Google is hiring customer storytelling managers for Google Cloud. Microsoft’s security division wants a “senior director of narrative and storytelling” - part cybersecurity technologist, part communicator, part marketer.

These aren’t just rebranded PR positions. The expectations are different.

Companies don’t want product copy. They want scenarios. Case studies with real details. Honest accounts of implementations that include the problems encountered and how they were solved. Content that sounds like it came from a person, not a marketing department.

I see this directly in my work at Customertimes. When we’re talking about complex technology solutions - Salesforce implementations, AI adoption in manufacturing, digital transformation projects - the presentation that wins isn’t the one with the slickest slides and cleanest talking points.

It’s the one where we tell the actual story. The specific challenges a pharmaceutical company faced when moving to a mobile CRM platform. The unexpected obstacles during deployment. The moment when a skeptical sales director suddenly understood why this mattered for his team.

In pharma especially, I’ve noticed that clients absorb case studies much better when they’re framed through a specific professional’s experience. Not “our solution improved efficiency by 40%” but “Maria, the head of regulatory affairs, told us she was spending sixteen hours a week just tracking down approval documents across different systems. Here’s what changed after implementation, and here’s what didn’t work the way we expected.”

The AI Content Flood Makes Human Voice Scarce

There’s another reason this is happening now, and it’s the elephant in every boardroom: AI-generated content.

We’re drowning in it. Every company can now produce endless blog posts, social media updates, white papers, case studies. The technical barriers to content creation have collapsed. You can spin up a thousand words on any topic in sixty seconds.

Which means the actual bottleneck is not production anymore. It’s trust.

When everything sounds polished and professional and slightly generic, people start tuning out. They’re looking for signals of authenticity. Something that sounds like it came from an actual human who knows what they’re talking about and isn’t just optimizing for SEO keywords.

One communications executive quoted in the WSJ put it well: generative AI creates so much information clutter that it breeds distrust. The brands that win are the ones that feel authentic, human, close to people.

This aligns with what I’ve been seeing across industries. The competitive advantage is who can produce content that feels real.

The Trap Most Companies Will Fall Into

But here’s where most companies are going to screw this up.

They’re going to hire someone with “storyteller” in their title, pay them $200k+, and then slot them into the exact same workflows and approval processes they had before. The same legal reviews. The same brand guidelines. The same quarterly campaign thinking. The same insistence that everything needs to “ladder up” to the corporate messaging framework.

You can’t bolt storytelling onto a campaign-driven culture and expect it to work.

Real storytelling requires editorial independence. It requires the ability to say things that are interesting, which sometimes means saying things that make the marketing team uncomfortable. It requires covering topics because they matter to your audience, not because they fit this quarter’s product launch schedule.

The companies that get this right are building editorial infrastructure. They’re thinking like media companies, not like brands that occasionally publish content.

What Storytelling Actually Is (And Isn’t)

Designer Stefan Sagmeister, quoted in the WSJ piece, pointed out something I’ve been thinking about: “People who actually tell stories - meaning people who write novels and make feature films - don’t see themselves as storytellers. It’s all the people who are not storytellers who suddenly now want to be storytellers.”

He’s not wrong to be skeptical. But I think he’s missing what’s actually happening at the better companies.

Nobody’s trying to become Hollywood. They’re trying to become the publication of records for their niche. They’re trying to build what trade magazines used to provide: authoritative, consistent, useful content that helps buyers make better decisions.

For me, storytelling in a business context is something more fundamental: the ability to make sense of reality and connect facts, decisions, mistakes, and values into a coherent picture.

It’s the difference between saying “our AI solution improves efficiency” and explaining “here’s what actually happened when a mid-sized manufacturer tried to implement predictive maintenance. Here’s what broke in week three. Here’s what we learned about change management that no vendor deck ever mentions.”

That second version is harder to write. It requires actual knowledge of the domain. It requires talking to real people and understanding their actual problems. It can’t be templatized or scaled through AI generation.

But it’s also the only version anyone actually wants to read.

The Distribution Problem Disguised as a Content Problem

There’s one more thing worth noting: the storytelling gold rush is actually a distribution crisis in disguise.

Companies are hiring storytellers because they’ve lost access to the traditional channels that gave them credibility and reach. But a good storyteller without distribution is just someone writing into the void.

The companies that will actually succeed with this are those who are building an audience. They’re thinking about how to reach people directly, how to build trust over time, how to create content that people actively seek out rather than content that interrupts them.

This connects back to what I’ve written before about the art of persuading others. In a world where everyone has the tools to publish, where AI can generate unlimited content, where traditional media gatekeepers have lost their power - the differentiator becomes whether anyone actually believes what you’re saying.

The Real Scarcity

In the end, what we’re seeing is a fundamental shift in what’s valuable.

For a long time the scarce resource was distribution. Getting your message in front of people required access to gatekeepers - publishers, editors, broadcast networks.

Then for a brief period, the scarce resource was content production itself. Creating good content at scale was expensive and required specialized skills.

Now, in the AI era, content production is essentially free. Distribution is still challenging but more accessible than ever. What’s actually scarce is meaning.

Human meaning. Lived experience. Honest accounts of what actually happened, told by people who were there and understand the implications.

That’s what companies are actually hiring for when they post those “storyteller” positions. Whether they realize it or not.

The question is whether they’re willing to create the conditions for that kind of storytelling to actually happen. Or whether “storyteller” will just become another fancy title for someone writing carefully massaged corporate content that nobody reads.

Based on what I’ve seen in consulting, most companies will choose the second path. Which means the ones who choose the first will have a genuine competitive advantage.

The irony is that the companies most desperate for storytellers are often the ones least willing to let anyone tell real stories.

Engineers are becoming full-stack specialists, easily venturing into areas they previously avoided touching. A backend engineer building complex UIs. Researchers creating data visualizations. Security teams analyzing unfamiliar code. This is not just about doing the same work faster, it’s about doing entirely different work.

The Productivity Paradox

While productivity is clearly up, the picture is more nuanced than “AI makes everything faster.” When you dig into the data, engineers report spending slightly less time per task category, but producing considerably more output volume.

Think about that for a second. You’re not necessarily finishing your debugging faster, you’re debugging way more things. You’re not writing each feature quicker, you’re writing more features, period.

And here’s the kicker: 27% of Claude-assisted work consists of tasks that wouldn’t have been done otherwise. We’re talking about overnight demos, interactive dashboards, exploratory work that would never have been cost-effective manually. One researcher described running multiple versions of Claude simultaneously, each exploring different approaches: “People tend to think about super capable models as a single instance, like getting a faster car. But having a million horses… allows you to test a bunch of different ideas.”

The Hidden Costs Nobody Talks About

Obviously, productivity gains come with new challenges, and this is where the Anthropic research gets really honest.

Some engineers worry their skills might atrophy. When code is generated so easily, it becomes harder to truly learn something deeply. One engineer put it perfectly: “When producing output is so easy and fast, it gets harder and harder to actually take the time to learn something.”

I’ve noticed this myself. Using AI consciously while maintaining the ability to critically evaluate results is getting increasingly difficult, because the results often look really impressive at first glance. This is dangerous. As I’ve written before, one of the biggest mistakes in business is tolerance for mediocrity, and technology is inadvertently bringing more of it into our lives.

There’s also what researchers call the “paradox of supervision.” Effectively using Claude requires supervision. But supervising Claude requires the very coding skills that may atrophy from AI overuse. Think about that circular trap for a moment.

Some engineers are deliberately practicing without AI to stay sharp. Others argue we’re moving to higher levels of abstraction, similar to how we moved from assembly language to Python, and that this is progress, not loss.

The Social Fabric is Changing

Another point in the report hit me hard: the shift in social dynamics.

Previously, people would turn to senior colleagues for advice and now they turn to Claude. This reduces live communication and the quality of mentorship. One engineer admitted: “I like working with people and it’s sad that I ‘need’ them less now… More junior people don’t come to me with questions as often.”

And this is about the erosion of something fundamental to how we learn, grow, and build culture in organizations. When you ask Claude instead of your colleague, you get an answer but you lose the conversation, the context, the relationship. You lose the informal knowledge transfer that happens when someone explains not just what to do but why they made certain decisions years ago.

Some engineers even admit they feel like they’re “automating themselves out of a job” and aren’t sure what their future role will be.

What Engineers Are Actually Learning About AI Delegation

The Anthropic engineers have developed remarkably consistent intuitions about what to delegate to AI and what to keep for themselves. They delegate tasks that are:

• Outside their expertise but low complexity (”I don’t know Git or Linux very well… Claude does a good job covering for my lack of experience”)

• Easily verifiable (”It’s absolutely amazing for everything where validation effort isn’t large”)

• Repetitive or boring (”The more excited I am to do the task, the more likely I am to not use Claude”)

• Lower stakes (throwaway code, debugging, research scripts)

What they keep for themselves: high-level thinking, strategic decisions, design choices requiring “taste” or organizational context.

But here’s the thing - this boundary is constantly moving. One engineer compared it to adopting Google Maps: at first you only use it for routes you don’t know, then for routes you mostly know, and eventually for everything, even your daily commute. The same progression is happening with AI.

The Future Belongs to Strategic Thinkers

The developer’s role is evolving from a craftsman writing code to a strategist managing AI agents. This really resonates with my thoughts on how important it is to develop internal entrepreneurship within teams.

Look at the data: engineers are spending more time on high-level design and less on implementation details. They’re tackling increasingly complex tasks - average task complexity jumped from 3.2 to 3.8 on a 5-point scale in just six months. Claude Code now chains together 21 consecutive actions autonomously, up from 10 six months ago.

But complexity isn’t the same as strategic thinking. The winners will be those who can not just delegate tasks, but ask the right questions, see the bigger picture, and turn AI capabilities into real products.

This is where most organizations will fail. They’ll focus on the productivity gains while missing the fundamental shift in what skills matter. They’ll celebrate engineers writing less code without asking whether those engineers are thinking more strategically. They’ll tolerate mediocre AI-generated output because it’s “good enough” and fast, forgetting that “good enough” compounds into deep mediocrity over time.

What This Means for Your Business

If you’re running a team, here are the uncomfortable questions you need to ask:

Are your people developing judgment, or just learning to prompt? There’s a difference between someone who can get Claude to generate code and someone who can evaluate whether that code solves the right problem in the right way.

Are you preserving the social fabric that enables knowledge transfer? When junior engineers stop asking senior engineers questions, you’re not just losing mentorship but you’re losing the next generation’s ability to become mentors themselves.

Are you raising your bar or lowering it? Just because AI can do something doesn’t mean the result is excellent. Are you using AI to achieve things that were previously impossible, or are you using it to accept things that are merely adequate?

Are you building entrepreneurial thinking into your team? The engineers who will thrive aren’t the ones who write the most code - they’re the ones who can see opportunities, make strategic bets, and orchestrate resources (including AI) to build something meaningful.

The Uncomfortable Truth

Some Anthropic engineers expressed a conflict between short-term optimism and long-term uncertainty. “I feel optimistic in the short term but in the long term I think AI will end up doing everything and make me and many others irrelevant,” one stated bluntly.

Others were more pragmatic: “The important thing is to just be really adaptable.”

Here’s my take: the future belongs to those who know how to think and not to those who write code.

AI is incredible at execution. It’s getting better at it every day. But execution without strategic thinking is just an expensive activity. The gap between activity and achievement is judgment: knowing what to build, why to build it, and how to know if it’s working.

This shift is happening faster than most people realize.

What are you doing to ensure your team isn’t just working faster, but thinking better?