When software gets a new user
Most business software assumes that its user has eyes, a mouse and a working tolerance for menus. We have spent decades improving that relationship. Then an AI assistant arrives, trying to complete a task across several applications, and some of the assumptions become rather visible.
The obvious response is to give the assistant an API. That helps. It also leaves a more interesting question unanswered: which parts of the product were genuinely useful, and which existed to help a person navigate towards them?
Consider a purchasing application. A human opens a supplier record, checks an invoice, compares a purchase order and selects an approval button. The screen quietly assembles context, supplies warnings and limits the next move. If an assistant accesses the underlying records directly, those responsibilities still exist. They need somewhere reliable to live.
This is where I would start designing for software as a user. Separate the business operation from the route a person takes to reach it. An operation such as approving an invoice should carry its own prerequisites, permission checks and consequences. The browser interface and the assistant can then use the same underlying rules. Otherwise, the new integration becomes an unusually efficient route around the old controls.
Machine-readable descriptions help with the mechanics. The OpenAPI specification provides a standard way to describe HTTP APIs. That makes an operation easier to discover and integrate. It cannot, by itself, settle what an organisation means by an approved supplier or an acceptable exception. Those meanings belong in the product and its operating rules.
The same distinction applies to data. A neatly returned number is only useful if its meaning travels with it. Is this the invoiced amount, the outstanding balance or the amount after a proposed credit? Which currency? When was it last checked? The human interface may previously have answered these questions through layout. An assistant needs them expressed directly.
There is a useful lesson here from accessibility. WAI-ARIA defines roles, states and properties that help make interface meaning available to assistive technologies. Its purpose is accessibility, and it should remain so. But the underlying discipline is instructive: software becomes easier to work with when meaning is explicit rather than inferred from appearance.
Permissions need similar care. Giving an assistant everything its owner can access is convenient during a demonstration. In daily use, it can be excessive. A person might have authority to approve a large payment while asking an assistant merely to reconcile the supporting records. OAuth Rich Authorization Requests already provides a mechanism for expressing finer-grained authorisation data. Building useful boundaries around that mechanism remains an application-design task.
Then there is the unglamorous matter of uncertainty. A request times out. Did the invoice get approved? Should the assistant try again? Stripe's idempotency documentation illustrates a practical approach to repeat requests: a key can let the service recognise a retry and return the earlier result. Every consequential operation deserves an equally clear answer to the question of what happens if it is attempted twice.
I suspect these changes will also put pressure on pricing. A seat is an intelligible unit when a person spends the day inside an application. It becomes a less complete description when one assistant coordinates work across several products. There may still be good reasons to charge for seats, especially where collaboration and oversight matter. But buyers will increasingly ask what completed work, reliability and accountability they receive.
Outcome pricing brings its own arguments. What counts as a completed reconciliation? Who pays for an unsuccessful attempt? Who owns the correction? Moving the meter does not remove the need to define the service.
The interface will remain important. People need to inspect, intervene and understand. Its role may gradually shift towards setting intentions and resolving exceptions, while routine navigation moves into the background.
For a software company, that is a useful design test. If another piece of software became your most frequent user tomorrow, would your product still know what it was doing?