Delivery Windows: The Agent-Native Interface

Delivery Windows vs Application Windows

The application window is such a settled idea that we forget it’s an idea at all. You launch a program, it opens a window, and you operate the window: menus, toolbars, panels, a save button. That whole vocabulary encodes one assumption so deep it’s invisible — a human is driving. The window exists because a person needs a surface to point at, click on, and steer. Take the person out of the loop and the entire apparatus is machinery with no operator. The thesis here is simple: when the agent drives, the right primitive is not an app you operate but a delivery window the agent opens, fills, and closes.

The application window is a cockpit for a human

Think about what an application actually gives you. It gives you controls. A word processor is a set of controls for arranging text. A spreadsheet is a set of controls for arranging numbers. An email client is a set of controls for composing, sorting, and sending. Each control is a small lever a person pulls, and the app’s design is mostly the art of arranging those levers so a human can find them.

This is a cockpit. It’s a good cockpit — decades of refinement went into it — but it’s built around a pilot. The launcher exists so the human can pick which cockpit to sit in. The window manager exists so the human can arrange several cockpits at once. The menus, the toolbars, the preference panes: all of it is surface area for a person to manipulate.

An agent doesn’t want a cockpit. An agent already knows what it’s trying to do. Handing it a word processor and asking it to click through the formatting menu is like handing a shipping manifest to a forklift and asking it to read. The agent doesn’t need levers to pull. It needs to produce a result and show you the result.

What a delivery window is

So invert the model. Instead of the human launching an app and operating it toward a goal, the agent takes the goal and produces the artifact — and then opens a window whose only job is to deliver that artifact to you. It opens when there’s something to show, it holds exactly what you need to see or decide, and it closes when the work is done. That’s a delivery window: a surface the agent opens, fills, and closes, rather than an application you keep open and operate.

Concretely, the difference is about who does the steering. In the app model, you open the mail client, you read the thread, you draft the reply, you hit send — you drove every step, and the app was the road. In the delivery model, you say what you want handled; the agent does the reading and drafting; and what surfaces to you is a window containing the reply, ready for you to approve, edit, or reject. You didn’t operate a mail app. You reviewed a delivery.

The unit of interaction shifts from operating a tool over time to receiving and deciding on a result. You’re no longer a pilot flying the plane. You’re the person the plane was flying the cargo to.

This is worth being precise about, because it’s easy to hear “the agent uses the app for you” — a robot clicking your buttons faster than you can. That’s not it. That’s still the cockpit; you’ve just replaced the pilot. A delivery window is a different shape entirely. There’s no cockpit to fly. There’s a result, a place it appears, and a decision you make about it. The intermediate machinery — the launcher, the window juggling, the middleware that exists so apps can talk to each other — has no reason to be there when nobody’s flying.

What you gain when the middle goes away

The immediate payoff is subtraction. No launcher to hunt through, because you’re not choosing a tool — you’re stating an intent. No window management as a chore, because windows appear when there’s something to deliver and leave when there isn’t, instead of accumulating until you clean them up. No integration glue between fifteen apps, because the thing coordinating the work is the same thing across all of it. A great deal of what a desktop asks of you every day is not the work — it’s the overhead of driving the tools that do the work. Remove the driver and most of that overhead has nothing left to do.

The second payoff is focus. An application window shows you everything the application can do, whether this task needs it or not — the full instrument panel, always. A delivery window shows you what this decision needs and nothing else. That’s not a cosmetic simplification. It’s the difference between a surface designed around a program’s capabilities and a surface designed around your next choice.

And because the agent is the one opening and filling these windows, the same accountability story that belongs at the OS layer applies here too: a delivery is a discrete, reviewable thing, which is exactly what makes agent work possible to inspect and replay instead of write-only. The interface change and the trust change are two views of the same shift — one we make the full argument for at the OS layer.

The honest limits today

None of this arrives all at once, and it would be dishonest to pretend otherwise. The alpha we’re building replaces the desktop session, not the whole software world underneath it. Plenty of real work still lives inside conventional applications, and a delivery-window model has to meet that reality where it is rather than declaring it obsolete. There will be tasks where you genuinely want the cockpit — where the point is the direct, hands-on manipulation, and no amount of “here’s the result” substitutes for doing it yourself. Design work, exploratory analysis, anything where the operating is the thinking. Those don’t go away, and a serious agent-native interface shouldn’t want them to.

The claim is narrower and, we think, sturdier: for the large class of tasks where you don’t actually want to operate a tool — you want an outcome — the application window is friction wearing the costume of a feature. The delivery window is what’s left when you stop assuming a human has to fly the plane.

That’s the interaction model behind an agent-native operating system: not AI bolted onto the desktop as one more app to operate, but a surface where the agent brings you the work and you decide what to do with it. The window still opens. You’re just not the one flying it.