An AI services engagement has a cost structure, and that structure is changing because one of its inputs is collapsing in price while the others are not. When you write down what it actually costs to take a business process from manual to automated, the line items sort into two groups: the ones whose price tracks model inference and code generation, and the ones whose price tracks human time and the difficulty of getting access to a customer's systems. The first group is heading toward zero. The second is holding steady. The firms that will keep their margin are the ones that recognize which group is which and spend their engineering effort on the part that stays expensive.
The line item that is collapsing
Start with the input that is genuinely getting cheaper. Stanford's HAI AI Index Report 2025 documents that the cost of inference for a model performing at a given capability level fell by roughly 280-fold over about eighteen months. That figure is the price to run a model that clears a fixed quality bar, not the price of the frontier, and it is the number that matters for a services firm, because a services firm does not need the frontier on most tasks. It needs a model that can read a process description, propose a redesign, write the integration code, and draft the agent logic. The cost of doing all of that, per unit of work, has dropped by more than two orders of magnitude.
Code generation sits inside this same collapsing term. Writing the connector to a customer's ERP, the parser for their invoice format, and the orchestration that moves a record from one system to the next is work an engineer used to bill hours against, and it is now the cheap part. A model produces a first draft of that code in seconds, and the marginal cost of the second draft, of the third, and of the variant for the next customer is close to the inference price, which is close to nothing. The two inputs an AI services pitch tends to lead with, the capability of the model and the speed of writing code, are precisely the inputs whose unit price is falling fastest.
What stays expensive: getting in
Now the inputs that do not move with inference. The first is context acquisition, the cost of getting into the customer's systems, earning the access required to read their data, and surfacing how the work is actually done rather than how the documentation claims it is done. None of this responds to a cheaper model. Earning access to a payroll system or a billing platform is a function of trust, security review, and the customer's own change-control process, and those proceed at human speed regardless of how cheap inference becomes. The cost of discovering how a process actually runs is dominated by observation and clarification with the people who do the work, because documented processes describe an intended state that the real work has drifted away from.
The reason this term resists the inference collapse is that its cost is set by the customer's environment, not by the model. Every system has its own authentication, its own data model, and its own exceptions that nobody wrote down. A cheaper model does not reduce the number of conversations required to learn that the finance team routes a particular vendor's invoices through a side process every quarter-end. Context lives in people, in undocumented exceptions, and in access that has to be granted, and a model cannot grant itself that access or interview anyone.
What stays expensive: the last mile
The second input that resists the collapse is the reliability tail, the human judgment required to resolve the cases the agent cannot resolve on its own. An automated process does not run at a single accuracy figure. It runs well on the common cases and fails on the long tail of exceptions, and each failure either gets escalated to a person or produces a wrong output that someone has to catch and fix later. The cost of that tail is governed by an expression worth stating literally: the exception rate, multiplied by the cost to resolve one exception, divided by how far one person's judgment carries across cases. We have walked this term in detail in the unit economics of the exception tail, and the point here is that none of its three factors is an inference cost. The exception rate is a property of the process and its inputs. The cost to resolve one exception is human time. The reach of a person's judgment is a tooling question, set by how well the agent presents the exception and how cleanly the human's decision feeds back.
What makes the last mile the dominant term is that it does not shrink when the code improves. A better model lifts the share of cases handled automatically, which lowers the exception rate, but the exceptions that remain are the hardest ones, and they are the ones that need a person. As the automated share rises, the residual cost concentrates almost entirely in that tail, so the engagement's economics come to be decided by how efficiently the firm handles exceptions rather than by how good its code is on the easy cases.
Why context acquisition becomes the dominant term
Put the two groups together and the cost anatomy of an engagement inverts. The line items priced against inference and code generation fall by orders of magnitude. The line items priced against access, observation, and human judgment fall hardly at all. The arithmetic does the rest: when one set of terms goes to near-zero and another holds steady, the steady terms become essentially the whole cost. An engagement once dominated by engineering hours becomes dominated by the cost of getting in and the cost of the tail.
This is why code speed is the wrong thing to optimize. Code speed was scarce when an engineer had to hand-write every connector, and it is no longer scarce, so a firm that competes by writing code faster is competing on the input whose price is heading to zero for everyone. The scarce input is the cost of acquiring context, and a firm reduces that cost the way software firms reduce any cost, with tooling and reuse. A capture agent that observes the work directly lowers the human-interview burden. A library of connectors and exception patterns built on prior customers means the next engagement starts with much of its context already structured. This is the mechanism behind the context flywheel: each engagement lowers the context-acquisition cost of the next, which is the property that lets a services-as-software firm bend its scaling curve away from headcount.
The counter-thesis, and why context still wins
A reasonable objection is that context acquisition is partly automating too, so it will follow code into the cheap column. Capture tooling does read systems directly, and models are getting better at parsing the artifacts a business produces, so the expectation that this term holds its price needs defending. There is something to the objection. The cost of observing a process is falling as capture tooling improves, and a firm that does not invest there will see this term stay high while competitors drive it down.
The objection misses where the residual cost sits. The part of context acquisition that automates is the reading, the parsing of documents and the logging of clicks. The part that does not automate is the access and the trust: the security review before a customer connects a system, the relationship that makes someone willing to grant credentials to a payroll database, and the judgment to know which undocumented exception matters. Those are properties of the customer relationship, and a cheaper model does not produce them. The same logic applies to the tail, where the hardest exceptions are the ones that demand a person and that no model reliably clears. So the cost migrates rather than evaporating, it migrates toward access and judgment, and a firm that builds tooling to drive down the readable part of context while owning the access and the tail is positioned where the cost actually concentrates rather than where it used to.