The Product Is Not The Model: The Enterprise Harness Is

The AI space is burning enormous amounts of power making comparisons between models: reasoning metrics, context windows, coding capabilities, latency, cost per token.

Those comparisons are important. But they are less and less the right altitude for enterprise decision-making.

As the source article notes, the same model can produce very different results depending on what it is surrounded by. Chatbots are the interface that puts a powerful model to work answering questions. Take that same model and put it inside a well-designed agent harness – with tools, context management, memory, permissions, verification, and observability – and it can run complex workflows.

This alters the thesis on enterprise AI investments.

The model gives intelligence. The harness is what makes that intelligence a dependable enterprise capability.

This is important for boards and CXOs because models will continue to improve, converge and be replaced. It’s the architecture around that that dictates how far we can trust AI with increasing responsibility.

1) Repackage the architecture – the model is the engine, the harness is the OS

There’s a good analogy in the source article . The model is the engine, the harness is the car .

The model’s reasoning and predictions. The harness controls what the model can see, what tools it can invoke, how things are executed, what happens when something goes wrong, what permissions apply, how progress is verified, when the system has to stop or escalate.

The diagram on page 4 collapses agentic execution into the deceptively simple loop:

Goal -> Context -> Model Decides -> Executed by Harness -> Observed Result -> Model Decides Again

Enterprise risk is a part of that loop.

The chatbot might give a bad answer.

A bad answer can be generated and acted on by an agent associated with enterprise systems.

Board position = model intelligence = potential ability. Harness maturity controls deployable autonomy.

2) Think of the harness as seven enterprise control capabilities

The source states that there are seven components of a production agent harness. They should not be considered as mere software components. Together they make the enterprise control architecture for autonomous AI.

1. System instructions — operating command

Specify the agent’s function, purpose, constraints on actions, escalation criteria, and interaction protocols.

2. Tool layer – action surface

Exact identification of the set of systems with which the agent can interact and the actions allowed by each tool.

The source makes an important design point that smaller, sharper tools generally trump sprawling collections of overlapping capabilities.

3. Working knowledge of context management

Control what information gets into the model’s finite context and what gets removed, summarised, retrieved later, or persisted somewhere else.

4. Memory — institutional continuity

Separate temporary session context from persistent project, user or episode knowledge.

5. Authority boundary – guardrails, permissions and sandboxing

Know which actions are automatic, which require policy enforcement, which require human approval, and which are forbidden.

6. Validation – external evidence

Provide the agent with mechanisms to verify that its work actually worked, not just let it declare its own success.

7. Accountability record — observability

Log model calls, tool calls, errors, tokens, decisions, execution paths to reconstruct failures.

Board translation: These seven components together respond to four questions: What does the agent know? What can it do? But how do we know it worked? Who can prove it took place?

3) Reliability equation changes with long term autonomy

One of the strongest observations in the article is not architectural, but mathematical.

Small error rates compound for long running tasks.

This is illustrated by a model that is 99% reliable at each step. The probability of success for each of the 50 steps falls to around 60%.

This is the reason why agentic reliability can not be boiled down to model-level benchmark scores.

Enterprise workflows are chains:

plan → retrieve → decide → call tool → observe → revise → call another tool → verify → act.

With each step, another opportunity for something to go wrong.

The harness needs retries, checkpoints, validation, iteration limits, failure recovery and escalation paths.

Board implication: Increased autonomy without reinforcing the harness creates non-linear operational risk.

4) Define autonomy as a controlled progression

The article repeatedly emphasises permissions, sandboxing, verification, and human involvement. Enterprise operating models must translate those ideas into explicit levels of autonomy.

Tier 1 – Counsel

The agent retrieves, reasons, drafts, recommends. They do that.

Tier 2 – Operate within limits

The agent takes reversible, low-risk actions using approved tools and stays within the boundaries of the rules.

Tier 3 – Execution of sign-off

The agent prepares consequential actions, requiring authorisation before execution.

Tier 4 – Limited autonomy

The agent independently executes defined workflows with ongoing monitoring, hard limits, verification and escalation.

Autonomy should be earned by proven reliability, not given because a model seems capable.

5) Design explicitly for how agents fail.

The source’s failure-mode section (pp. 19–20) is particularly relevant to enterprise governance, since the problems are predictable.

context rot:

long sessions accumulate stale information until the agent forgets the objective.

Runaway loops

The agent keeps trying the same unsuccessful strategy again and again.

Tool sprawl:

overlapping tools increase selection mistakes.

Prompt injection —

untrusted external content attempts to manipulate agent behaviour.

Overconfident termination:

the agent declares it has succeeded, but does not check itself.

Cost of compounding:

Multi-agent execution leads to unexpectedly large bills for tokens and infrastructure.

Silent capability drift

Changing the core model causes behaviour change without changing application code.

These should be the default risk scenarios for enterprise agent design reviews.

You don’t want to eliminate the failures.

It is to make failure bound, detectable, recoverable and accountable.

6) Verification is the space between plausible work and responsible work

Agentic systems pose a nasty governance problem: the system that does the job can also claim the job succeeded.

That’s bad design control.

Mature harnesses have mechanisms for agents to check their work. Coding agents run tests and linters ; research systems validate sources ; browser agents inspect the resulting screens ; other systems use independent models or rubrics before accepting an outcome.

The principle of enterprise should be:

Do not use self-reported completion as the control for consequential autonomous work.

Verification requires evidence.

Depending on the workflow this could be transaction confirmation, reconciliation, policy validation, test execution, source verification, state comparison or human approval.

Board translation: trust can only rise where it is accompanied by a rise in independent verification.

7) Put economics in the harness

Agent economics is not chat-bot economics.

A single user request can invoke dozens of reasoning steps, retrievals, model calls, tool calls, retries, and potentially multiple sub-agents.

The source refers to agents as ‘token furnaces’ and states that cost and latency must be managed at the harness level.

• Prompt caching
• Model routing
• Parallel execution
• Budgets

These are practical controls.

Boards should therefore look beyond cost per token to:

• cost per successful workflow
• model calls per finished task
• retry verification cost cost
• average number of agent steps per result
• multi-agent vs single-agent cost
• cost of human intervention
• business value per autonomous execution

Maybe an agent that does a $20 job for $2 is worth it.

A fancy multi-agent architecture that does the same job for $18 may just be sophisticated inefficiency.

8) Multi-agent needs to be earned, not just assumed

Industry is increasingly associating agent sophistication with multi-agent architecture.

The source is a lot more disciplined.

Its diagram on page 13 describes an orchestrator which delegates work to specialised sub-agents in isolated contexts and synthesises their conclusions. The important advantage is not parallelism, it is context isolation. But the article also points out the trade-off: multi-agent architectures consume more tokens and add coordination complexity.

The rule for the enterprise should thus be: .

Employ a single agent until the task demonstrates that a single context cannot reliably house the work.

Then introduce specialisation where decomposition results in observable improvements in quality, speed, or control.

Maturity is not complication.

9) Match harness architecture, not framework

The article reviews a number of agent frameworks, but its larger point is more enduring than any framework choice: frameworks provide implementations; the underlying harness responsibilities remain.

So enterprise architecture should normalise :

• identity and permissions
• tool contracts
• context patterns
• memory limits
• evaluation requirements
• observability
• checkpointing
• human escalation
• cost controls

Those capabilities should outlive changes in model and framework.

Board implication: Don’t construct enterprise governance on the basis of whatever agent framework leads the market this quarter.

10) Measure harness maturity before extending autonomy

Boards need a handful of measures that show whether autonomy is getting safer or just bigger.

A good scorecard should include:

Reliability:

• task completion rate,
• verification pass rate,
• retry rate,
• loop termination rate,
• human override rate.

Risk:

• Unauthorised tool attempts,
• policy interventions,
• prompt injection events,
• sensitive action approvals.

Economics:

• cost per successful task,
• token-consumption,
• cost of retries,
• multi-agent amplification.

Operations:

• Full end to end traceability,
• recovery rate from checkpoints,
• success rate of escalations,
• mean time to diagnose failures in agents.

Quality:

• evaluation pass rate,
• regression rate after model changes,
• and performance on representative production tasks

The source makes a good point about evals: teams need representative tasks with checkable outcomes, and new prompts, tools, or models should be tested against them before release.

That makes evaluation the equivalent of CI/CD for agent behaviour .

What leaders must not do

Three patterns look good, but are ageing badly.

Model-first architecture

Teams optimise around the best model, and treat everything else as plumbing. Architecture debt remains; model benefits erode.

Pre-verification autonomy.

Organisations increase the scope of what agents can execute before they develop independent evidence of successful execution.

Multi-agent by default.

Adding more agents adds context, coordination, reliability, and cost problems, while appearing sophisticated.

What the source ultimately argues for is a better architecture: thin harnesses around increasingly capable models — but with durable controls treated as core product engineering.

Closing – Own the Control Layer

The strategic error would be to assume that better models will eventually render sophisticated harnesses obsolete.

No doubt some of the scaffolding will be removed as the models get better.

But better reasoning does not remove the enterprise need for permissions, context, verification, auditability, cost controls, tool boundaries or accountability.

That’s not the weakness of today’s models.

They are the enterprise’s autonomy requirements.

The models will be better than some else’s roadmap.

Model economics will go on some other pricing curve.

Frameworks will rise and fall.

The harness is the enterprise’s codification of its own intent, risk appetite, operating rules, economics and definition of success.

We have to see the model more and more as a replaceable part of intelligence.

The harness should be viewed as enterprise architecture.

Boardroom Query

Are we investing mainly in intelligence that we rent or in building the control architecture that allows us to safely substitute models, increase autonomy, prove outcomes and maintain control of how AI runs our enterprise?