To deliver HFS Services-as-Software, services companies must leap from managing people, to engineering production economics. To do so demands a new ‘harness’ as a commercial layer to measure what machine labor actually does and ties that activity to a verified business result – in line with what AWS is proposing in a three-part mechanism for outcome-based pricing that enterprises can rely on.
AWS posits its Bedrock AgentCore provides the managed harness that runs the agent while its observability layer records what the agent actually does. AWS argues those traces can be mapped to measurable business outcomes, with AWS Marketplace providing the commercial layer through which suppliers can charge for successful outcomes rather than simply seats or tokens.
Instrument machine labor, agree definitions of success, verify outcomes – to forge the billable unit
Whether AWS gets to be the harness or not, their experiments (linked above) highlight the benefits of being able to instrument machine labor, agree a standard definition of success, verify that the outcome occurred, then make that the billable unit. AWS is suggesting standardised outcome metrics to simplify procurement across providers for such outcomes as a successful hire, tickets resolved, productivity improvement, etc.
Tokens remain an internal cost that providers optimise, while customers increasingly buy the result. Such a harness can become the meter between AI consumption and value delivered – and the unlock that shifts services from selling inputs to selling results – a requirement sought by 76 per cent of enterprise leaders but contracted by as few as 5% ( CX Leaders Want Outcome Pricing)
FTE has dominated because variables in human work make outcome pricing risky
HFS has long called for outcome pricing because FTE pricing is fundamentally an input model: you buy 100 people, you pay for 100 people. The problem with human labour is that providers could not take on the risk of being fully accountable for the outcome. Human work is variable, difficult to instrument, hard to attribute accurately, and full of exceptions. So “outcome-based” contracts usually end up as FTE pricing plus some gainshare and SLAs.
With the rise of AI, the key change is not just that it can be cheaper than humans, it is that machine work is observable, measurable, repeatable, and therefore economically controllable, in ways human work isn’t.
Consider a claims process. With a human team, you know roughly how many people worked on it, their salaries and broadly how many claims they processed. But precisely attributing cost to each successful outcome is messy. One person helped another. Someone spent half an hour thinking. Someone else dealt with an exception. And quality varies between employees and across days.
With machine labor, the production process can potentially be traced across tasks received, context retrieved, model used, tools called, decisions made, verification performed, outcome accepted (or rejected), through to any escalations due to exceptions. You can associate actual consumption with each event. So a provider can calculate what the average cost of a verified successful outcome is. Services-as-Software becomes an economic model procurement teams and vendor business planning teams can rely on.
Apply a commercial harness to make machine labor an auditable unit of production
We would no longer need to price on the inputs – of either FTEs or tokens. Instead the harness acknowledges that the model produces tokens, the agent performs the tasks, the harness observes and controls the work, the business process produces the outcome. This allows the supplier to manage the production risk against known knowns. Machine labor becomes an auditable unit of production; something you can sign a contract for.
Services-as-Software enables the enterprise to contract for a number of completed outcomes. How the services provider ‘manufactures’ them is down to them. With FTE pricing, productivity improvement can be bad for the supplier’s business. If automation eliminates 30% of the required employees, they could be eliminating 30% of their own revenue.
With outcome pricing, the incentive reverses: Every improvement in productivity potentially increases the service providers gross margin. Learning fast to improve the system is incentivized. This is literally software economics inside a services contract.
Token costs and optimisation should be left to your service provider to manage
If your shift is simply from paying for FTEs to paying for tokens you have simply replaced one input-pricing mechanism with another. The token is useful to service providers in the same way that electricity, compute cycles, employee hours and API calls are useful. They are important to understand because they determine their costs.
But enterprise customers don’t want to buy them. Banks, for example want to buy outcomes such as accounts reconciled, fraud detected, customers onboarded, mortgages processed, or service enquiries resolved.
The Bottom Line: As Services-as-Software becomes economically possible, apply a harness to make it commercially contractable
HFS has argued for outcome-based pricing for a long time. What prevented it has not been a lack of imagination in procurement. The production system wasn’t sufficiently measurable. Human labour made outcomes difficult to isolate, costs difficult to attribute and performance difficult to standardise.
Machine labour makes Services-as-Software economically possible; the harness makes it commercially contractable and shifts services companies from managing people to engineering the economics of production.
For enterprise leaders that means the industry is edging closer to providing what you have been clamouring for – a cost per outcome contract that incentivizes continuous improvement.
