Author
TL;DR The inner harness runs the model; the outer harness defines tasks, customers, and completion. Whichever layer you expose to customers sets your value metric, so the boundary between them is a pricing decision, not just an engineering one. Three structural pricing models follow from where you draw it, and pricing power lives at the outer layer.
- What “Inner” and “Outer” Actually Mean in an Agent Architecture
- Why the Inner Harness Is Commoditizing — and Why That’s a Pricing Signal
- Inner and Outer Agent Harness Pricing — Three Structural Models
- The Pricing Decision the Outer Harness Forces
- What a Six-Figure API Bill Actually Tells You
- Practical Checklist: Auditing Your Harness Pricing Boundary
- FAQs
This article is about agent harness architecture in AI systems, not about Harness.io, the DevOps CI/CD vendor. The two share a name and nothing else.
Inner and outer agent harness pricing is an architectural question that most software companies are answering by accident. They choose a value metric, ship it, and discover later that the metric was determined by which layer of their agent system they exposed to customers, not by any deliberate pricing strategy. This article makes that decision explicit so you can make it on purpose.
What “Inner” and “Outer” Actually Mean in an Agent Architecture
If you need a full grounding in what an agent harness is, start here. What follows establishes the inner/outer split and its pricing implications.
The inner harness: what it controls (and what it doesn’t)
The inner harness is the execution loop. It drives LLM invocation, dispatches tools, manages the context window, and runs the agent inside a sandboxed environment. It decides how a task runs. It does not decide what task runs, who requested it, or what counts as done.
The inner harness has no concept of a customer or a contract. It processes tokens and returns outputs.
The outer harness: where business logic actually lives
The outer harness is the orchestration layer. It defines tasks, routes outputs from one agent run to the next, manages state across sessions, and connects the agent system to customer workflows. It decides what is done, for whom, and when to stop.
Business logic, customer context, and the definition of a completed unit of work all live here.
Why the boundary between them matters for pricing
The boundary between inner and outer is where your value metric is implicitly set. If you expose the inner harness directly to customers, they see token consumption. If you expose the outer harness, the metric is yours to choose: tasks, workflows, seats, records processed, or any member of the outcome family, priced as flexibly as the value delivered warrants.
That is worth saying plainly, because the outer harness is not a new thing to price. What the outer layer does, define the task, hold the customer context, decide what done means, is the application layer. Pricing it is monetizing an application, the problem software companies have been solving for decades, not a net new concept that needs a net new paradigm.
That boundary is a pricing decision. Most teams treat it as an engineering decision and inherit a pricing model they did not choose.
Why the Inner Harness Is Commoditizing — and Why That’s a Pricing Signal
When pass-through pricing at the inner layer signals a commoditized position
Across practitioner communities building on Claude Code, Codex, and open-source agent runtimes, a pattern is emerging: the inner harness is converging. The invocation loop, tool dispatch, and context management that once differentiated agent platforms are now table stakes, and open-source alternatives keep closing what gap remains.
When your inner harness commoditizes, pricing at that layer means pricing against a cost floor your customers can increasingly see and benchmark. The pattern across our library is consistent on this point: vendors who price at differentiated layers above commoditizing infrastructure hold their margins, and vendors who pass commodity costs through do not. The inner harness is becoming infrastructure, and infrastructure pricing is weak pricing only without the volume. Tight margins at enormous volume make a great deal of money. Most application vendors will never have that volume.
Pass-through pricing means your invoice unit is your supplier’s unit, unrecasted. When the inner harness is the supplier’s unit, and that unit is commoditizing, you are one OpenAI price change away from a customer anchoring to your cost floor.
What the outer harness controls that the inner harness never will
The outer harness controls task definition, completion criteria, workflow routing, and customer-specific state. None of those are available to the inner harness. None of them will commoditize on the same timeline as LLM invocation, because they require domain knowledge, integration work, and product decisions that are specific to your customer’s context.
That is where your pricing power lives. The outer harness is the layer that knows what “done” means for a specific customer. The inner harness does not.
The outer harness’s real job is to absorb the inner harness’s failures
The inner harness fails in ordinary ways: a run loops, a retry compounds, a model returns a confident answer that is wrong. Where those failures land is a pricing decision. Priced at the inner layer, every one of them is billed, because tokens were consumed. Priced at the outer layer, the vendor absorbs them, because the unit is the completed task and a failed run did not complete one.
That absorption is the outer harness’s real value, and it is where trust is built. No one wants to pay for the vendor’s failures. A courier does not invoice you for the parcel it lost, and a bank does not charge a fee on the transfer that bounced. The only business that bills for its own failed attempts is one that does not expect a second order. A billed failed loop is the vendor taking more than its share of the value it delivered, which is the opposite direction from everything a value metric is meant to do. Vendors that engineer the failures out get both the accuracy and the customer who stays.
The commoditization test: can your customer swap your inner harness without noticing?
Ask it directly: if you replaced your inner harness runtime with a cheaper open-source alternative tomorrow, would your customer’s outcome change? If the answer is no, the inner harness is not your differentiator. Pricing it as if it were costs you margin and, over time, credibility.
Where Does Your Pricing Architecture Actually Stand?
A few questions return your pricing architecture score and show which of your licensing, packaging, and pricing decisions needs attention first. Real diagnosis, not a mailing-list toll.
Inner and Outer Agent Harness Pricing — Three Structural Models
The three models below map to where a vendor draws the pricing boundary relative to the inner/outer split. For context on how these map to the broader AI pricing spectrum, see the AI Pricing Spectrum article. For the broader SaaS pricing history these models extend, see SaaS pricing models.
Model 1: Pricing at the inner harness (infrastructure pricing)
The vendor exposes token or credit consumption directly. The customer sees invocations, tokens, or credits on their invoice. The customer absorbs all variance when a model runs long, retries, or returns a degraded result.
GitHub Copilot’s AI Credits move is the clearest current example. The inner harness cost becomes the customer’s problem.
This model is appropriate when the outer harness is customer-built and the vendor has no visibility into what constitutes a completed task. When the vendor does have that visibility and still prices at the inner layer, they are leaving margin on the table and exposing themselves to the commoditization dynamic described above.
What we observe in B2B software negotiations is consistent: when buyers can see the underlying infrastructure cost, they anchor to it. Infrastructure-layer pricing hands the customer that anchor.
Model 2: Pricing at the outer harness (orchestration pricing)
The vendor prices on a unit the outer harness controls: tasks completed, workflows triggered, decisions made. Inner harness costs are absorbed internally. The customer’s invoice does not move when token prices shift.
This is the structural move that enables margin control. The vendor takes on cost management as a product responsibility and returns a predictable, outcome-adjacent unit to the customer. The value metric is decoupled from LLM cost variance.
This model requires a well-defined outer harness. If the vendor cannot certify task completion, they cannot invoice on task completion. The architecture precedes the pricing decision.
Model 3: Split-layer pricing across both harnesses
A base fee covers outer harness access (a seat or platform fee), and a consumption meter runs at the inner layer for overage. Salesforce Agentforce operates this way across its enterprise deployments.
The base fee creates a predictability floor. The consumption meter captures upside when usage runs high. The tradeoff is communication complexity: customers need to understand two meters, and sales needs to explain both.
This model is most common in enterprise contexts where procurement teams demand a predictable line item and finance teams want a usage-based ceiling.
Which model fits which stage of product maturity?
Early-stage products often default to Model 1 because tokens are what the inner harness already counts, not because tokens are the right unit. That default is a cost input dressed as a metric, and it is a poor fit for the application layer at any stage. Even before the outer harness can certify a task, there is almost always a unit the customer recognises as value: a document processed, a conversation handled, a seat, a workflow run. Choose that, even roughly, over the supplier’s unit.
The signal to move to Model 2 is when the outer harness stabilizes enough to define a repeatable task unit. Until then the choice is between a value-aligned proxy and a cost input, and the proxy wins. Pricing at the inner layer was always a choice, never a constraint.
The Pricing Decision the Outer Harness Forces
What makes an outer harness priceable in practice
A priceable outer harness has three properties. First, it defines a discrete task boundary: there is a clear start state and a clear completion state. Second, it can verify completion independently of the customer’s confirmation. Third, it produces a log the vendor can audit.
Without those three properties, you cannot price on task completion. You can only price on consumption, which pushes you back toward Model 1.
Across decades of patterns in our library, one thing is clear: alignment between the invoiced metric and the unit the customer perceives value in is the strongest predictor of willingness to pay. The outer harness is the layer that makes that alignment possible. If it cannot define a verifiable value unit, pricing cannot move up the spectrum toward outcome-based pricing.
Why pricing teams should have a seat at the harness architecture meeting
Engineering teams designing the outer harness are making pricing decisions. They decide what a “task” is. They decide what counts as completed. They decide what state is tracked across sessions.
Those decisions determine which value metrics are available to the business. A task boundary that is ambiguous in the architecture will be ambiguous on the invoice. Pricing teams that sit outside that conversation inherit a pricing model they cannot change without an engineering rewrite.
Pricing fluency at the architecture stage is not a nice-to-have. It decides whether the pricing model fits the product or was never designed at all.
What a Six-Figure API Bill Actually Tells You
How inner harness cost explosions happen
Enterprise AI deployments have produced a recognizable failure pattern: a monthly API bill arrives at a scale no one budgeted for. The root cause is almost always the same. The outer harness had no defined task boundary, so the inner harness ran without a natural stopping condition. Retry loops compounded. Parallel agent runs multiplied. An optimization routine ran against a hundred times the dataset it was sized for. No one had defined what “done” meant, so the system never stopped trying.
This is not a cost management failure. It is an architecture failure that manifests as a cost failure. The outer harness did not exist in a form that could constrain the inner harness.
The outer harness controls that prevent them
A well-defined outer harness prevents runaway inner harness costs through task-level budgets, completion criteria that halt execution, and audit logs that surface anomalous runs before they compound.
When those controls exist, a cost explosion is an alertable event, not a billing surprise.
For questions about who absorbs cost when an agent run fails or returns an unusable result, that liability question is handled separately; this piece stays on the architectural controls that make those events rarer.
Practical Checklist: Auditing Your Harness Pricing Boundary
Five questions to determine whether your pricing boundary is at the right layer.
- Can your customer observe and verify the unit you charge against? If they cannot, you are charging against an abstraction they will eventually distrust.
- Is your pricing unit controlled by the inner harness, the outer harness, or your customer’s behavior? Each answer maps to a different model. Know which one you are in.
- If your LLM provider changes its token pricing tomorrow, does your customer’s invoice change automatically? If yes, you are in Model 1 whether you intended to be or not.
- What is the smallest complete unit of value your outer harness can certify as delivered? If you cannot answer this, you cannot move to Model 2.
- Do your engineers and your pricing team agree on what a “task” is? Disagreement here is the single most common root cause of a pricing model that does not survive its first enterprise renewal.
If questions 3, 4, or 5 surface a gap, the Pricing Architecture Assessment maps the boundary and identifies which model your current architecture supports. If the gap is organizational rather than informational, with engineering and pricing each holding half of the answer, talk to a pricing expert before the next renewal cycle settles the question for you.
