The Deployment Era
Share this:
In early May 2026, within a single week, the two largest AI companies each announced billion-dollar ventures dedicated to one problem: getting their software deployed into enterprise environments.
OpenAI launched the OpenAI Deployment Company, acquired a 150-person consulting firm called Tomoro, and partnered with 19 investment and consultancy firms including Bain, Goldman Sachs, and SoftBank. Denise Dresser, OpenAI’s Chief Revenue Officer, described the vision on CNBC: forward-deployed engineers who sit with customers, understand their workflows, and build integrations on-site. “Think about the complex workflows, about how you actually build a product service,” Dresser said. “This structure is going to allow us to do that at speed and scale.”
Days earlier, Anthropic announced an enterprise AI services company backed by Blackstone, Hellman & Friedman, Goldman Sachs, General Atlantic, Apollo, and Sequoia. Their target: mid-sized enterprises like community banks, manufacturers, and regional health systems. Krishna Rao, Anthropic’s CFO, said it plainly: “Enterprise demand for Claude is significantly outpacing any single delivery model.”
For the last three years, the AI conversation has been about models. Which one is smarter, faster, cheaper. That race continues, but the bottleneck has moved. Enterprise buyers are no longer asking “is AI good enough?” They are asking “how do I get this running in my environment?”
This pattern is not unique to AI. We have watched it play out across every category of enterprise software for years. The product gets built, customers show up, and then someone has to figure out how to deploy it into environments the vendor doesn’t control including VPCs, on-prem data centers, air-gapped networks, and sovereign clouds. Every enterprise customer has constraints, and those constraints live in their infrastructure, not yours.
If you are building a SaaS product, you have probably heard some version of the same request: “We need this running in our AWS account.” Or: “Our security team won’t approve data leaving our network.” Or the one that makes your infrastructure team go quiet: “We need this on-prem.”
The Palantir playbook
Both OpenAI and Anthropic are borrowing from the same model: Palantir’s forward-deployed engineering approach. Send smart people to sit with the customer, understand their stack, build custom integrations, and repeat for the next customer.
To be fair, these forward-deployed engineers are doing more than just deploying software. They are wiring AI into existing enterprise workflows, connecting models to back-office applications, integrating with the customer’s identity providers, logging infrastructure, compliance tooling, and monitoring systems. Dresser described it as helping customers “take that capability from their back-office applications, connecting it to the model, and then really building intelligence in terms of each of the workflow.” That is a broad scope: part deployment, part systems integration, part custom application development.
Palantir built a $60B+ company this way. But it works because Palantir is deploying one product: their own. The economics of a forward-deployed engineering team make sense when you are the vendor, the integrator, and the platform all at once.
The math changes for everyone else. There are tens of thousands of software vendors facing the same deployment challenge. Most are 50-to-500-person companies. You cannot stand up a deployment subsidiary backed by Goldman Sachs. You cannot acquire a 150-person consulting firm. You have maybe two or three infrastructure engineers, and they are already busy keeping your cloud product running.
Yet you are getting the same customer requests that drove OpenAI and Anthropic to create deployment companies.
Services vs. platform
There is nothing wrong with the services model. Consultants and forward-deployed engineers are a reasonable solution for vendors deploying their own product at high contract values. But services are inherently linear. Each new customer requires a new engagement. Each new environment is bespoke. The ratio of engineers to customers stays roughly constant.
Gil Feig, CTO of Merge, has talked publicly about their journey to customer-hosted deployments: 18 weeks for their first, eventually getting it down to 4 to 6. That is a real company describing a real timeline, and it captures the challenge well. Even when you get good at it, every deployment is still a project.
A platform approach inverts this. Instead of sending people to each customer, you build infrastructure that lets you deploy into any customer environment repeatably. The deployment logic is encoded once and executed many times. The ratio of engineers to deployments improves with scale instead of staying flat.
This is the problem we work on at Tensor9. Our platform takes your existing cloud infrastructure definitions (your Terraform, Helm charts, Kubernetes manifests) and compiles them for different deployment targets. You write your stack once, and the platform handles the translation.
We want to be honest about what this does and does not solve. Compilation handles the infrastructure transformation: mapping your AWS services to equivalents in the target environment, generating the right Terraform or Helm output, wiring up IAM and networking for the new context. It also handles a chunk of the enterprise integration work that forward-deployed engineers do manually: wiring your application’s logs into the customer’s Splunk or Datadog, connecting to their identity provider for SSO, routing metrics to their monitoring stack. These integrations are part of the compiled output, not a separate professional services engagement.
What compilation does not solve is the custom workflow building that makes up the other half of what OpenAI and Anthropic’s deployment companies do: re-engineering a customer’s business processes around AI, building bespoke integrations with proprietary internal systems, or the organizational challenges like customer success workflows and support models for distributed deployments. For OpenAI and Anthropic, deploying their own product, the services model makes sense for that work. For the thousands of other software vendors who need to get their product into customer environments, the infrastructure and integration layer is the part that should be automated.
The ripple effect
Here is what we think happens next.
OpenAI and Anthropic will spend the next 12 to 18 months deploying AI into hundreds of enterprise environments. In the process, they will normalize a new expectation: serious enterprise software runs where the customer says it runs, not where the vendor prefers.
That expectation will not stay contained to AI. Once a bank has OpenAI running in their VPC, they will turn to their observability vendor, their data pipeline vendor, their security tooling vendor, and ask the same question. “If OpenAI can deploy here, why can’t you?”
Most of those vendors will not have a good answer. The ones who do will win deals. The ones who don’t will lose them to competitors who figure it out first.
This is a pattern we have watched repeat across every compliance-heavy industry. The first vendor to deploy on-prem in a customer’s environment raises the bar for every vendor that follows. AI is about to accelerate that cycle.
What this means if you are a SaaS vendor
If you already deploy into customer environments, you know how expensive and manual it is. The announcements from OpenAI and Anthropic are a signal that customer expectations are about to ratchet up. What used to be a nice-to-have for your largest customers is becoming table stakes across your buyer base.
If you do not yet offer deployment into customer environments, the window to figure it out is narrowing. Not because AI companies are your competitors, but because they are training your customers to expect it.
The deployment era is here. OpenAI and Anthropic just spent billions to confirm it. The vendors who treat customer-deployed software as a core capability, not an afterthought, will have a structural advantage in every enterprise deal for the next decade. The good news is that you do not need a billion-dollar services company to get there. You need the right infrastructure.
See it with your own stack
Tensor9 compiles your existing cloud infrastructure for new deployment targets. You point Tensor9 at your infrastructure as code, and it is compiled for a different environment: your AWS stack rewritten for on-prem Kubernetes, your cloud services mapped to their equivalents in a customer’s VPC, your logging and monitoring wired into their customer’s Splunk or Datadog. You keep your IaC. The output is real, deployable infrastructure code that your customers install in their own environments.
The fastest way to understand what that looks like in practice: bring your stack and we will run the compilation with you. Learn more at https://www.tensor9.com/schedule-stack-assessment/.
