The pod that shipped the feature last quarter was two people and a stack of agents. The same feature, eighteen months ago, took six. The work landed. The client was happy. Then someone had to price the next one, opened the estimating sheet, and started typing person-days into a day-rate formula that assumed six people were still in the room.
That moment is where pricing agent-assisted delivery quietly goes wrong. Not in the delivery. In the estimate, which is still counting bodies for a job that no longer needs them.
Mphasis is the cleanest public version of this. It reports delivering the same scope with fewer people, citing moves like a hundred-person team down to sixty. Whatever your read on how fast that spreads, the mechanic is real on at least some engagements now: a small human team plus a set of agents does the scope a larger team used to. The work has not got cheaper to value. It has got cheaper to staff. Those are different things, and a day-rate estimate cannot tell them apart.
Why headcount stops being a clean proxy for cost
Estimating in hours was never really about hours. Hours were a stand-in for cost. A senior engineer at a day rate, times the days you think the work takes, gives you a cost base you can put margin on. It held up for decades because headcount tracked cost cleanly. More work, more bodies, more hours, more cost. The proxy was good enough that nobody questioned it.
Agent-plus-human pod delivery breaks the proxy in a specific way. The cost of an agent doing part of the work does not move with headcount, and it is not zero. There is a model bill, a platform subscription, the tooling the agent runs inside, the human time spent supervising and correcting it. That cost is real, but it does not show up anywhere in a person-day estimate, because the person-day estimate only knows how to count people.
So you get two failure modes, and they pull in opposite directions.
Estimate the agent-leveraged work in person-hours at a full day rate, and you overprice it. You quote six people for a job two people and a set of agents will do, the buyer gets a cheaper number from a firm that has done the same maths more honestly, and you lose the deal you should have won.
Estimate the irreducibly human work the same way and you underprice it. The discovery, the architecture, the stakeholder wrangling, the judgement calls an agent cannot make. That work did not get cheaper. If your blended day rate has quietly absorbed an efficiency assumption from the leveraged work, you are now pricing the hard human work below its real cost, and bleeding margin on exactly the part that justifies the engagement.
Both errors live in the same estimate. Both are invisible, because the one number on the line cannot show you which kind of work it is describing.
You do not abandon estimation, you change what a resource is
The instinct, when the proxy breaks, is to reach for something exotic. A new unit of work. An outcome metric. A per-resolution price. Those are real conversations, but they are not the fix for the estimate, and most firms reach for them before they have done the simpler thing.
The simpler thing: keep your estimating machinery, and change what counts as a resource.
Your rate card, your roles, your resource mix all still work. The only assumption that has to go is that a resource is a person. An agent is also a resource. It does part of the delivery, it carries a cost, and it belongs on the estimate as a line with its own loaded rate, sitting in the same mix as the people. Once you model it that way, the human hours on the estimate fall to what the humans actually do, the agent line carries its own cost, and the work still has a defensible cost base you can price against.
Nothing about this is speculative tooling. A loaded rate already bundles things that are not a single person's salary. It carries benefits, on-costs, bench, the tooling that person works inside. The agent stack a role runs on is now one more thing in that bundle. You can fold it into the human role's load, or you can give the agent its own line. Either way the cost base stays explicit instead of hiding inside a day rate that no longer means what it used to.
Two ways to carry the agent cost when pricing agent-assisted delivery
There are two practical shapes, and the right one depends on how separable the agent work is.
Fold it into the loaded rate. When the agent is an amplifier on a specific role, the cleanest move is to load its cost into that role. A senior engineer who now runs a coding agent has a higher loaded cost per day than one who does not, because the agent's share of the bill rides with them. The role's effective output per day is also higher, so you estimate fewer of those days. Net effect: fewer human-days on the line, each day costing slightly more, the cost base intact, the margin honest.
Give the agent its own line. When the agent does a chunk of work you can name and separate, model it as its own resource with its own loaded rate. A document-extraction agent, a test-generation agent, a first-pass code agent. Now the estimate shows two lines where it used to show one: the human days, and the agent line carrying its own cost. The leverage stops being buried in an assumption. It is on the page, where finance can see it, the buyer can see the shape of it, and you can defend the price line by line.
A worked version, in round numbers. A feature that used to take a four-person team at a 1,000 a day blended rate over fifteen days cost you 60,000 in effort. The agent-assisted version is two people for ten days plus an agent line. Two people at, say, a 1,100 loaded day rate over ten days is 22,000. The agent line, model spend plus its share of tooling and supervision overhead, runs 4,000 across the work. Cost base: 26,000, not 60,000. The number is lower because the staffing is lighter, not because you discounted. And every part of it is legible: you can see exactly where the 34,000 of leverage came from, instead of pretending the work still takes four people or quietly pocketing the difference until a competitor prices it out from under you.
Hold price separately from effort
The second move is the one that makes the cost base useful rather than just accurate.
Price and effort are different dimensions, and the agent shift forces them apart. Effort is going down. Price, if you sell on outcomes or value, does not have to follow it down at the same rate, because the buyer is paying for the result, not for the bodies. The whole point of a clean cost base is that you can sit a price on top of it that is governed separately, with a margin you can actually see.
This is where the auto-discount trap catches firms that skip the step. If your price is mechanically effort times rate, every efficiency gain becomes a discount you hand the buyer for free. Two people did the work, so you bill for two people, and you have just given away the entire value of the leverage. Holding price separate from effort is what lets you keep some of that value instead of competing it all away. The cost base tells you the floor. The price is a separate decision sitting on top of it.
This is also the boundary of what this guide covers. Once price and effort separate, you are into outcome pricing, shared-risk terms, and the delivery risk that transfers onto you when you sell a result instead of a quantity of time. That is its own subject, worked through in the unit of account piece, which makes the broader case that the hour is load-bearing across the whole business, not just the invoice. The narrow claim here is smaller and more practical: get the cost unit right first, because you cannot price an outcome with a known margin on top of a cost base you cannot see.
The estimate that shows where the leverage sits
The payoff of modelling the agent as a resource line is not a more accurate single number. It is a more legible estimate.
When the agent is a line, the estimate stops hiding the leverage and starts showing it. You can read, per feature or per phase, how much of the work is human judgement and how much is agent-assisted throughput. That tells you where your margin actually comes from, which deals are leveraged and which are not, and where your pricing is exposed if the agent's share of the work turns out to be flakier than you assumed. A blended day rate collapses all of that into one number and tells you none of it.
It also makes the next estimate better. When the leverage is explicit on the deals you have already shipped, you have a record of how much agents actually displaced, not a guess. The firm that buried the agent inside a day rate has no such record. It just has a margin number that drifted and no way to explain why.
None of this needs a new tool
Estii's existing primitives carry this without anything new. Roles already hold a loaded cost that bundles salary, benefits, and on-costs with the margin added on top, so loading an agent's share into a role's cost is the mechanic the tool already runs on. To give the agent its own line, a stream models a loaded resource as a primary role plus partial allocations of supporting resources, which is exactly the shape of a human role carrying an allocation of an agent, blended into one rate that the schedule and the cost base both read from. Rate cards govern cost, price, and margin with low, normal, and high bands per role, so an AI-loaded line is held to the same margin discipline as a person, and a deal priced below the floor flags itself. And because scope breakdowns group estimates by role, role tag, or stream, the estimate can show the human-versus-agent split per feature instead of burying it in a blended day rate. The cost stays explicit, the price stays governed separately, and the leverage shows up on the page.
The estimate was never really counting hours. It was counting cost, and using bodies as the proxy because bodies were close enough. They are not close enough anymore. The firms that come through this will be the ones whose estimate can still tell them what the work costs when half of it is no longer done by a person.
