When AI Gets Cheap, Execution Becomes the Only Margin

I have seen this movie in different costumes. Hardware commoditizes. Cloud primitives get cheaper. Tooling spreads. The thing that stays scarce is not the component, it is the ability to make it behave inside a real operation.

AI is on the same path. If you are betting on raw model margin, the math will eventually turn against you. Someone will offer similar capability at a lower cost. Someone else will bundle it. Another player will run it on smaller models closer to the work. You can argue timelines, but you cannot argue direction.

So I treat “AI margin” as an illusion unless it is anchored in execution. The defensible margin is the ability to integrate AI into workflows, keep it reliable, and produce measurable outcomes quarter after quarter. That is not a product marketing line. It is operations.

The shift: from token economics to operational economics

In a boardroom, the question is not “What model do we use?” The question is “What unit of work gets cheaper, faster, and safer?” That is operational economics.

When I ran an international business unit in smart-building and home-automation, margin did not come from the bill of materials alone. It came from reducing returns, improving delivery reliability, and making service scalable across markets. The same principle applies to AI. The “model” is not the product. The product is the operating improvement it enables.

When model costs trend down, two things happen:

• Inference becomes a variable input. Like electricity in a factory or SMS fees in a consumer app, it matters, but it rarely justifies a durable premium.
• Integration becomes the constraint. The bottleneck shifts to process design, data contracts, QA, and change management.

If you want margin that holds, you need to own the constraint.

Budget AI like an ops improvement program, not a science project

Operators mis-budget AI in a predictable way. They over-fund the model and under-fund everything that makes the model useful in production. Then they call the initiative a failure.

I budget AI the way I used to budget quality and reliability programs in industrial tech. The spend goes where the risk and rework live.

Here is the order I use:

1. Workflow mapping and ownership. Name the process owner. Define the “before” and “after.” If you cannot describe the handoffs, you cannot automate them. This is the same thinking I wrote about in AI value and the stop button. If nobody owns the stop button, nobody owns the outcome.
2. Integration first. Your model is a brain in a jar until it can read and write inside the systems where work happens. ERP, CRM, ticketing, PLM, MES, email, spreadsheets. Integration is not glamorous, but it is where cycle time is won.
3. QA and monitoring as a product, not a task. In consumer electronics, when I owned QA and test across hardware and software, the biggest cost was not the test equipment. It was the defects that escaped and came back as returns and support load. AI is the same. You need systematic test cases, regression suites, and live monitoring.
4. Training and incentives. If people are measured on output but AI changes the steps, you need to update the measures. Otherwise, you get shadow processes and silent rejection.
5. Model spend as variable COGS. Treat it like a line that you expect to fall. Negotiate it. Multi-source it. Design so you can swap it.

This budgeting stance does two things. It protects you from model price compression. It also forces you to build the capabilities that create real operating leverage.

What to measure: run AI like a critical system

Most AI teams report model-level metrics that do not translate into operational control. Precision, recall, benchmark scores. Useful, but incomplete.

As a former COO in electrification and energy storage, I cared about metrics that linked to delivery and risk: uptime, lead time, scrap, rework, field failures. If an AI system touches customer commitments or internal throughput, it deserves the same seriousness.

My baseline scorecard looks like this:

• Uptime: Is the capability available when the operation needs it?
• Latency: Does it respond within the decision window of the workflow?
• Accuracy for the task: Not generic accuracy, but accuracy on your real cases, including edge cases.
• Cost per resolved task: Total cost, including human review, escalations, and rework.
• Escalation rate: How often does it hand off to a human, and why?
• Rework rate: How often does downstream work need correction because of the AI output?
• Change failure rate: When you update prompts, tools, or models, how often do you break the workflow?

Two operator rules:

• If you cannot roll back safely, you are not ready to scale. That is a release discipline problem, not an AI problem.
• If you cannot explain a miss, you cannot improve it. Treat incidents like you would treat a production deviation.

This is also why I like smaller, more controllable deployments where it makes sense. I have written about that mindset in shipping AI with small models. Control beats cleverness when the cost of failure is real.

Pricing: sell outcomes, not tokens

If you price AI as “tokens plus markup,” you are choosing a race to the bottom. You are also misaligning incentives. The buyer wants fewer tokens, fewer steps, fewer errors. You want more consumption. That ends badly.

Outcome pricing is harder, but it matches how operators think. Tie fees to the unit of improvement your customer actually cares about:

• Throughput: cases closed per day, quotes produced per week, claims processed per hour.
• Error-rate reduction: fewer wrong invoices, fewer false escalations, fewer compliance misses.
• SLA-backed performance: response time and availability for a defined workflow.

In SaaS and fintech work, I learned to be explicit about the boundary between automation and accountability. If you are going to price outcomes, you must also define:

• What inputs you require (data quality, system access, human review rules).
• What is in scope (which workflows, which languages, which exception types).
• What “good” means (acceptance criteria and auditability).

Outcome pricing without operational definitions becomes a contract dispute. Outcome pricing with operational definitions becomes a partnership.

A practical lens: where your defensible margin actually lives

I use a simple lens when I evaluate an AI product or initiative. Ask where the defensible margin sits, then invest there.

• Model margin: fragile. Expect compression.
• Data access margin: sometimes durable, often political. You still need execution to use it.
• Workflow integration margin: durable. Painful to replicate.
• Reliability margin: very durable. Most teams do not have the discipline.
• Change management margin: durable. Underestimated by technical teams.

When I build ventures like Shopeno and IBHQ, I assume the underlying AI capability will get cheaper and more available. The differentiation has to be in how the product fits the workflow, how safely it operates, and how quickly it improves without breaking trust. That is the only way to build something that survives a pricing reset.

The same holds in industrial environments. Reliability is a contract you pay for and enforce. I made that point explicitly in ruggedization as a reliability contract. AI is no different. The reliability work is where the margin hides.

My checklist for the next quarter

If you are a board member, owner, or operator and you want to make this actionable fast, here is what I would push for in the next 90 days:

1. Pick one workflow with clear volume and pain. Not a demo. A real queue.
2. Define the unit of value. Time to resolution, cost per case, rework rate, SLA compliance.
3. Instrument the baseline. If you cannot measure “before,” you cannot claim “after.”
4. Fund integration and QA ahead of model spend. Make the model swappable.
5. Ship with a stop button and rollback. If it cannot fail safely, it will fail loudly.
6. Operationalize monitoring. One dashboard that the process owner actually uses.
7. Price or internal-charge by outcome. Make incentives align with less waste, not more tokens.

My opinion: the winners will look like operators, not model resellers

AI will keep getting cheaper to run. That is good news for everyone, but it destroys businesses that confuse input costs with value creation.

The companies that keep margin will be the ones that can take messy reality, map it into a workflow, integrate deeply, and run the system with reliability discipline. They will talk less about models and more about throughput, defects, and SLAs. They will treat AI as an operational capability, not a feature.

If you want defensible margin, stop asking how to monetize inference. Start asking how to monetize execution.