Six ways agents rewrote the contract between you and your software
Agents have changed software as we know it. Here is something that was never true before: two users can send the identical message to the same product and get different work done, at different cost, over different durations, with different results. This is not a bug. It is the new contract between the user and the product.
I build with agents every day, and increasingly through them. What I keep noticing is that this isn't one change, it's six separate ones, and most teams still treat them as one thing ("we added AI"). Taken apart:
1. The request–response cycle has entirely changed
A request used to be a straight line. The user clicks, the server computes, the response renders. Every step was designed ahead of time by an engineer who knew exactly what would happen.
A request now involves a series of chained decisions, made at runtime: which model to use, what context to include, what to pull from cache, which tools to call, and when to stop and ask. Each decision trades the quality of the output against the cost the model incurs and the performance — per request, decided by software, not by an engineer at design time.
The engineering implication is that you're no longer building endpoints; you're building a decision policy. The product implication is the one at the top of this essay: software no longer promises to be deterministic.
2. Performance metrics have changed
Performance work used to mean shaving milliseconds off time-to-interactive. An agent task takes seconds, sometimes minutes, and users are fine with it — on one condition: they have to be able to see that real progress is happening.
This is the reason we have quick acknowledgements, eager acknowledgements ("On it — reading your files now"). It's the reason answers stream token by token instead of arriving finished. And it's why the modern equivalent of the loading animation narrates what it's doing, sometimes inventing new words while it works. The narration is what buys the patience.
So the metric has moved: from time-to-interactive to time-to-first-token, and from raw latency to something softer: whether the user trusts that the work is underway. A ninety-second task that narrates itself feels faster than a nine-second task behind a frozen screen.
3. Cost has become a design decision
Cost is immensely important now, and it's in the product's hands. Depending on how you handle the input context, what you cache, and more importantly, whether you choose the right model for each task, the cost incurred in serving one request can vary by 3 to 10x, or even more.
That variance used to be an infrastructure concern — engineers optimised for latency and let finance worry about servers. Now every feature has a per-request cost line, and margin is something you design. Route the summary to a small model and the reasoning to a large one, cache the system prompt, trim the context, and you've changed the unit economics of the product without touching a pixel.
If you're building on top of models, you should be able to say what one request costs you. If you can't, the pricing strategy is a guess.
4. The UI surface has changed
The standard, increasingly, is that most of the work is achieved through a chat UI. And the chat UI has grown a few more elements: a way to add additional context, and a canvas in which the output is displayed. Together these give the user one unified surface — the same place where you ask for the work, scope it, watch it happen, and receive the result.
This changes what interface design even is. The interesting design work has moved from "where do we put the button" to "what does the agent show, ask, and decide."
5. Mastery has become transferable
Traditional products had a different type of mastery curve. The UI/UX changed from product to product, and knowing Photoshop didn't mean knowing 3ds Max. That curve was also the moat — years of accumulated fluency kept professionals loyal.
With the chat UI, the learning transfers. If you know how to use Claude Code well, you likely know how to use Codex well, or you learn it very quickly — because the skill was never the tool. The skill is delegation: specifying what you want, scoping it, checking the result, and knowing when to step in.
That's great for users and uncomfortable for incumbents. UI lock-in is dissolving, and the moat is moving from "they'd have to relearn everything" to "we remember everything about them" — that is, from interface to memory and context.
6. The security model has changed
Traditional software could only do what its endpoints allowed. An agent with tools can do anything its tools allow — read files, call APIs, spend money. So the old questions ("is this endpoint safe?") have been joined by a new one: what is this agent permitted to do on my behalf? Scoping the tools is the new least-privilege.
The inputs have become adversarial too. With prompt injection, the attack doesn't have to come through your network edge: a webpage, an email, a README that the agent reads can carry instructions aimed at the agent itself. The trust boundary has moved from the network edge to the context window, and that is a genuinely new place for it to be.
And the user-facing side of security has changed with it. The confirmation dialog has grown into permission modes, plan modes, and "ask before running": how much trust to extend is now a setting the user chooses. Budget caps are the new rate limits, because an agent spends money, not just compute. The audit log has become a product surface: users read the agent's action history the way admins used to read server logs.
What to do about it
If you're building product in this world:
- Design the wait. Acknowledge the request instantly, stream the output, and narrate progress while the work runs.
- Measure new things. Time-to-first-token, cost per task, and intervention rate, meaning how often the user has to step in.
- Treat cost as a feature. Model routing and caching are product decisions. Put them on the roadmap.
- Assume your users arrive pre-trained. They learned delegation somewhere else. Don't make them learn your dialect of it.
- Scope the tools and cap the spend. Least-privilege applies to agents more than it ever applied to endpoints, and the budget is part of the permission.
The losing move, visible across the industry right now, is bolting a chat box onto an existing product and calling it agentic. That is what happens when these six changes are treated as one.
Each of these is worth talking about more — every section here could be its own piece. But that's for later.
Thank you for reading!
Top comments (0)