Agentic development over the last two years has been about giving models responsibility for increasingly large pieces of work. As fidelity on these longer-horizon tasks improves, startups are productizing the capability into “software factories” where a customer specifies a product and agents build it. As this extends to non-technical work, it looks like AI employees that own a corporate function with limited human oversight.

At the same time, the mantra in AI-native services has been to sell the work. Pricing the outcome instead of the seat or tokens makes the value legible to the customer and allows companies to price against labor budgets rather than software budgets.

But the two trends create a new problem. When a company sells an outcome, technical uncertainty becomes financial risk: the company is underwriting the cost-to-complete like a fixed-price contractor.

The variance in cost grows with the amount and complexity of work the agent takes on. Whoever agrees to an outcome price is effectively short a call option on task complexity: the customer gets the promised outcome for a known price, while the vendor bears the upside in the cost of getting there.

Contractors typically deal with this risk through scoping and structuring.

The easiest answer is to decompose a long-horizon task into shorter ones and price each separately. A six-month software project can become distinct phases: design, migration, testing and deployment. But not every task decomposes cleanly. If an agent is hired to launch and grow a new product over a year, decisions in month 2 change the work required in month 10 and much of the value is only observable at the end.

A second answer is hybrid contracts: minimum commitments and deposits, with overages, re-quotes and change orders when work falls outside the expected scope. This protects margin, but gives up some of what makes selling an outcome attractive. The customer still has to think about the machinery underneath the work.

The customer’s real objection is usually a variable bill, not a variable quote. A variable bill changes after work begins, while a variable quote reflects what the vendor knows beforehand, then becomes firm when accepted.

I think this hints at the answer for agent companies: build an underwriting model. Before accepting a job, a planning system could inspect the task, compare it against prior projects, and estimate a distribution of cost-to-complete. The firm quote would reflect both expected cost and the risk in the tail.

Uber is an interesting analog. Uber first launched guaranteed prices with uberPOOL in 2014. Riders entered a fixed destination so Uber could match them with others on their route, but the quoted fare held even if no match appeared. By constraining the trip, Uber could bear the remaining matching risk.

As Uber learned from uberPOOL, it began introducing upfront prices for regular uberX rides in April 2016. The quote incorporated expected time and distance, local traffic, tolls and live rider and driver supply. Uber explained at the time that it was “able to use past data to estimate the likely cost of the trip.” The quote still varied by trip, but what disappeared was the variable bill.

The guarantee had a boundary. If the rider made a significant change to the trip, Uber could fall back on time-and-distance pricing. The firm quote only applied to the trip that Uber had inspected at the outset.

Behind the quote, Uber separated the rider price from driver pay. Its service fee (the difference between the two) varied by trip. Uber explains that “Uber’s service fee varies to make upfront pricing work.” Losses on some rides could be offset by gains on others as only the aggregate needed to be profitable.

Better prediction reduced the risk premium Uber needed to embed in each quote. But prediction was only part of the system. Uber had a well-specified job, a large reference class of comparable work, clear rules for when the scope had changed and enough volume to absorb individual errors.

Agent companies will need to recreate the same conditions. A planning system needs structured information about the task before it can quote it. The company needs objective acceptance criteria so both sides know when the work is complete. It needs explicit triggers for a re-quote when the customer changes the job or fails to provide a required input. And it needs limits on how much correlated risk it is willing to hold if many projects depend on the same model or tool.

The harder part is that long-horizon work is much less standardized than a ride. The open frontier is underwriting larger, interdependent projects where neither the work nor the outcome fits into a clean unit.

Every completed project creates a new observation about what a certain kind of work actually costs. Unlike a human contractor, an agent company can observe every plan, retry, and failure, then use that execution trace to improve both delivery and the next quote. Better quotes should win more work, and more work should produce better cost data.

Over time, that creates a compounding advantage that a new entrant can’t recreate by just using the same underlying model. If applications increasingly sell work instead of software, the moat is not just the effectiveness of their agent. It is the accumulated ability to decide which work to accept, what to promise and how to price the risk of delivering it.