Someone in your company built something to learn or fix an immediate problem, not to run as a production service. That’s happening more frequently with AI-enabled development. They built to learn, not to earn, to borrow Marty Cagan’s vernacular. The artifact they created exists to test an idea, a workflow, or a customer reaction — not to carry production commitments. But sometimes the customer sees it and wants it anyway. That’s the moment your company starts running a second operating model, whether it realizes it or not.

Ok, so now you’ve got something that was shown to the customer and they’re into it. That’s the moment we’re all looking for. You had an internal experiment that you thought could work and the customer agreed. But the minute a customer wants that new vibe-coded hotness, you have a situation your standard MSA (Master Services Agreement) wasn’t written for. So, what terms do you let them use it under? You don’t want to get in people’s way or tamp down on the enthusiasm of the builder or the customer. But most MSAs implicitly assume two things: that the software was built by engineers who can carry production responsibilities, and that the organization behind it has committed to uptime, support response SLAs, and remediation when something breaks. The new builder can’t make those commitments personally or on behalf of the organization, nor should they be asked to. And the data flowing through this built-to-learn artifact is the same customer data that lives under jurisdictional obligations that don’t have a beta exemption. Depending on what your company does, this could be PII and ultimately be held to an even higher standard.

The answer you feel like you want to give is something like, “make it production-grade first, then ship it.” Sometimes that’s right. Usually it isn’t. You end up optimizing for delivery before you’ve learned enough to know what should be delivered, killing the things that made the experiment valuable in the first place: the speed, the closeness to the actual customer problem, and the willingness to ship something rough and learn.

The reason is that you’re trying to force discovery work into a delivery operating model. Done right, discovery creates energy because the builder and customer are learning and solving problems together. Delivery creates obligations because the company is making commitments.

Discovery and delivery aren’t opposites. They’re different phases of the same work. The mistake is pretending they’re governed by the same commitments.

One MSA, two operating models.

Discovery Needs Its Own Operating Model

This mismatch is what most companies live with. They (typically implicitly) decide to skip the transition entirely, ship the capability under the existing MSA and hope nothing “breaks”. I try to assume positive intent here. People aren’t being malicious — they’re trying to solve customer problems and take initiative. They either don’t know better (these situations are above their pay grade), or they don’t want to go through the organizational headaches that would come with doing it the “right” way.

That works until it doesn’t. When it doesn’t, the customer has a clean contractual path to clawbacks, broken commitments, and remediation obligations the company can’t (or doesn’t want to) actually meet. And god forbid any of this happens around renewal time and affects the tenor of those discussions (or the entire commercial relationship).

This is where the second operating model becomes a deliberate design decision. That operating model isn’t another engineering organization. It’s a different set of commitments, commercial terms, and operating rules for discovery work before it becomes production software. An experienced CTO recognizes that discovery is already operating under different assumptions than delivery. The move is to formalize those assumptions into an operating model built for innovation — one that, where relevant, supersedes the standard T&Cs (Terms and Conditions) or your general MSA.

It’s easy to go with the standard pushback that this is expensive — legal cycles, procurement loops on the customer side, potentially more deal-desk friction on contracts or renewals. Those are real concerns.

They also shouldn’t be surprising. Different operating models naturally invite different contractual discussions. If procurement asks why the terms changed, that’s not a sign something went wrong. It’s a sign the contract is catching up to the way the service is actually being delivered.

The simple counter is that it’s still cheaper than the alternative, which is paying out clawbacks and remediation on commitments the company couldn’t keep in the first place.

Contracts Follow the Operating Model

Most CTOs treat contracts as a legal artifact. Legal drafts them. Sales negotiates them. Someone you’ve never met on the customer side signs them. You approve the exceptional ones at deal desk or hear about them when something goes wrong.

A contract is a coherence claim.

It says: these are the commitments we make, and these are the conditions under which we make them. Someone has to make those commitments true. Many of those someones report to you. The contract is downstream of the operating model that makes those commitments real. If the operating model changes and the contract doesn’t follow, you’re committing to things you can no longer deliver.

This isn’t a new AI phenomenon. SaaS changed contracts. GDPR changed contracts. DORA and the Cyber Resilience Act changed contracts. Every operating model shift eventually forces the commitments to catch up. AI-enabled building didn’t invent the principle; it compressed the timeline. What used to take years can now happen in a quarter because the population of people who can build and deliver software just expanded drastically.

The Second Operating Model Already Exists

The thing AI changed isn’t what software is. It’s who can build it. I’ve written before about infrastructure by adoption and polish levels as ways to recognize and classify software built outside traditional engineering workflows.

This article is about what happens next. Specifically: standalone applications built and shipped alongside your core product, or features that fill gaps in it — all governed by a different operating model. Some companies call these innovation programs. At Mapp, we call ours Mapp Labs. Michael Diestelberg’s companion piece covers the product view of the platform side; this one covers the contractual and operational mechanics.

Innovation programs used to require skunkworks teams staffed by experienced engineers and PMs, and most of those programs starved competing with the product roadmap for capacity. AI changed the math by lowering the technical barrier to entry.

A solutions architect, a sales engineer, or even a CSM can ship something real now. They typically don’t have the experience to think through all of the standard productionization concerns of build-to-earn software, and they’re not going to take a 2am page on a Saturday when their tool falls over. That’s not a failure. It’s the right division of labor. But the operating model behind their software is fundamentally different from the operating model behind a production feature, and a contract that doesn’t reflect that is selling something the company can’t deliver.

The Constants Hold, the Rest Flexes

The first job is to separate what remains constant from what can flex. GDPR doesn’t have a beta exemption. Your DPAs (Data Processing Agreements) don’t either. Your SOC-2 controls don’t relax because the builder was a CSM. Compliance posture, basic security, and customer trust are constants, regardless of who built the software or how long it took them to create it. If your operating model can’t hold those, you’re operating under the wrong TOM (Target Operating Model).

Once the constants are protected, the rest of the commitments can flex. SLAs and SLOs, support models, ownership of failure modes, remediation terms, and pricing structure are all things that can flex pretty readily and most customers are open to. But these are things the new builder genuinely can’t commit to. They are also things that your MSA, written for build-to-earn, production-grade systems, assumes by default. The CTO move is to codify what flexes in a contractual envelope that supersedes the MSA for the relevant scope — a Labs SOW (Statement of Work), a beta addendum, a subordinating MSA, new T&Cs (Terms and Conditions), whatever your legal team wants to call it. It’s not a handshake agreement between a CSM and customer. It’s a real document the customer signs that says: this is built differently, supported differently, priced differently, and we’re both clear on those terms and adjusted expectations going in.

Operationally, that means the builder owns functional fixes and triage on their own work. Technology owns the constants: security, compliance, and the underlying infrastructure. Best-effort support everywhere else, with the boundaries written into the SOW.

The point of writing it down is that it’s bilateral. The company stated it and the customer agreed. Six months from now when the tool has an outage over a weekend and the response takes 47 hours, you’re not in breach of contract. You’re operating exactly as the new contract terms outline.

The new contractual model also gives you a natural opportunity to standardize your agreements over time. New capabilities ship under it by default, while existing agreements can move onto the same foundation during renewals, expansions, or other commercial discussions. Instead of accumulating contractual drift, you’re using the operating model transition to reduce it.

The Defensive Read Misses Half of It

It’s easy to read the new operating model as a defensive move: fewer clawbacks, fewer contractual surprises, fewer commitments you can’t (or won’t) actually keep. That’s all true.

But it’s also only half the story.

The same contractual envelope creates a commercial one. It formalizes something that was probably ad hoc before, if it existed at all. The cost dynamics of AI features — variable API costs scaling with use — usually don’t fit inside flat SaaS subscription line items. Consumption pricing isn’t optional once you’re shipping AI capabilities at scale; the cost volatility forces it if you’re calling external model APIs directly. What the new TOM does is create the contractual space where consumption pricing can actually live. Usage credits, upsell on overage, a new line item for the revenue team to sell. That’s lower margin than your core product, but it’s real revenue against a cost basis that would otherwise eat your margin from underneath. And revenue is revenue, right?

The DPA work sits in this same envelope. New AI vendors mean new sub-processors. The permitted-personnel scope in the old DPA probably doesn’t cover the people who now have access to the data. Customer opt-in for PII into LLMs is a clause that didn’t exist before because it didn’t need to. None of this is exotic — it’s the same kind of vendor-terms maintenance the company has always done — but it’s another piece that has to land at the same time as the SOW and the pricing changes for the whole thing to be coherent.

The pricing model is the obvious commercial benefit here. The less obvious benefit is what paying for beta software does to the customer relationship. When customers are paying for what they use, the skin in the game often helps them to show up to feedback conversations differently. They want roadmap input because they’re funding the build. They’re closer to your team. That’s the discovery model working as designed — customers as co-investigators, not only consumers of finished work. It also tends to make renewals easier since you’re shipping things they already asked for and use. The new TOM, properly built, makes your commercial team’s job easier across the board. All of this depends on having the culture and feedback infrastructure to support it.

The commercial upside is a direct consequence of the new operating model, not an accidental side effect. When the contractual model matches the operating model, you can price AI work coherently, involve customers earlier, and turn what used to be ad hoc experimentation into something the business can actually sell.

Why This Is a C-Level Move

Notice how many functions we’ve already pulled in. Commercial. Legal. Operations. This isn’t a move that the CTO can make alone. The new builders also sit in those other functions. The new envelope’s rules apply to everything they ship, and the constants like compliance and security apply regardless of who reports where. Your senior peers have to be aligned for any of this to actually work. Without that, the new TOM is just a document.

This isn’t about putting builders in fear around what they ship. The envelope exists so the team can keep moving fast without the company being on the hook for commitments it can’t keep. The flex is what gives the team room to move.

Where I sit, tech support reports to me, so the support SLAs in the new envelope are mine to commit to. In other orgs, support sits under customer success or operations, and those SLAs are someone else’s commitment. Compliance might sit under legal, under tech, or be its own org. Revenue ops sits wherever it sits. No single role has the full picture, which means no single role can drive this alone. Whoever has the most context can kickstart the conversation. The work itself is a senior team operation, and that’s also what brings peers along.

Getting everyone on board with an initiative like this is part of the job of leadership. Running engineering doesn’t end at the engineering boundary. If you’re on the SLT, you’re running the company alongside your peers, and the company’s commitments to its customers are a thing you own a share of.

The Innovation Program You Already Have

What this looks like in practice is a company that can do something it couldn’t before. It can put non-engineer builders in front of customers without the company being on the hook for commitments those builders never made. It can charge for what it’s actually delivering, including the parts whose costs are volatile, in a way that survives the next pricing change from a model vendor. The DPA, the SOW, the pricing, and the support model are all coherent with each other and with what’s actually being built. The result is a tighter customer feedback loop because the operating model keeps customers involved throughout discovery. Now customers are funding the work, shaping what’s being built, and sitting inside the conversation. Companies that adopt this model learn faster than the ones that don’t.

The company that hasn’t done this is still shipping AI features under an MSA written for a different operating model and finding out, deal by deal, that those two things don’t match anymore.

It’s often up to the CTO to recognize that the operating model changed. The first time someone close to your customers shipped something a customer wanted, the line was crossed. The only real choice now is whether the operating model behind that program was built deliberately or assembled in panic after nearly costing you a customer.

This isn’t about whether to do innovation programs. The tools to build software are already in your team’s hands. The people closest to customers are already shipping. The customers want what they’re getting. An operating model that doesn’t support that is one you’re going to be patching anyway, with worse terms and less time. So it’s better to make it intentional.