The AI Harness Has Ten Components, Not Seven

Tomasz Tunguz published Software After AI / Harnessing AI yesterday. It is the cleanest single-page architectural breakdown of what production AI systems actually need that I have read this year. His core argument lands in one line:

Like a mustang, AI is powerful but wild. What happens when every company has access to the same model? The best riders win.

That is correct, and Tunguz lays out seven components a serious AI harness needs to win the riding contest. Read his piece. It is twelve minutes and it ought to be required reading for every CPTO and head of engineering planning their 2027 architecture.

Here is the part I want to add. The seven components Tunguz describes are the technical harness. They are what an engineer needs to build. They are not, on their own, what makes the harness win in the market. The same seven components, built to the same quality, will produce wildly different outcomes depending on three layers Tunguz under-weights or doesn’t cover at all: the human-leadership layer, the customer-engagement layer, and the business-model layer.

I have been building toward this argument across the empowerment piece, the vibe-coding piece, the GitLab Act 2 piece, and the Forward Deployed AI Engineers piece. This article ties them to Tunguz’s framework and proposes the complete shape: the AI harness has ten components, not seven.

The Seven Tunguz Names

Briefly, so you can follow without leaving this page. Tunguz’s framework, with my one-line gloss on each:

#	Component	What it is	Why it matters
1	Context & Memory	Custom retrieval, short-term memory, SOP databases that evolve with the org	Determines whether the agent knows what your business means by “contract” or “incident”
2	Tools & Action	Registry-exposed tools, validated arguments, approval gates, MCP as connective tissue	Determines what the agent can actually do, safely
3	Orchestration & Loop	Think-act-observe cycles, sub-agents, planning, retries, stop conditions	Determines how the agent recovers from its own mistakes
4	State & Persistence	Checkpoints, file systems, session threads, artifact storage	Determines whether a multi-step task resumes or restarts
5	Sandbox & Compute	Isolated Unix workspaces, controlled egress, credential management	Determines whether the agent is safe to run on production data
6	Observability & Governance	Tracing, logs, evals-as-regression-tests, human-in-the-loop	Determines whether you can debug, trust, and improve the system
7	Cost & Workflow Optimisation	Deterministic vs. non-deterministic routing, model selection	Determines the unit economics of every agent run

This is a tight, opinionated stack. Every one of those components is non-negotiable. Skip any, and the harness has a hole that will produce a stress fracture under production load. If you are building AI agents and you don’t have a clear architectural answer for each of those seven, your harness is incomplete.

But here is the thing: if every serious vendor builds those seven, the differentiation problem is not solved. It is moved. “The best riders win” is the right framing, but Tunguz’s framework only tells you what the saddle and bridle look like. It does not tell you anything about the rider, the relationship with the horse, or the prize money.

The Three Layers Tunguz Misses

8. Leadership and Empowerment

Tunguz’s framework is engineering-centric: it describes what the system needs. It is silent on who operates the system, how they are organised, and what culture they bring to operating it. That is a load-bearing omission, because the same harness produces dramatically different outcomes depending on the team running it.

I have written this argument out in full in Leading AI Is an Empowerment Problem, so the short version is this. Kief Morris’s on-the-loop position - building and improving the harness rather than inspecting every artifact - is exactly what Marty Cagan has been calling empowered product teams for twenty years, and exactly what Reed Hastings calls context not control at Netflix. The harness is the technical artifact. The way humans relate to it is the cultural artifact. You need both.

Concretely, the leadership layer of the harness needs to cover:

Talent density. Tunguz’s Observability & Governance component is only useful if there are humans on the other end of the alerts who can act on them. Empowered teams with high talent density will tighten the harness over time. Feature teams will react to alarms and ship band-aids. Same observability, different evolutions.
Empowered ownership. Every component of the harness needs an owner with the autonomy to improve it. Context & Memory without an owner becomes stale. Tools & Action without an owner accumulates dead and duplicate tools. Orchestration & Loop without an owner stops being challenged. The agentic flywheel that Tunguz’s framework enables only spins if someone owns spinning it.
Anti-rationalisation discipline. Anthropic’s open-source agent-skills framework is, in this view, a harness for the humans who build harnesses. Every skill has an explicit rationalisations section that anticipates the excuses an agent or a tired engineer will invent to skip the right process. Without this discipline encoded into how the team works, your harness gets quietly downgraded over time and you don’t notice until production breaks.

The mechanical test is this: if you imagine swapping the engineering team operating your harness from your current org to a feature-team org from a Fortune 500 bureaucracy, does the harness produce the same outcomes? Of course not. The harness is necessary; the team operating it is the variable that decides whether you win. Tunguz’s framework treats this as out-of-scope. It is not.

9. Customer Engagement and Pattern Promotion

Tunguz’s framework implicitly assumes the harness is deployed once into a single environment. That assumption breaks the moment you are selling AI-powered software to enterprises. The harness has to be operated against the customer’s reality, not yours, and the architecture has to make that engagement compound back into platform value rather than vanish into bespoke services revenue.

I made this argument at length in SaaS Isn’t Dead - It’s Picking Up Forward Deployed AI Engineers. The Palantir model is the proof point: Forward Deployed Engineers embedded in the customer’s environment, building the harness against the customer’s data, processes, and people, with an explicit weekly promotion forum that pulls bespoke patterns back into the platform. The reason Palantir has 139% net dollar retention and not the usual SaaS-flat 110% is that this layer compounds in a way an installable product never does.

Concretely, the customer-engagement layer of the harness covers:

Forward Deployed AI Engineering as a function, not as a billable consultancy. Senior engineers plus agents, embedded with customers, paid for inside the platform contract. The economics work because agents collapse the cost of services; without that, you re-create a 30% gross-margin services arm and the platform loses focus.
Pattern promotion forums. Weekly cadence, no exceptions, three questions: what did the FDEs build this week, which patterns will show up at the next five customers, who owns promoting those into the platform? This is the agentic flywheel Tunguz’s framework enables, applied to vendor-customer engagements rather than internal loops.
Customer-side Ontology. Tunguz’s Context & Memory component talks about retrieval and SOPs in the abstract. In reality, the most valuable context is the semantic, executable model of the customer’s specific business - what Palantir calls the Ontology. The FDE engagement is how that gets built. Without the engagement layer, your Context & Memory component is generic and your competitor’s is bespoke and compounding.

The honest test of whether your harness has this layer: when a customer signs up, does the harness produce value in days or in months? Out-of-the-box products produce value in months. FDE-equipped harnesses produce value in days. The market will reward the second shape, hard, for the next five years.

10. Business Model and Compounding Capture

Tunguz’s seventh component is Cost & Workflow Optimisation. That is a unit-economics view: cheap models for easy work, expensive models for hard work. It is correct and necessary, and it is also not the whole business-model picture. The business model has to match the architecture, and Tunguz’s framework is silent on the pricing side.

The architecture of an agentic harness has two distinct economic regimes:

The platform itself is high-fixed-cost, low-marginal-cost software. The economics are pure SaaS. Subscriptions are the right pricing primitive for this layer.
The agent work the harness performs is variable-cost, value-tied compute. Customers want to pay in proportion to work done, especially as agents take on tasks that used to require headcount. Consumption is the right pricing primitive for this layer.

A pure-subscription business model under-monetises high-volume agent customers and over-charges low-volume ones. A pure-consumption model penalises customers for relying on the platform and creates terrible revenue predictability. GitLab’s Act 2 letter explicitly calls out this exact hybrid as Belief 9 of their go-forward strategy: subscriptions for what customers have today, consumption pricing for the work agents do, with more flexibility to mix as the way of work evolves. Palantir is doing the same thing operationally. This is not a marketing decision; it is an architectural decision, and it belongs in the harness framework.

Concretely, the business-model layer covers:

Hybrid pricing. Subscription for stable platform value, consumption for agent-rate work, with a clear path from one to the other so customers can grow without renegotiating.
Engagement bundled into platform contracts. The FDE engagement from the customer-engagement layer cannot be sold as a separate SOW or the platform feedback loop dies. Build it into the platform pricing.
OKRs that connect agent metrics to business outcomes. Tunguz’s Observability component gives you the data. The business-model layer turns that data into the operating system of the company. Agent success rate per workflow has to sit next to product north-star metrics and revenue, or the harness is invisible to the people who decide where to invest.

The test for this layer: can you grow the harness and grow the customer’s spend in proportion without renegotiation friction? If yes, your business model is harness-aware. If renewals require pulling teeth and expansions require fresh procurement cycles, the model and the architecture are out of alignment.

The Ten-Component Harness

Putting it all together:

Layer	#	Component
Technical (Tunguz)	1	Context & Memory
	2	Tools & Action
	3	Orchestration & Loop
	4	State & Persistence
	5	Sandbox & Compute
	6	Observability & Governance
	7	Cost & Workflow Optimisation
Human / Leadership	8	Leadership and Empowerment
Go-to-market / Implementation	9	Customer Engagement and Pattern Promotion
Strategy / Capture	10	Business Model and Compounding Capture

This is the full shape. Tunguz wrote the technical-architecture half. The other three components are what turn a technical harness into a business that wins.

Each of these maps to one of my recent pieces, deliberately:

Components 1-7 ⇄ Three-Tier AI Architecture and The Skills Framework at the implementation level.
Component 8 ⇄ Leading AI Is an Empowerment Problem and Vibe Coding in Prod Is a Management Problem.
Component 9 ⇄ Forward Deployed AI Engineers.
Component 10 ⇄ GitLab’s Act 2 - The Agentic Restructure Goes Public.

If you want to operationalise the ten-component harness in 2026-27, those five articles are the operational playbook, and Tunguz’s piece is the architectural blueprint underneath.

Where Tunguz Is Definitely Right

I want to be clear that this article is extension, not refutation. Tunguz’s framework is the most useful single artifact I have seen this year for engineers planning AI systems. Specifically:

The framing of the harness era is exactly right. The transition from “software with fixed workflows” to “AI inside a harness” is the dominant story in enterprise software right now, and naming it the harness era is the right vocabulary.
The seven components are the right seven. I would not subtract any of them. Try to do without State & Persistence and your multi-step tasks fall apart at scale. Try to do without Sandbox & Compute and you eat a security incident in your first six months in production.
The competitive-advantage argument is correct. When models commoditise, the riders win. He nails this. Everyone reading his piece should internalise it.

What I am arguing is that the seven components are necessary and not sufficient. Once every serious vendor builds the same seven, the differentiation that decides who actually wins the rider contest comes from the three components Tunguz under-weights. Build the seven. Then build the next three.

A Ninety-Day Audit Using the Ten Components

The most useful thing a CPTO, VP Eng, or founder running an agentic product can do this quarter is to run the ten-component audit against their own org. The shape that has worked well in conversations with leaders going through this exercise:

Days 0-30: Score every component honestly. Walk through all ten, rate each on a five-point scale, and back the score with concrete evidence (a deploy, a customer outcome, a postmortem). Aim for brutal calibration. If three of your scores land at 4 or 5, you are probably grading yourself too kindly. Most well-run engineering orgs that have not done this exercise will score 2 or below on at least three of the ten.
Days 30-60: Invest in the bottom two. For most organisations, the bottom two are predictable. Observability & Governance (component 6) lands low because nobody wants to do the unglamorous tracing and eval work. Customer Engagement and Pattern Promotion (component 9) lands low because the FDE-style move is culturally hard for boards that grew up on pure-SaaS economics. Both are exactly where the leverage hides. Pick the bottom two on your scorecard and invest there before touching anything else.
Days 60-90: Connect the harness to business outcomes. Tie the data coming out of components 6 and 7 directly into your company’s OKRs (component 10), and stand up the first weekly pattern-promotion forum (component 9) so customer-engagement learning flows back into the platform. Establishing the cadence early is what makes the difference between a flywheel and a static product six months in.

A simple test for whether the audit has worked: at the end of ninety days, you should be able to point at each of the ten components and name (a) the person who owns it, (b) the score it was at, and (c) the score it is at now. If those three columns are populated for every row, you are operating the ten-component harness rather than reading about it. The seven Tunguz names you might already be tracking. The other three are where the leverage hides.

The Takeaway

Tunguz published the right framework at the right moment. “The best riders win” will be the line everyone quotes for the next year, and the seven components are the right starting architecture for any serious AI product team in 2026-27.

The piece I think is missing - and the piece I have been working out across the last six months on this site - is that the technical harness is necessary and not sufficient. The teams that win the harness era will be the ones who treat the human-leadership layer, the customer-engagement layer, and the business-model layer as first-class components of the same system. Build the seven, then build the next three. The leverage compounds across all ten.

If you read Tunguz’s piece this week, pair it with the five articles I linked above. Together they are the operating playbook for the next twenty-four months of enterprise AI. The riders who internalise all ten components, not just seven, are the ones who will finish the race.

References

Software After AI / Harnessing AI - Tomasz Tunguz - The seven-component framework this piece extends
Leading AI Is an Empowerment Problem - The human-leadership layer (component 8)
Vibe Coding in Prod Is a Management Problem - The individual-contributor companion to component 8
Forward Deployed AI Engineers - The customer-engagement layer (component 9)
GitLab’s Act 2 - The Agentic Restructure Goes Public - The business-model layer (component 10)
The Skills Framework - Procedural discipline inside the technical harness
Three-Tier AI Architecture - Implementation-level architectural patterns
The Last Bottleneck - Why this matters now