For years the build order was the same everywhere I worked. Design the screens, get sign off from whoever has to look at them, bolt an API onto the back once the UI is locked, and ship it.
That order made sense when the only thing calling your product was a person holding a mouse. It stops making sense the moment a real share of what calls into your product is an agent, because an agent does not care what your screen looks like, it cares what the capability does, whether the contract is documented, and whether it can trust that contract to hold.
So I flipped the build order, on my own teams, for good.
Capability and contract first, screens after
The rule now is simple. Capability and its contract come first, surfaces come after, and the human UI is just one more consumer of the SDK, the same as any agent or any other client calling the same endpoints.
This does not give anyone permission to skip design, it just moves design downstream of a stable, documented capability instead of upstream of it. You cannot bolt a contract onto a UI after the fact and expect an agent to integrate against it cleanly. The contract has to exist before anything gets built on top of it, screens included.
The reference doc is the product
On my teams the SDK layer and its reference document ship before any UI work starts, no exceptions. That document has to cover every public method, the auth model, the configuration, and a worked example for every major operation, plus what happens when a call fails and why it failed.
Written well, that one document is enough for a developer, or an agent, to integrate without ever talking to the person who built it.
That is the part that actually changed for me. I used to write docs so a new hire could ramp faster. Now I write them because an agent is going to read that file directly and act on whatever it says, with nobody in the loop to ask a clarifying question first. The doc stopped being a courtesy and became the interface itself, for a category of user that reads markdown instead of clicking buttons.
Acceptance criteria become evals
The definition of done changes right behind the build order. It used to mean the screen worked and a human clicked through it during a demo. Now it means the capability passes its eval suite, whoever or whatever is calling it.
An eval suite is a PRD written so a machine can grade it. Feed it a known input and the output either matches the right answer or it does not. Run it a thousand times and see whether it holds up, a single clean demo in a conference room never tells you that. Break it on purpose and check that it fails the way it is supposed to, instead of some other way nobody planned for. If your acceptance criteria still live entirely in a screenshot of a working screen, you have acceptance criteria for the part of your user base that still uses a mouse, and nothing for the part that does not.
What 1.5 weeks looks like from the inside
Here is what capability first buys you in practice. I replaced a roughly $1M a year third-party annotation platform in 1.5 weeks, decision to production, with zero downtime on the projects already running against the old tool.
That timeline only exists if you cut straight to the capability core and skip everything decorative. We started with the contract the existing projects already depended on instead of a new UI, held that contract steady, and built the replacement capability behind it, so the projects sitting on top never had to notice the swap happening underneath them. Once the capability held, the interface came together fast, because the hard decisions were already settled by the contract, there was almost nothing left to invent.
Speed like that falls out of doing the sequencing in the right order and refusing to spend a day on decoration before the core capability has earned it, not out of heroics.
What I would actually do
If you are a PM and nothing on your roadmap has an agent calling it yet, it will soon, and the habit is cheaper to build now than to retrofit later. A few things I would put in place.
1/ Write the tool contract before the wireframe. Define the inputs, outputs, and error states for the capability itself, and let the screens follow from that, not the other way around.
2/ Define your evals as the acceptance criteria, not the screenshot. If you cannot describe what a passing call looks like in a test, you do not know what done means yet.
3/ Treat the agent as a persona with its own jobs to be done. It has no patience for a five-click flow and no ability to infer intent from a poorly worded button, so design for it on its own terms instead of assuming your human flows will translate.
4/ Add an agent-surface line to your roadmap scoring. For every feature, ask what share of it an agent could use today without a human driving it. That number will be low for most of your roadmap right now, track it anyway, because it will not stay low for long.
None of this replaces product judgment, it just moves the judgment to the part of the system that has to hold up regardless of who, or what, is calling it.
This is post 6 of 9 in my Thoughtful interfaces series. The rest lives at hagestedt.com/writing.