The squeeze is the strategy

I keep seeing the same pattern. A company building a product — could be a startup, could be a mid-market team, could be a CTO fielding board questions — bolts Claude onto support, rolls out Copilot internally, maybe ships an AI feature or two. It's useful but it's not moving the needle. Meanwhile, the platform their customers already use announces it can do half of what they do natively. The question becomes: what do we do next?

The answer isn't another AI feature. The answer is that they're caught in a squeeze they haven't fully mapped yet.

Here's what I've been tracking. There are four axes of pressure converging on enterprise AI right now, and most companies seem to only be feeling one or two of them.

First: the frontier labs are moving down-stack. Anthropic stood up a deployment company with Blackstone, Helman Friedman, and Goldman Sachs — roughly $1.5 billion in capital. OpenAI is doing the same at a reported $10 billion valuation. These aren't model companies selling API access anymore. They're hiring forward-deployed engineers to embed inside enterprises and wire agents into operating workflows. When the company shipping the model tells you the bottleneck isn't the model but the implementation layer, that's a signal worth sitting with.

Second: the big consultancies are moving up-stack. McKinsey, BCG, Accenture, PwC — they're not just doing AI readiness assessments and change management. They're building deliberate agentic deployment practices. Training delivery teams on production patterns. Showing up with engineers. They have decades of relationships with exactly the decision-makers your sales team is trying to reach.

Third: systems of record are exposing agent interfaces. Salesforce, ServiceNow, Workday, SAP — all opening APIs and agent frameworks for AI to act inside their platforms. SAP acquired Dreamio, paired with Prior Labs for a governed data play. These vendors don't need a startup sitting between their data and a customer's agent. They want the agent calling their platform directly, with their permission model and their audit trail.

Fourth: private equity has become a distribution channel. PE firms own thousands of mid-market companies, especially in finance, ops, and compliance SaaS. They're desperate to get efficiency out of those investments. A PE firm can introduce one deployment partner across the entire portfolio, compare results across companies, and standardise the playbooks where patterns repeat. That's a completely different distribution shape than vendor-by-vendor startup sales.

If you're shipping a generic AI wrapper without owning a workflow, you're getting squeezed from all four directions simultaneously. Spring 2026 is the moment this became unmistakable.

The question I keep seeing everywhere is: which AI tool should we buy? That's the wrong question. The model is a commodity — it improves every quarter and you can swap it. GPT-4 was the frontier eighteen months ago; now it's table stakes.

The right question is: where does the value in your AI investment actually live?

I've started thinking about it as a stack. Bottom to top: Model, Data, Workflow, Harness. Model is commodity. Data is necessary but not sufficient — your system of record is about to open an agent API that lets anyone access it. Workflow is closer — who owns the end-to-end process? But the real compounding value sits in the harness: the evals, the governance, the feedback loops, the audit trail, the thing that makes the system get better from use rather than just from quarterly model upgrades.

Most implementations I've studied have invested everything at the model layer and nothing at the harness layer. They've built something that works today but depreciates every time the model improves, because there's nothing compounding on their side.

I've been building AI-first platforms across verticals for a while now, and there are a handful of architectural principles I keep testing everything against. Not because they're clever, but because every time I violate one, I pay for it later.

Event sourcing over CRUD — every interaction writes an immutable event. You can derive new views without re-engineering. If your AI vendor does CRUD, you're locked into their schema and you've lost your data trail.

Skills over controllers — agent capabilities should be declarative recipes, not code endpoints. New capability should mean a new recipe, not a sprint. This is how you stay faster than Salesforce's generic agent when the domain demands specificity.

Feedback as interaction — every user touchpoint is a training signal. The system should compound from use, not just from vendor-shipped upgrades.

Three-tier context — hot, warm, cold. Assemble what the model needs; don't dump everything into the prompt and hope. Most implementations I've looked at are burning tokens and getting worse results by throwing context at the problem.

Boundary skills — the agent has explicit constraints on what it can do. Human approval at decision points. This is how you get governance without killing the autonomy that makes agents valuable in the first place.

Triple output — every interaction produces updated state, a training signal, and an audit trail. All three, always. This is the difference between a system that compounds and one that depreciates.

None of these are exotic. Most of them are well-understood in other domains. But I'm consistently surprised by how many enterprise AI implementations violate all six — and how many vendors selling AI solutions couldn't articulate any of them if you asked.

Principles are easy to list. The harder question is what changes when you actually build this way.

Take a concrete example: an accounts receivable platform that handles dispute resolution. In a typical AI integration, you'd bolt a model onto the dispute workflow — classify the dispute, draft a response, maybe auto-resolve the obvious ones. It works. Customers see value. Ship it.

Now apply the squeeze test. Salesforce announces AR agent capabilities in Revenue Cloud. Your classification model is the same one Salesforce can call natively. Your training data is sitting in the customer's CRM, which Salesforce owns. Your "AI feature" just became a thinner and thinner layer between the customer and the platform they already pay for.

Now build it differently. Every dispute interaction writes an immutable event — not just the outcome, but the context that was assembled, the confidence score, the customer's modification if they changed the response. That's event sourcing. The dispute classification logic isn't code — it's a skill recipe that a domain expert can update without an engineering sprint. That's skills over controllers. Every time a customer modifies an AI-drafted response, that modification feeds back into the system's understanding of that customer's preferences. That's feedback as interaction. The system assembles context from three tiers — the live dispute details, the customer's historical patterns, and the full event archive — instead of dumping everything into the prompt. And every interaction produces three things: the updated dispute state, a training signal from the customer's reaction, and an audit trail that compliance can query.

The difference isn't subtle. The first version gave the customer a feature. The second version built institutional knowledge that compounds with every dispute resolved. Salesforce can replicate the feature. They can't replicate six months of compounded institutional knowledge about how this specific customer's AR team handles disputes.

That's the harness. It's not a product you install — it's an architectural stance that determines whether your AI investment gets more defensible over time or less.

If you're a leader reading this and wondering where to begin, here's what I'd suggest.

Pick your highest-value workflow — the one with the most human judgement and the most repetition. Then ask three questions about it.

First: if the AI makes a mistake in this workflow, how do we know? Not "how do we know eventually" — how do we know before it reaches the customer? If the answer is "we don't have a way to trace that," you've found your first problem. The audit trail isn't a nice-to-have. It's the foundation everything else sits on.

Second: when we want to change how the AI behaves in this workflow, what does that take? If the answer is an engineering sprint, you've built something that can't evolve at the pace AI is moving. The consultancies showing up with deployment teams will be able to reconfigure faster than you can ship a release. That's not a good position.

Third: is this workflow getting better from use? Not from model upgrades — from actual customer interactions feeding back into the system. If every customer touchpoint just produces an output and nothing else, you're leaving the most valuable signal on the table. The companies that capture that signal build something that compounds. The ones that don't are running on a depreciating asset.

You don't need to rebuild everything at once. Start with one workflow. Instrument it. Get the feedback loop running. See what compounds. Then decide what's next.

The PE angle is the one I keep turning over. The playbook I've described works inside a single company. But the PE distribution model — deploy one architecture across thirty portfolio companies, compare results, standardise — that's where it either scales beautifully or breaks in ways I haven't seen yet. Cross-company patterns in agentic workflows might generalise. They might not. The institutional knowledge that makes a harness valuable could be deeply company-specific in ways that resist standardisation.

I don't have a clean answer on that one. But from what I can see, the PE firms making moves in this space are betting it generalises, and they're putting real capital behind that bet. We'll find out.