Rent, Build, or Both: What Cloud Can Teach You About AI

In June, Salesforce agreed to buy Fin, the customer-service AI company formerly known as Intercom, for $3.6 billion. The detail worth pausing on isn’t the price. It’s how Fin got there. Fin started on off-the-shelf frontier models. It now runs on Apex, a purpose-built model the company post-trained on its own support data, and which it claims resolves customer issues at a higher rate than the top frontier models available. Intercom’s own framing: “the age of vertical models is here.”

A while back, in this newsletter, I warned against treating token consumption as a scoreboard. Since then, the conversation has already moved. With the Anthropic and OpenAI filings putting everyone in armchair-valuation mode, the question of the moment is cost: what’s the right infrastructure to run AI at scale without writing a blank check to a model provider you don’t control?

The reflexive answer you might hear is “build your own.” Rip out the expensive frontier APIs, stand up open-weight models, fine-tune on your own data, capture the savings. And just like tokenmaxxing, the overcorrection is its own trap. What I’ve actually been hearing more of is that the future isn’t all-rent or all-build. It’s hybrid.  And the hard part of hybrid isn’t the architecture. It’s the people.

We’ve Run This Play Before

If hybrid sounds familiar, that’s because we’ve lived it once already. Fifteen years ago, the debate was public cloud versus your own data center. Purists on both sides were sure their model would win outright. Neither did. What won was hybrid cloud: workloads placed where they made sense, the ability to move them, and teams who understood the seams. The same shape is forming around AI. You will use some combination of frontier models you rent and open-weight models you train, routed by cost, latency, accuracy, and how much you care about keeping your data out of frontier models.

There’s a clean logic to it that maps onto a distinction I made last issue. In the science phase,  when you’re still discovering whether an idea works, a frontier model an API call away is exactly right. It’s the fastest way to prove you’re onto something. Most of the time the prototypes in this phase fail, so the goal is to fail fast and cheap. The engineering phase is when you harden it: this is when it might make sense to fine-tune a smaller open-weight model on your proprietary data, optimize inference so the savings are real, and enrich it with context you’d never want to ship to a public model. Fin’s journey from GPT to a vertical model is that arc in miniature. So is the broader pattern in software history: you start with a vendor when you’re figuring it out, and you invest in your own team once it becomes core to your business.

For some, 100% build may not be realistic. Some companies may prefer a relationship with a frontier model vendor, for support and operational reasons; while others may be more comfortable self-managing open weight models. But the real divide won’t be between companies that rent and companies that build. It will be between companies with the talent to manage the seams, and those that simply swap one dependency for another.

Different Skillsets, Different Roles

That said, the hybrid model won’t happen overnight. Your senior engineers are dramatically more AI-capable than they were two years ago. They use coding agents fluently. They’ve stood up a RAG pipeline. From where a CIO sits, it’s easy to look at them and conclude the team is ready to go hybrid.

That conclusion is the trap. The rise of AI-assisted development has closed the gap on the easy half of the skill set. The engineer who uses AI tools fluently is currently not the same hire as the engineer who can benchmark open-weight models against frontier ones for a specific use case and route work between them. The first skill has converged into what we now just call a good senior engineer. The second hasn’t converged yet. It remains genuinely scarce.

What does the hard half actually look like? This may change, but the trend in AI engineer job descriptions typically includes roughly five capabilities. Notice they’re all permanent functions, not one-time setup:

• Benchmarking and routing work continuously between frontier and open-weight models as new ones ship.
• Fine-tuning open-weight models on your own data, with techniques like LoRA.
• Evaluating model outputs in production, monitoring drift, and knowing when to roll back or retrain.
• Curating the internal training data that makes your fine-tuned model better than a generic one.
• Optimizing inference so the cost advantage is real and durable, not theoretical.

You can’t hire a consultant to own your model quality in perpetuity. Someone inside the building has to. And the market knows it: Stanford’s 2026 AI Index found that mentions of agentic-AI skills in US job postings jumped more than 280% in a single year, to roughly 90,000 listings. Furthermore, AI job postings are increasingly asking for the skills to build and manage systems at scale, not just talk to a model. The center of gravity has moved from model interaction to system architecture. The job titles are moving with it.

What Hybrid Demands of Your People

Two implications follow, and they pull in different directions. The first: forward-deployed engineers, the Palantir-style specialists everyone is suddenly hiring, are a real accelerant, but treat them as enablement, not a crutch. Using a system that someone else stood up is not the same as owning it. The team that builds the system alongside the experts, and then rebuilds it themselves, also builds ownership. Renting the skill to get started is smart. Renting it forever means you’re paying a babysitter for a system no one on your payroll actually understands and every version change becomes a project with external dependencies to manage.

The second is about evolution. A lot of what made someone a specialized AI engineer a year ago has simply folded into what we expect of a strong senior engineer today. Appropriate model selection, for instance, used to be a data-science concern and is now something you’d want every developer to think about before they route everything to the most expensive model. The specialist skills of 2026 become table stakes in 2027. Which means the people who understand the hybrid stack now are the people most likely to understand whatever comes next. That’s an argument for keeping a few of them on the front edge of the role permanently, not because the current shape is final, but precisely because it isn’t.

What to Do Now

• Treat hybrid as a talent decision, not just an architecture decision. The build-vs-rent choice you make at the infrastructure layer quietly rewrites the team you need. Decide them together.
• Don’t mistake AI fluency for hybrid-readiness. As you ramp your prototyping practice, get an honest read on whether your people have the hard half: benchmarking, fine-tuning, eval, data curation, inference optimization. Don’t stall prototyping to get the hybrid team built, but don’t ignore hybrid skills and expect frontier-based prototypes to be permanent architectures. Longer term, you’ll want the options to optimize for cost, performance, and privacy.
• Rent to start, then build the muscle to own it. Use frontier models and forward-deployed engineers to help move quickly, but structure the engagement so your team comes out able to run the thing without them, and keep hiring at the frontier of the role so you don’t fall a year behind.

What We’re Watching

At Karat, we’re seeing this in real time across our clients: the rush to hire “AI engineers,” and the quiet difficulty of knowing whether a candidate actually has the scarce half of the skill set or just interviews well in an AI-fluent market. The role is being rewritten faster than most hiring rubrics can keep up and mis-measuring it during a structural shift means staffing up confidently and stalling later. As we build the next generation of technical assessment for the Human + AI era, the skills we’re working to measure are exactly these: model judgment, systems thinking, and the ability to build something you’ll still understand a year from now.

Rent the model if you have to. But before you commit to building on top of it, ask the question that determines whether hybrid works: who, inside your walls, is going to own what you build long after the consultants have gone home?

Jeff Spector is the Co-Founder and President of Karat, the trusted standard for measuring talent quality. Karat helps engineering leaders at companies like PayPal, Atlassian, and Citi make their most important talent decisions through human-led, AI-native talent evaluation.