The Next Personal Software Won't Be an App

OpenAI describes Codex plugins as bundles of apps, skills, instructions, and workflows. Reading that, I kept coming back to a much simpler question: what will people actually ask their computers to do?

I think they will ask for the thing they want: "Update my CV", "send this email", or "prepare my agenda every morning." The agent will figure out whether it needs an API, an existing tool, or some code to get it done.

Ask for the thing you want

Today we usually translate a need into the shape of an application. We choose a product, learn its interface, enter the data it expects, and follow the workflow somebody designed for us. Even when another person builds the application, we still tend to describe the solution first: "I want a program that does this."

Take the morning agenda. The useful request is: "I want my agenda ready when I wake up." An agent could read an authorised calendar, check the relevant messages, and prepare the document or notification. It may call an existing service or run a script. That is its problem.

The user should not have to decide any of that before asking for the result. This is what I mean when I say the next personal software may not be an app. The program can still exist, but it becomes something the agent uses along the way.

desired result -> agent -> systems, APIs, or code -> result

The agent can still choose code

Code still has a very obvious job here. A lot of work is simply better when it runs deterministically.

If an operation has to validate an exact condition, fresh interpretation on every run is a bad idea. The same applies when a small piece of code can repeat the operation thousands of times without changing its mind. The agent can prepare the inputs, run that component, and deal with whatever it rejects.

It may also write a script for one part of a task. If the same operation keeps coming back, that script can become a stable tool. If a service already does the job well, the agent can call its API. Again, the user asks for the result and the agent figures out the machinery.

I suspect APIs will become even more important if this happens. An agent needs reliable capabilities with clear permissions and predictable responses. Putting a chat in front of an operation does not make the system behind it disappear.

An hour versus ten seconds

Then there is speed.

An agent has to understand the request, collect context, decide which tools to call, wait for them, and check what came back. It burns tokens while doing that. Even if models become much cheaper, the execution still takes time.

So imagine the agent needs an hour for something a small program finishes in ten seconds. The numbers are hypothetical; I am not presenting a benchmark. Use the program.

Tasks that code can run quickly and cheaply will keep running as code. The agent may sit above them to decide when to execute them or to handle the weird case that nobody anticipated. It should not think through a known operation again merely because it can.

Some software is valuable because it stays online

I have two SaaS products, Notion to Maps and Notion to Calendar, whose value continues for as long as people use them. Notion to Maps has the clearest example: a live GPX URL (and many other types).

It can turn a Notion database into a GPX file for GPS devices. You could run that conversion once and copy the file by hand. The SaaS keeps the GPX available through a URL instead. If the device supports it, it can fetch fresh data from that URL while the points of interest continue to be managed in Notion.

That removes the repeated export-and-copy step. The person keeps working in Notion, and Notion to Maps keeps the bridge to the GPS device online.

An agent may eventually manage the Notion database too. The service still has a job: maintain the URL and generate the current GPX whenever the device asks for it. Keeping that infrastructure running makes sense here. The customer gets a URL that is ready whenever the GPS device asks for it, and the SaaS keeps doing useful work between visits.

Tasks and systems have different constraints

A task can leave a result and finish. A system may have to preserve shared state for years. It coordinates different people and keeps working while nobody is talking to an agent.

Booking is a useful conceptual example. A traveller could ask an agent to find and reserve a hotel. The person at reception could use another agent to retrieve the reservation too.

There is still a shared system in the middle. It has to know which rooms are available and preserve the reservation. When the traveller arrives, the hotel has to be expecting the right person. Several people and organisations are working on the same state, and the result exists in the real world.

Agents can start the booking, query the system, and help when something goes wrong. The deterministic software holds the parts that cannot vary. A room cannot be booked twice because two models interpreted the available state differently.

The mobile hypothesis

This may become much more common when an agent has useful, authorised access to the personal context already on a phone. A person could ask for something when they need it, without opening a computer or working out which app contains the workflow.

That complete mobile integration is still a hypothesis. It needs permissions people can understand, and it needs to be reliable enough for ordinary tasks. If that happens, adoption could be brutally fast. By brutal I mean very fast: people would not have to learn how to build or deploy anything.

So this is my guess. For a lot of personal work, you will ask for the result. The agent will use the software that gets it done. The software stays; you just stop having to think about it first.