Agent-ready is the new mobile-ready

I was using Claude Cowork to research a PE firm ahead of a meeting. Along the way it read that the firm was pushing AI across its portfolio as part of its value creation plan. Nobody had said what that would cost to run, so it added a card to my to-do list to work it out. Then another agent picked it up from the Kanban board, built a rough cost model from public pricing, listed its assumptions in a comment on the back of the card and flagged it for me to review. All this happened without me even thinking about it, let alone having to do anything. But this isn’t a story about what can be done with Cowork. It’s not even about automation. It’s about mobile apps circa 2010.

Mobile was bolted on before it was designed in

Around 2010, most companies treated mobile as a smaller screen for the website they already had. They built a cut-down mobile site, or wrapped their web pages in an app, and moved on. The companies that designed for the phone from the start took the customers. Even Facebook got it wrong: in 2012 Mark Zuckerberg said the company’s biggest mistake had been betting too much on HTML5 instead of building native apps, and by then it had already rebuilt its iPhone app from scratch.

AI agents are the same shift. An agent is software that does work on someone’s behalf: it reads, decides and acts inside other systems. Most work software is now adding agent access to a product designed for people clicking buttons. Atlassian and Linear have both shipped MCP servers, a standard way for an agent to plug into a product, and that’s real progress. But a connector added to a product built for people is like the cut-down mobile site again. What matters is whether the tool treats agents as users in their own right.

The commercial reason is plain. As agents take on more of the routine work, a tool’s value depends on how much of that work an agent can do in it safely. A tool agents can’t use becomes the place where a person still does the job by hand, and that’s where your cost stays. If you sit on a board or back a portfolio, this belongs in technical due diligence alongside security and tech debt.

Five questions that separate the two

1. Can an agent do everything a person can? If an agent can create a ticket but can’t move it, comment on it or close it, it stops halfway and a person finishes the job. Partial access is worse than it sounds, because it leaves work half done by a machine with nobody clearly owning it. Ask the vendor for a list of what an agent can’t do.

2. Can it sign in without borrowing someone’s account? The usual shortcut is to give the agent a person’s login or API key. Every action in the audit log then carries that person’s name, nobody can separate what they did from what the agent did, and when they leave, the agent either breaks or carries on working under a departed employee’s identity. An agent needs its own identity, one that a named person approved.

3. Can you limit what it touches, and for how long? You wouldn’t give a contractor keys to every room in the building with no end date. An agent should reach only the projects or records it needs, read-only where that’s enough, with access that expires. You should be able to see when it last used that access and switch it off in one click.

4. Does the system explain itself to the agent? An agent arriving at a tool knows nothing about how your team uses it: which list means ready, what a flag means, where to record progress. Left alone, it guesses. The common fix is a prompt document someone writes by hand, which is out of date within a month. A tool designed for agents tells them, from the live system, using your own setup.

5. Does a human approve changes before they land? Agents get things wrong, so the question is whether you see the mistake before it does any damage. For anything that matters, the tool should show exactly what the agent intends to change and wait for a person to say yes.

Those five are why the opening story worked. The to-do list Cowork added to is a board in a tool I built for my own work, and I treated the five as requirements from the start rather than features for later. For an agent to add that card, it had to find my list, know what a card on it should look like and have permission to add one. None of that can be an afterthought. Most of the products you already pay for will get there, some much faster than others, and the five questions tell you which ones are on their way.

Ask before the next renewal

Pick the three tools your teams spend most of their day in. Before each one comes up for renewal, send the vendor the five questions and ask for written answers. Put the answers next to the price when you decide.

A vendor that designed for agents will answer in a paragraph. One that bolted them on will send you a roadmap.