This is the last post in this series, so let me skip the setup. Nine posts is a lot of argument about where enterprise software is headed: buying, deployment, harnesses, distribution, product, UX, and roles. If you lead a team and you believe even half of it, here is the list I would actually run, starting Monday.
Pick your intelligence procurement posture
First step: get finance and security in a room this week and answer one question, not per project, but once, for good, per data class. Which data can go out to a frontier API, which has to stay in your own cloud, and which never leaves on-prem.
Most organizations still make this call project by project, which means every new initiative reopens the same argument. That is slow, and it teaches the org that AI work always needs a special process, which kills adoption before it starts. Treat intelligence spend the way you already treat cloud spend: a posture decided once per data class, that any team can build against without asking permission again.
What good looks like in 30 days: a one-page policy, a small number of data classes, a deployment answer next to each one, and a name on it. Not a committee charter. A page people actually use.
Stand up one harness with evals
First step: pick one real workflow that is currently painful, not a demo and not an innovation-lab project, something a team is accountable for today. Wire a harness around it, and before you touch a model, write down what "good" means well enough to test for it.
The reason most pilots break when a vendor swaps the model underneath them is that nobody wrote down what good output looked like. With evals in place from day one, a new model is a configuration change you can verify. Without them, it is a re-litigation with whoever owns the budget. Building the harness first, on one workflow, is how you stop taking every new model release on faith.
What good looks like in 30 days: one workflow running against a real eval set, and you can swap the model underneath it and watch the score move before anyone downstream notices a difference.
Bring one piece of work to where people already are
First step: find the report or status update that everyone in your org complains about, the one that is stale by the time someone reads it or that somebody assembles by hand every week. Make it arrive already built, inside the tool people already have open, instead of asking them to come open yours.
The instinct is to build a new destination: a dashboard, a portal, something with its own login. That instinct is backward now. Work should travel to wherever people already spend their day, whether that is email, chat, or a shared doc, not wait for them to visit it. The report nobody wants to compile by hand is the best place to start, because the win is visible immediately, and it is a chore people are glad to give up.
What good looks like in 30 days: that one report shows up on its own, on schedule, in the place people already look, and somebody asks you to do the same thing for a second report.
Re-score your roadmap for agent surface
First step: go through your roadmap line by line and ask, for each item, could an agent consume this today with no person driving it. Write down the honest percentage. Then write down the number you want two quarters from now, and what has to change in the product to close that gap.
This number is uncomfortable to calculate the first time, because most roadmaps were built assuming a person clicking through a screen. An agent wants a different kind of surface, built for programmatic use, not a UI, and most products were not built that way. That gap, between what exists and what an agent needs, is the roadmap now, whether it is written down or not.
What good looks like in 30 days: a real percentage, a target for two quarters out, and at least one roadmap item that got re-scoped because of the distance between them.
Put one designer on the checkpoint
First step: name the exact moment in your product where a person reviews what an agent produced, and put a designer on that one moment this week, not on the screens around it.
Everyone is redesigning the parts of the product that are disappearing: the forms, the flows, the screens an agent now runs end to end. The part that is not disappearing is the review moment, where someone decides whether to trust what came back. Get that moment wrong and trust erodes fast, every bad handoff makes the next review slower and more suspicious. Get it right and trust compounds, people start approving in seconds because the system has earned it.
What good looks like in 30 days: that checkpoint has been redesigned on purpose, not inherited from the old flow, and you can point to a real change in how fast or how confidently people approve what comes through it.
Treat adoption as a product problem, not a license purchase
First step: stop measuring the rollout by seats provisioned. Pick one team, instrument one honest before-and-after number on real work, and manage that number instead of the login count.
This is the whole argument, compressed. Buying licenses is not a program, it produces a graph of logins going up while the actual work stays exactly the same. Treating adoption like a product means you have a target user, a workflow you are trying to change, and a number you watch to know whether it changed. That is the discipline behind the rollout I have referenced throughout, zero to 500+ active users inside a 3,000+ person organization, and I wrote it up as a product-agnostic playbook at hagestedt.com/playbook.html. Three phases: prove it on one team with a number you would defend in front of a CFO, expand along the pull instead of pushing a mandate, then operationalize it so the program survives a quarter where you do nothing to push it. It is public because the point was never to keep the method, the point was to prove it works and let anyone run it.
What good looks like in 30 days: one team with a defensible before-and-after number, and a second team asking to join without you recruiting them.
The nine posts, compressed
Software stopped being a destination and started arriving inside the tools people already use. That moved the durable asset from the model to the harness around it, and changed how you buy intelligence, where you deploy it, what you build, and who reviews what comes back. None of it works without someone owning the moment a human checks the agent's output, because that is where trust is either earned or lost.
This is post 9 of 9, the last one, in my Thoughtful interfaces series. The rest of it, and the playbook this post keeps pointing back to, lives at hagestedt.com/writing.