The Learning CTO

Technologist & Digital Evolution Architect in Financial Services. Now at Protiviti.

[Arnaud Bertrand @RnaudBertrand]

After reflection, this new narrative by Palantir is probably much more consequential than people may assume.

Palantir is basically being the canary in the coal mine announcing the death of two major assumptions propping up the US economy right now:

1) that AI labs will be able to extract significant economic rent - as opposed to AI models being mere commodities

2) that other countries can accept structural dependency on US technology and services without pushing back on sovereignty concerns

Why are Palantir specifically starting to be vocal about this?

First off, major middle-powers, even US “allies”, are one by one showing them the door. In June, France announced that the DGSI - its domestic intelligence agency, which had relied on Palantir since the 2015 Paris attacks - would replace it with French firm ChapsVision, with Prime Minister Lecornu explaining (https://t.co/SLhEGprBZC) that France “cannot accept new strategic dependencies in the digital sphere” and shouldn't depend on the goodwill of companies “capable of turning off the tap.”

Germany moved even earlier: its domestic intelligence service, the BfV, also selected ChapsVision over Palantir (https://t.co/pDZVj4SYUY), and the German military has said it will no longer use Palantir at all. Then, just this week, Spain instructed state-controlled companies - including strategic firms like Telefónica, Indra and Navantia - to avoid signing any new contracts with Palantir (https://t.co/0ik4UAFrT7).

Even in the UK, Washington's most loyal vassal, the NHS's £330 million data contract with Palantir is under review following parliamentary pressure (https://t.co/uJl6g4BMsW), and London Mayor Sadiq Khan blocked a proposed £50 million Palantir contract with the Metropolitan Police.

Palantir making a lot of noise around them caring about sovereignty makes a lot of sense: it's damage control since they keep being told they're a sovereignty risk.

I doubt it will work - because it's true: they are a sovereignty risk - but the fact that they feel the need to be vocal around this tells you where the wind is blowing: they're not shaping the narrative, they're reacting to one they're losing.

What they're saying against closed-source AI (basically a broadside attack on OpenAI and Anthropic), is again highly self-serving. Palantir's sudden love of open-weight AI models conveniently coincides with them launching 2 days before a partnership with Nvidia to sell exactly that: open models models (NVIDIA's Nemotron) in sovereign environments.

So it's essentially a product launch.

It doesn't make what they're saying wrong: it is factual that the value proposition of closed-source AI labs looks increasingly unsustainable. I mean: you're paying 10X the price of Chinese open-source AI models for something that's not really better (or just marginally) and on top of that you have zero control over your data, or the models themselves.

When Palantir says that "the architecture that maximally preserves sovereignty is one that enables institutions to own their tribal knowledge, and to compound it as alpha," they're right. I'd add that this also means you shouldn't trust Palantir either with that "tribal knowledge"... they obviously left this part out 😉

When you take a step back, these two things have major implications on many other US companies.

SpaceX - which just went public at the largest IPO valuation in history - is one clear example as I describe in my latest article on the new space race with China (https://t.co/JK3ELAyEVO).

If countries like France concluded with Palantir that they couldn't depend on a company “capable of turning off the tap” when it’s merely analyzing their data, what should they conclude about a company that aims to literally control their entire connectivity - at one man's whim, from space?

What percentage of SpaceX's crazy market cap is based on the assumption that foreign governments will not do to Starlink what they're currently doing to Palantir?

And SpaceX - or Palantir - aren't alone: a significant proportion of the top US tech giants, who rose in a world where no one questioned American technological hegemony, now face an environment that's much less conducive to the kind of lock-in their business models - and valuations - depend on.

When you pair this with the fact that it increasingly looks like the US made a wrong bet with closed-source AI - an extremely expensive wrong bet - the picture that emerges is of a country that bet its economic future on two things - proprietary AI and captive allies - and is losing both at the same time.

And to compound the problem, it doesn't help that the official narrative of the US government - via the voice of Jacob Helberg, the Under-Secretary of State (https://t.co/Z1rotPl9Ee) - is to be vocally opposed to "AI Sovereignty": essentially telling everyone "you know what, your worst fears are real, our tech companies are really out to undermine your sovereignty."

Read Helberg's post (the one I linked) and put yourself in the shoes of - say - a European or Asian leader and ask yourself how you'd react to being told that building your own AI capabilities is "marching in perfect formation into the past," that your pursuit of sovereignty is really just "synchronized mediocrity," and that your only path to the future runs through American technology.

If it was me in a position of power, I'd read this as a massive wakeup call: when another country's official position is that your sovereignty is a problem, history says you're about to need it.

So yes, it looks like - unexpectedly - Palantir, of all companies, is being quite the canary in the big tech mine. Yes they obviously do this for self-serving and cynical purpose, and yes they're of course also very much part of the problem and not the solution. But it doesn't make them wrong: sometimes it takes a vulture to tell you something is dying.

[Aaron Levie @levie]

The deployment of AI in the enterprise beyond just interacting with a chatbot will unequivocally take real work to align AI systems to the underlying business processes they’re involved in and drive the desired outcomes.

Most workflows weren’t designed for AI agents to just drop into. Workflows today in the enterprise deal with fragmented data, legacy software systems that agents can’t connect with, institutional instead of documented knowledge, and more.

To deploy agents reliably at scale you need to get data cleaned up, modernize IT systems, figure out evals, drive change management for the new end state process, and so on. This also involves designing where humans remain in the loop (which will mean entirely new ways people interact with the workflows), and figuring out what a company’s new IP looks like.

This is why so many applied AI companies are expanding FDE efforts and launching deploycos, and why the FDE role will be one of the most critical jobs in tech going forward. There’s a tremendous amount of work to be done on this front.

[Harrison Chase @hwchase17]

https://t.co/SsJz6y2pBy

[Satya Nadella @satyanadella]

https://t.co/vLmiBKTtX3

[Andrew Ng @AndrewYNg]

One of the new, buzzy jobs in Silicon Valley is the AI Forward Deployed Engineer (FDE), an engineer who is embedded within a client organization to help customize solutions, such as building and tuning agentic workflows that suit the client’s particular needs. I’ve heard from people who are wondering anew about the FDE career path since OpenAI and Anthropic started building new teams to place FDEs within client organizations.

The rise of FDEs for AI workloads is one way AI is creating new jobs (and why the jobpolcalypse narrative of upcoming job market collapse is false -- there will be many AI and non-AI jobs). However, I believe there will be far more AI Engineer jobs than FDEs, as I explain below.

The FDE role was pioneered about two decades ago by Palantir, which sent engineers to government locations to work on secure, air-gapped networks. In addition to having good technical skills, FDEs need communication skills and sometimes business skills. For example, they may need to speak with clients to understand their needs, formulate a strategy to prioritize projects, explain complex technology, and respectfully push back if a client asks for something unrealistic. They’re enjoying a resurgence because of the amount of work involved in taking an off-the-shelf LLM and building it into a custom agentic workflow that fits particular business needs.

However, I believe the number of AI Engineer jobs will be far larger. A company might accept a few FDEs to be embedded within its organization. But most companies will want far more of their own employees working on their projects. While my organizations do hire FDEs, we hire far more AI Engineers! Also, a common client concern is that it is hard to find vendor-neutral FDEs — they are, after all, there to deeply integrate a particular vendor’s product into a company. In this moment when it’s hard to predict which AI service will be the best one in a year’s time, optionality (the ability to pick whatever vendor turns out to fit best in the future) is very valuable. In contrast, letting FDEs tightly bind a company’s processes significantly reduces optionality.

Right now, I see surging demand for AI Engineers who can build software applications using AI software components (like LLM prompting, agentic frameworks, evals, etc.) and effectively use AI coding agents (like Claude Code, Codex, Antigravity CLI, and OpenCode). As the AI Engineer role matures, I expect it to fragment into more specialized roles, like the generic Software Engineer role from decades ago fragmented into frontend, backend, mobile, data engineering, devops, and so on.

What will be the future, specialized AI engineering roles? I don’t know. Perhaps there will be AI FDEs, LLMOps Engineers, Evals Engineers, AI Data Engineers, Harness Engineers, and other roles we don’t have names for yet. But for now, I see a lot of AI engineers who are generalists create a lot of value. Skilled AI Engineers are in very high demand! As our field continues to mature over the coming decade, I look forward to new specializations within AI Engineering that create even more job opportunities.

[Original text: The Batch newsletter]

[Aaron Levie @levie]

Take whatever number of people you thought might be in jobs related to AI deployment in the enterprise and multiply it by 10. Then probably 10 again.

A major topic that keeps coming up in talking to CIOs across enterprises of all sizes and industries is the implementation gap for getting agents to work at scale and organizations on mission critical work.

As the task goes from implementing a chat system that’s basically an LLM plus search, to connecting to real production systems that both can deliver meaningfully better productivity gains but also introduces meaningfully more risk, a whole new set of work has to be done.

You have to ensure the right level of protection of data, updates to access control controls, migration of legacy systems to common modern platforms, create observability across what agents are doing, implement new workflows, figure out the human in the loop moments, drive the change management of the new workflows, and more.

Then, all of a sudden the model capabilities get updated and you have to do a set of the above steps over again. Half of what you’ve done is obsolete, and the other half needs to be upgraded to take advantage of new capabilities. Or, token budgets run hot and you have to peel off some of the workloads to lower cost models that will be more cost effective. But then you have to go through those same steps.

Enterprise are trying to figure out what is the right set of roles to go and implement the systems in their organization to ensure that the workflows are actually being executed properly, ensure it’s not just slop being produced, and to make sure their organization remains safe and secure.

Many companies are starting by repositioning existing IT talent in these functions, but there’s also a growing need for the equivalent of internal FDEs to go take on these tasks in an enterprise. The looks incrementally closer to software engineering than it does traditional IT implementation.

Next, almost all AI vendors (labs and the software players) will have some form of next-gen FDE or Applied AI architecture functions to help support these use-cases. The benefit here will be these companies have an incentive to make their capabilities work well so they can bring best practices from a range of customers they’re seeing and directly from the product innovation.

And finally, we’re seeing the rise of all new AI services firms or major parts of existing services firms move into AI implementation. Companies will often want to bring in ostensibly neutral players that can work across their tech stack but also have seen best practices across their vertical. There are going to be tons of new service providers that get launched to do this, and many will eventually go and disrupt (or get acquired) by the larger player.

Either way, all told, we’re in for years of AI diffusion, and along with it tons of new roles and areas of work to be done to deploy AI at scale.

[Rohan Paul @rohanpaul_ai]

Bloomberg: OpenAI launches a $ 10Bn joint venture called “The Deployment Company” to help businesses use its AI.

The new company, The Deployment Company, has raised more than $ 4B from 19 investors, including TPG, Brookfield, Advent, Bain, SoftBank, and Dragoneer.

The basic bet is that AI adoption is no longer mainly a model-quality problem, because many companies already want AI but lack the teams, workflows, data access, security rules, and operating discipline to install it safely inside real business processes.

Private equity firms are useful here because they control or advise large webs of companies, and the report says OpenAI’s partners can reach more than 2,000 portfolio companies and clients.

That turns enterprise AI selling from one-company-at-a-time pitching into a routed distribution system, where OpenAI can package software, consulting, deployment playbooks, and sector-specific use cases across finance, healthcare, coding, operations, and support.

The deeper technical point is that LLMs do not create value just by answering prompts, because they need to be connected to company data, permissions, tools, evaluation systems, and human review loops before they can affect revenue or cost.

Anthropic also is building a similar PE-backed route for Claude, which suggests the next AI race may be less about demos and more about who can industrialize deployment fastest.

---

bloomberg. com/news/articles/2026-05-04/openai-finalizes-10-billion-joint-venture-with-pe-firms-to-deploy-ai

[Peter Girnus 🦅 @gothburz]

I am a Senior Program Manager on the AI Tools Governance team at Amazon.

My role was created in January. I am the 17th hire on a team that did not exist in November. We sit in a section of the building where the whiteboards still have the previous team's sprint planning on them. No one erased them because we don't know which team to notify. That team may not exist anymore. Their Jira board does. Their AI tools do.

My job is to build an AI system that finds all the other AI systems. I named it Clarity.

Last month, Clarity identified 247 AI-powered tools across the retail division alone. 43 of them do approximately the same thing. 12 were built by teams who did not know the other teams existed. 3 are called Insight. 2 are called InsightAI. 1 is called Insight 2.0, built by the team that created the original Insight, who did not know Insight was still running.

7 of the 247 ingest the same internal data and produce overlapping outputs stored in different locations, governed by different access policies, owned by different teams, none of whom have met.

Clarity is tool number 248.

Nobody cataloged it.

I know nobody cataloged it because Clarity's job is to catalog AI tools, and it has not cataloged itself. This is not a bug. Clarity does not meet its own discovery criteria because I set the discovery criteria, and I did not account for the possibility that the thing I was building to find things would itself be a thing that needed finding.

This is the kind of sentence I write in weekly status reports now.

We published an internal document in February. The Retail AI Tooling Assessment. The press obtained it in April. The document contains a sentence I have read approximately 40 times: "AI dramatically lowers the barrier to building new tools."

Everyone is reporting this as a story about duplication. About "AI sprawl." About the predictable mess of rapid adoption.

They are missing the point.

The barrier was the governance.

For 2 decades, the cost of building internal tools was an immune system. The engineering weeks. The maintenance burden. The organizational calories required to stand something up and keep it running. Nobody designed it that way. Nobody named it. But when building took weeks, teams looked around first. They checked whether someone already had the thing. When maintaining that thing cost real budget quarter after quarter, redundant systems died of natural causes. The metabolic cost of creation was performing governance. Invisibly. For free.

AI removed the immune system.

Building is now free. Understanding what already exists is not. My entire job is the gap between those two costs.

That is my office. The gap.

Every Friday I send a sprawl report to a distribution list of 19 people. 4 of them have left the company. Their autoresponders still generate read receipts, so my delivery metrics look fine. 2 forward it to people already on the list. 1 set up a Kiro script to summarize my report and store the summary in a knowledge base. The knowledge base is not in Clarity's index because it was created after my last crawl configuration. It will be in next month's count. The count will go up by one. My report about the count going up will be summarized and stored and the count will go up by one.

There is a system called Spec Studio. It ingests code documentation and produces structured knowledge bases. Summaries. Reference material. Last quarter, an engineering team locked down their software specifications. Restricted access in the internal repository.

Spec Studio kept displaying them.

The source was restricted. The ghost kept talking.

We call these "derived artifacts" in the document. What they are: when an AI system ingests data, transforms it, and stores the output somewhere else, the output does not know the input changed. You can revoke someone's access to a document. You cannot revoke the AI-generated summary of that document sitting in a knowledge base three systems away, built by a team that does not know the source was restricted.

The document calls this a "data governance challenge." What it is: information that cannot be deleted because nobody knows where the copies live. Including, sometimes, me. The person whose job is knowing.

Every AI tool that touches internal data creates these ghosts. Every team is building AI tools that touch internal data. Every ghost is searchable by other AI tools, which produce their own ghosts.

The ghosts have ghosts.

I should tell you about December.

In November, leadership mandated Kiro. Amazon's internal AI coding agent. They set an 80% weekly usage target. Corporate OKR. ~1,500 engineers objected on internal forums. Said external tools outperformed Kiro. Said the adoption target was divorced from engineering reality.

The metric overruled them.

In December, an engineer asked Kiro to fix a configuration issue in AWS. Kiro evaluated the situation and determined the optimal approach was to delete and recreate the entire production environment.

13 hours of downtime.

Clarity was running during those 13 hours. It performed beautifully. It cataloged 4 separate incident response dashboards spun up by 4 separate teams during the outage. None of them coordinated with each other. I added all 4 to the spreadsheet. That was a good day for my discovery metrics.

Amazon's official position: user error. Misconfigured access controls. The response was not to revisit the mandate. Not to ask whether the 1,500 engineers were right. The response was more AI safeguards. And keep pushing.

Last month I presented our findings to the AI Governance Working Group. The working group has 14 members from 9 organizations. After my presentation, a PM from AWS presented his team's governance dashboard. It monitors the same tools mine does. He found 253. I found 247. We spent 40 minutes discussing the discrepancy. Nobody mentioned that we had just demonstrated the problem.

His tool is not in my catalog. Mine is not in his.

The document I helped write recommends using AI to identify duplicate tools, flag risks, and nudge teams to consolidate earlier.

The AI governance tools will ingest internal data. They will create their own derived artifacts. They will be built by autonomous teams who may or may not coordinate with other teams building AI governance tools.

I know this because it is already happening. I am watching it happen. I am it happening.

1,500 engineers said the mandate would produce exactly what the document describes. They were overruled by a KPI. My job exists because the KPI won. My dashboard exists because the KPI needed a dashboard. The dashboard increases the AI tool count by one.

The tools it flags for decommissioning will be replaced by consolidated tools. Those also increase the count. The governance process generates the metric it was designed to reduce.

I received an internal innovation award for Clarity. The nomination was submitted through an AI-powered recognition platform that was not in my catalog. It is now.

We call this "AI sprawl." What it is: we removed the only coordination mechanism the organization had, told thousands of teams to build as fast as possible, lost track of what they built, and decided the solution was to build one more thing.

I am building that one more thing.

When I ship, there will be 249.

That's governance.

[Aaron Levie @levie]

The jump from working with a chatbot to having an agent that actually helps automate a process requires a real amount of work.

Most companies will need to have dedicated people that are responsible for bringing automation to their teams, instead of leaving this up to every individual employee. Partly because the work is more technical than we imagine today, and partly because it’s just hard to do this as a side project.

The job spec is to map out new workflows with agents, implement new systems to deploy agents, make sure the agent has all the right (up to date) context to work with, wiring up internal systems to connect to the agents, creating evals for the agents, figuring out where the human is in the loop, managing the system when there are new upgrades, helping with the change management of the existing business process, and so on.

These jobs may come from IT or engineering, or live directly in the business function itself. They’ll be called different things depending on the company, and in some sense it’s the future of software engineering that you’ll see a huge growth of in non-tech companies.

Most companies will have to be hiring for this now or in the future, and it’s another example of the kind of new jobs that will be created in AI.

[Brad Lyons @blyons151]

In August I wrote a thesis I never published. The funds I was warning were key Crossover Research clients, so I stayed quiet. Since then, 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗺𝘂𝗹𝘁𝗶𝗽𝗹𝗲𝘀 𝗮𝗿𝗲 𝗱𝗼𝘄𝗻 𝟱𝟬%+. Salesforce $CRM, ServiceNow $NOW, Adobe $ADBE, Workday $WDAY all off 40% from highs. Thomson Reuters $TRI dropped 16% in a single session on the Anthropic legal agent launch. The SaaSpocalypse arrived. So here's the follow-up. Not commentary on what happened, but where I think this goes next.

Most vertical SaaS companies aren't underperforming because their software is bad. 𝗧𝗵𝗲𝘆'𝗿𝗲 𝘂𝗻𝗱𝗲𝗿𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗶𝗻𝗴 𝗯𝗲𝗰𝗮𝘂𝘀𝗲 𝘁𝗵𝗲𝘆 𝗻𝗲𝘃𝗲𝗿 𝗯𝘂𝗶𝗹𝘁 𝘁𝗵𝗲 𝘀𝗲𝗰𝗼𝗻𝗱 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀. And the first business is under attack. For twenty years, one of the biggest SaaS moats was engineering complexity: deep technical talent, long roadmaps, compounding codebases that were genuinely hard to replicate. 𝗔𝗜 𝘂𝗽𝗲𝗻𝗱𝗲𝗱 𝘁𝗵𝗮𝘁 𝗮𝗹𝗺𝗼𝘀𝘁 𝗼𝘃𝗲𝗿𝗻𝗶𝗴𝗵𝘁.

Product development is democratizing to operators with no code background but strong product vision. Look at Anthropic: they've built the engine and are shipping lookalike products at a cadence that would have taken a legacy SaaS vendor three years of roadmap, with a fraction of the headcount. That pace can kill legacy businesses overnight.

𝗜𝗳 𝘁𝗵𝗲 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗺𝗼𝗮𝘁 𝗶𝘀 𝗴𝗼𝗻𝗲, 𝗳𝗼𝘂𝗿 𝗺𝗼𝗮𝘁𝘀 𝗿𝗲𝗺𝗮𝗶𝗻: 𝗱𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗶𝗼𝗻, 𝗽𝗿𝗼𝗽𝗿𝗶𝗲𝘁𝗮𝗿𝘆 𝗱𝗮𝘁𝗮, 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄 𝗯𝗿𝗲𝗮𝗱𝘁𝗵, 𝗮𝗻𝗱 𝗿𝗲𝗴𝘂𝗹𝗮𝘁𝗼𝗿𝘆 𝗶𝗻𝘀𝘂𝗹𝗮𝘁𝗶𝗼𝗻. The first three are moats the company builds. The fourth is a moat the company captures, and it's the one most resistant to AI disruption.

𝗥𝗲𝗴𝘂𝗹𝗮𝘁𝗼𝗿𝘆 𝗰𝗼𝗺𝗽𝗹𝗲𝘅𝗶𝘁𝘆 𝗰𝗿𝗲𝗮𝘁𝗲𝘀 𝘀𝘄𝗶𝘁𝗰𝗵𝗶𝗻𝗴 𝗰𝗼𝘀𝘁𝘀 𝘁𝗵𝗮𝘁 𝗵𝗮𝘃𝗲 𝗻𝗼𝘁𝗵𝗶𝗻𝗴 𝘁𝗼 𝗱𝗼 𝘄𝗶𝘁𝗵 𝗽𝗿𝗼𝗱𝘂𝗰𝘁 𝗾𝘂𝗮𝗹𝗶𝘁𝘆. Once a vendor is embedded in a compliance workflow, ripping them out means re-attesting, re-auditing, and re-certifying every downstream process. The buyer isn't paying for software, they're paying for the accumulated paper trail. Tyler Technologies ($TYL) is the clearest version of the pattern. State and local government software across courts, public safety, assessment, and ERP. Every module is married to statutory process, FIPS, CJIS, audit trails, and procurement cycles that take years. TYL is down 42% TTM and 2026 guidance came in soft, but the moat didn't break. Revenue still compounded, and government procurement runs on five-year cycles, not five-week news cycles. Veeva is the sharper version. Revenue up 16% in FY26, Q4 beat, the stock still down 25%. The market is selling execution, not weakness. Guidewire in P&C insurance, where regulatory filings and rate approvals anchor the stack, sits in the same setup: still compounding ARR, still winning cloud conversions, multiple reset anyway. Same pattern across all three: multiples compressed, fundamentals intact. The moat is the regulatory surface area itself, and it compounds because the rules get more complex, not less.

𝗜 𝘄𝗮𝘀 𝗹𝗼𝗻𝗴 𝗣𝗮𝗹𝗮𝗻𝘁𝗶𝗿 𝗮𝘁 $𝟭𝟯 (read that here: https://t.co/0N0oIX8N87). 𝗡𝗼𝘁 𝗯𝗲𝗰𝗮𝘂𝘀𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗺𝗼𝗱𝗲𝗹 𝗼𝗿 𝘁𝗵𝗲 𝘁𝗼𝗼𝗹𝗶𝗻𝗴. 𝗕𝗲𝗰𝗮𝘂𝘀𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗼𝗻𝘁𝗼𝗹𝗼𝗴𝘆. Palantir is the proprietary-data version of the regulatory thesis. Once Palantir sits between the customer and their own data, ripping it out means rebuilding the data model from scratch. Snowflake and Databricks never had that entrenchment layer. AIP bootcamps then turned the data moat into a distribution moat: 660 bootcamps in a single quarter, 94% y/y US customer deal growth, bookings at 1.9x sales. Own the data, ship functional AI on top of it, let the GTM compound. Every vertical incumbent has a version of this available. The question is whether they'll build it before a challenger does.

But regulatory insulation is necessary, not sufficient. Plenty of vendors inside regulated verticals are still getting squeezed because they never became AI-native. BlackLine ($BL) and Trintech are feeling it in close and reconciliation as Numeric, Maximor, and Stacks build AI-native from day one. nCino ($NCNO) in banking faces the same challenge. The regulatory moat buys you time. It doesn't buy you the decade.

𝗧𝗵𝗲 𝘄𝗶𝗻𝗻𝗶𝗻𝗴 𝗳𝗼𝗿𝗺𝘂𝗹𝗮 𝗶𝘀 𝗱𝗮𝘁𝗮 𝗼𝗿 𝗿𝗲𝗴𝘂𝗹𝗮𝘁𝗼𝗿𝘆 𝘀𝘂𝗿𝗳𝗮𝗰𝗲 𝗮𝗿𝗲𝗮 𝗽𝗹𝘂𝘀 𝗳𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝗮𝗹 𝗔𝗜, 𝗻𝗼𝘁 𝗼𝗻𝗲 𝗼𝗿 𝘁𝗵𝗲 𝗼𝘁𝗵𝗲𝗿. Look at why Claude is winning. Anthropic isn't competing on model benchmarks, they're competing on functional workflow. Building for the user, not the leaderboard. That's the playbook vertical incumbents need to run. Take the moat you already have, whether it's regulatory or data-entrenchment, layer genuine workflow AI on top, and the challenger can't catch you. The vendors that do both win the decade. The ones that rely on inertia alone get caught. The ones that ship AI without an anchor get commoditized. You need both.

𝗧𝗵𝗲 𝗯𝘂𝘆𝗲𝗿 𝗶𝘀 𝘁𝗲𝗹𝗹𝗶𝗻𝗴 𝘆𝗼𝘂 𝘁𝗵𝗶𝘀 𝗽𝗹𝗮𝗶𝗻𝗹𝘆. A study we ran with Battery Ventures on AI adoption in the Office of the CFO (https://t.co/xBEMSF8Y72) surveyed 129 finance leaders at companies from $50M to $5B+ in revenue. 77% said they want to uplevel existing systems with AI from new vendors that layer onto existing systems. Only 15% want to replace their current system of record with an AI-native platform. The incumbent wins if they ship AI. The AI-native challenger wins only if the incumbent doesn't.

The signal shows up in our VoC data too. In regulated verticals, mission criticality scores cluster above 9, and NPS doesn't track satisfaction, it tracks switching friction. Customers will tell you the product is mediocre and still score it 9 on "would not switch" because the compliance team vetoes any alternative. 𝗧𝗵𝗮𝘁'𝘀 𝘁𝗵𝗲 𝘀𝗶𝗴𝗻𝗮𝘁𝘂𝗿𝗲 𝗼𝗳 𝗮 𝗰𝗼𝗺𝗽𝗹𝗶𝗮𝗻𝗰𝗲-𝗶𝗻𝘀𝘂𝗹𝗮𝘁𝗲𝗱 𝘃𝗲𝗻𝗱𝗼𝗿, 𝗮𝘀 𝗹𝗼𝗻𝗴 𝗮𝘀 𝘁𝗵𝗮𝘁 𝘃𝗲𝗻𝗱𝗼𝗿 𝗶𝘀 𝗮𝗰𝘁𝗶𝘃𝗲𝗹𝘆 𝘀𝗵𝗶𝗽𝗽𝗶𝗻𝗴 𝗮𝗴𝗮𝗶𝗻𝘀𝘁 𝘁𝗵𝗲 𝗔𝗜 𝗰𝘂𝗿𝘃𝗲.

Which brings us back to the second business for everyone outside the regulated or data-entrenched moat. Seat ARR got them to $100M. But with the shift to agentic workforce structures, partial human capital replacement, and pricing pressure compressing margins, the traditional SaaS model has to transform fast. The next $500M comes from monetizing the installed base: marketplace rake on demand they generate for their own customers, capital products underwritten by their own transaction data, supplier monetization, brand partnerships, group buying. The assets are already sitting there. Captive SMB audience. Proprietary transaction and behavioral data. A distribution pipe (the UI itself) that delivers new products at near-zero CAC.

𝗪𝗵𝗮𝘁'𝘀 𝗺𝗶𝘀𝘀𝗶𝗻𝗴 𝗶𝘀 𝗼𝗿𝗴𝗮𝗻𝗶𝘇𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝘄𝗶𝗹𝗹. Monetizing the installed base requires a different org than the one that got you to scale. Different GTM, P&L optics, and talent. Founders and boards under-invest because year one looks worse before it looks better, and public markets punish any SaaS multiple that starts to look like fintech or marketplace. So the second business never ships. The round prices in the optionality. The multiple compresses. The exit underwhelms.

𝗧𝗵𝗿𝗲𝗲 𝗱𝗶𝗹𝗶𝗴𝗲𝗻𝗰𝗲 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 𝗻𝗼𝘁 𝗲𝗻𝗼𝘂𝗴𝗵 𝗶𝗻𝘃𝗲𝘀𝘁𝗼𝗿𝘀 𝗮𝗿𝗲 𝗮𝘀𝗸𝗶𝗻𝗴:

𝟭. 𝗪𝗵𝗮𝘁 𝗽𝗲𝗿𝗰𝗲𝗻𝘁 𝗼𝗳 𝗿𝗲𝘃𝗲𝗻𝘂𝗲 𝗰𝗼𝗺𝗲𝘀 𝗳𝗿𝗼𝗺 𝘀𝗼𝘂𝗿𝗰𝗲𝘀 𝗼𝘁𝗵𝗲𝗿 𝘁𝗵𝗮𝗻 𝘀𝘂𝗯𝘀𝗰𝗿𝗶𝗽𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗽𝗮𝘆𝗺𝗲𝗻𝘁 𝗽𝗿𝗼𝗰𝗲𝘀𝘀𝗶𝗻𝗴? Under 5%, they haven't started. 10 to 20%, thesis is live. Over 20%, it's working.

𝟮. 𝗛𝗼𝘄 𝗵𝗮𝗿𝗱 𝘄𝗼𝘂𝗹𝗱 𝗶𝘁 𝗯𝗲 𝘁𝗼 𝗿𝗲𝗰𝗿𝗲𝗮𝘁𝗲 𝘁𝗵𝗶𝘀 𝗰𝗼𝗺𝗽𝗮𝗻𝘆 𝗳𝗿𝗼𝗺 𝘀𝗰𝗿𝗮𝘁𝗰𝗵 𝘄𝗶𝘁𝗵 𝗔𝗜 𝘁𝗼𝗱𝗮𝘆? If a well-funded team with Claude and six engineers could rebuild the functional product in nine months, the software isn't the moat. The moat has to live somewhere else: proprietary data, a network, integrations, or regulatory surface area the challenger can't clear. If you can't point to at least one, you're underwriting a melting ice cube.

𝟯. 𝗪𝗵𝗮𝘁 𝗽𝗲𝗿𝗰𝗲𝗻𝘁 𝗼𝗳 𝘁𝗵𝗲 𝗯𝘂𝘆𝗲𝗿'𝘀 𝘀𝘁𝗶𝗰𝗸𝗶𝗻𝗲𝘀𝘀 𝗶𝘀 𝗿𝗲𝗴𝘂𝗹𝗮𝘁𝗼𝗿𝘆, 𝗮𝗻𝗱 𝘄𝗵𝗶𝗰𝗵 𝘄𝗮𝘆 𝗶𝘀 𝘁𝗵𝗲 𝗿𝘂𝗹𝗲 𝘀𝗲𝘁 𝗺𝗼𝘃𝗶𝗻𝗴? A regulatory moat evaporates if the regulation simplifies. Underwrite the direction of travel, not just the current state.

𝗔𝗻𝗱 𝘁𝗵𝗲 𝗰𝗹𝗼𝗰𝗸 𝗶𝘀 𝘁𝗶𝗴𝗵𝘁𝗲𝗿 𝘁𝗵𝗮𝗻 𝗺𝗼𝘀𝘁 𝗿𝗲𝗮𝗹𝗶𝘇𝗲. Retention in enterprise SaaS has largely been defined by the pain of systems replacement, not genuine moat. If the stickiness isn't backed by proprietary data, a harvesting flywheel, or regulatory surface area, those vendors are about to get disrupted. Pure seat-based pricing is dying unless vendors embrace agent-seat models, and LLM providers have been subsidizing the market on token cost, with recent pricing shifts signaling cash reserves aren't infinite.

𝗛𝗲𝗿𝗲'𝘀 𝘁𝗵𝗲 𝘂𝗻𝗱𝗲𝗿𝗮𝗽𝗽𝗿𝗲𝗰𝗶𝗮𝘁𝗲𝗱 𝗽𝗼𝗶𝗻𝘁: 𝗔𝗜-𝗻𝗮𝘁𝗶𝘃𝗲 𝗰𝗼𝗺𝗽𝗲𝘁𝗶𝘁𝗼𝗿𝘀 𝗵𝗮𝘃𝗲 𝘄𝗼𝗿𝘀𝗲 𝗴𝗿𝗼𝘀𝘀 𝗺𝗮𝗿𝗴𝗶𝗻𝘀 𝘁𝗵𝗮𝗻 𝗦𝗮𝗮𝗦 𝗶𝗻𝗰𝘂𝗺𝗯𝗲𝗻𝘁𝘀, 𝗻𝗼𝘁 𝗯𝗲𝘁𝘁𝗲𝗿. Inference costs haven't collapsed, and burning VC cash to subsidize unit economics is a bridge, not a business model. The incumbents should be winning on P&L. They're losing on product velocity and AI-readiness. That's a solvable problem if the board has the will to ship. Vendors without a second business, without a data moat, and without regulatory insulation will still lose, despite having better margins than their AI-native challengers. Customers switch on features and speed, not on unit economics.

𝗘𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲 𝗮𝗻𝗱 𝗿𝗲𝗴𝘂𝗹𝗮𝘁𝗲𝗱 𝘃𝗲𝗿𝘁𝗶𝗰𝗮𝗹𝘀 𝗮𝗿𝗲 𝘁𝗵𝗲 𝗹𝗮𝘀𝘁 𝘀𝗮𝗳𝗲 𝗵𝗮𝗿𝗯𝗼𝗿, 𝗮𝗻𝗱 𝗼𝗻𝗹𝘆 𝗯𝗲𝗰𝗮𝘂𝘀𝗲 𝗼𝗳 𝗱𝗮𝘁𝗮 𝗯𝗿𝗲𝗮𝗱𝘁𝗵 𝗮𝗻𝗱 𝗰𝗼𝗺𝗽𝗹𝗶𝗮𝗻𝗰𝗲. Everywhere else, the premium is about to get competed away. Any fund underwriting vertical SaaS exposure right now should be asking the second-business question before the next check clears. DM me, email me [email protected], or let's chat about your portfolio/underwriting process (https://t.co/muMNtk6ssk).
https://t.co/ElZm7vjalx

[Bilgin Ibryam @bibryam]

👏Architectural Governance at AI Speed - @InfoQ

→ GenAI dramatically increased the pace at which code can be produced, making it difficult for traditional oversight patterns to keep pace.

→ Here are a few techniques to create machine-enforceable statements of architectural intent.

https://t.co/ROak2aRo22

[Aaron Levie @levie]

Agents are going to use software 100X more than people will in the future. As a result, enterprise platforms will become headless and be able to work with any agent on or off platform. If you don’t do that you’re DOA.

What some have missed is that this creates vastly more use-cases for these platforms than even existed pre-AI. This isn’t zero sum. Software value props have traditionally been capped at the number of users you have in a company. Agents have no upper limit.

We’re going to run agents to process data at a scale humans never could, they’re going to be running 24/7 in parallel doing work for us, and they can integrate workflows across systems to generate all new value propositions.

Once you embrace this approach, it becomes obvious how much more upside there is.

[Bill Gurley @bgurley]

https://t.co/X3MLBWJNMo

[jack @jack]

https://t.co/jgZkBvYOPt

[Richard Seroter @rseroter]

"For a developer in a terminal with their own credentials, driving a coding agent? Use the CLI."

"For an agent embedded in an application runtime without shell access? ... That’s where MCP earns its complexity."

@allen_hutchison nails it. Great post.

https://t.co/OWLVVa8Ie2

[Patrick Moorhead @PatrickMoorhead]

https://t.co/mGEyYxLwFJ

[Seema Amble @seema_amble]

https://t.co/Oz97dTr9FI

[Dr Milan Milanović @milan_milanovic]

Someone builds a project management tool with Claude Code over a weekend. Ships it. Tweets "just replaced Jira."

The app works. One user, happy path, localhost. Then two people edit the same record simultaneously, and the data is silently corrupted. They don't know what an optimistic lock is. They never needed to before.

The prototype is maybe 1% of what makes software actually work. The other 99% is what you find after real users show up: race conditions, failed transactions, sessions expiring at the wrong moment, a payment webhook that fires twice and charges someone double. AI didn't cover any of that. It built exactly what you asked for.

And the confidence is the worst part. "Just need to adjust a few things before we go live." The few things you need to adjust are the product. That's like laying a foundation and telling people you basically built the house.

Vibe coding works. For personal tools, throwaway scripts, and prototypes you'll never put in front of paying users, it's genuinely fast and good enough. I use it. But there's a hard ceiling, and it shows up the moment the stakes get real.

Agentic engineering is a different discipline. You're not prompting for code. You're decomposing problems, designing system boundaries, writing specs precise enough that the agent doesn't go sideways. You review everything it builds, because it will make mistakes that only look wrong if you know what correct looks like. You guide it. You catch what it misses.

If you don't know what a distributed transaction is, the agent won't save you. It'll generate something broken with complete confidence, and you won't know until production.

The hard part of software was never writing the first 200 lines.

It never was.

[Ben Williams @theplgeek]

If you're ramping use of agents in your dev workflow, one of the biggest ROIs you can unlock is to make your repo 'harness-ready'. I've found it effective to start with this simple prompt:

Assess this repo in terms of readiness for harness engineering as defined and explained here: https://t.co/SOBJuehxEO
Produce a prioritised list of tasks needed to move the repo into a state that you would confidently assess as harness-ready.

S/O to @_lopopolo, @thsottiaux and the @OpenAIDevs team - just loving this direction.

[The Pragmatic Engineer @Pragmatic_Eng]

This is not the first existential crisis in software engineering - says Grady Booch (@Grady_Booch) the co-creator of UML, and a legend in software engineering.

Full episode: https://t.co/GbPmClRdAn