On Your Behalf

The word "agent" means something and it isn't just "that little box in my IDE". Consider, then, the relationship of Agency. Let's assume, for the duration of this post at least, that the future will involve many much more most "agents", that they will be an important part of how we approach computing. If it helps, place centuries of human history between now and then.

How do we envision that our relationship with computers will look, when we're running the agent of the future?

a relationship of agency

Consider a real relationship of agency in the real world, consider an executive assistant. Some day in the future an agent might read all my mail, as if I were a fancy executive. (For my personal email, of course, it will use a local model, but some people will trust a remote inference provider.) On certain occasions will be reasonable for the agent to respond to the email.

But an executive assistant will never write a letter and sign it Jane Q CEO. Most communications, she signs it with "Jane Doe, executive assistant to Jane Q CEO". Occasionally, she will draft a letter, and the CEO will actually sign it. This is what agency looks like.

Are our computer systems even slightly ready for this?

Your agents will need their own accounts. Not just emails; you will need to be able to delegate specific, meaningful, slices of access to anything, granting it to an agent that should be recognizable as Not You, but On Your Behalf -- for as limited time and purpose as the Principle of Least Privilege and other security best practices would require. Look at something like Github fine grained personal access tokens: this gets you an important part of the way there, but this remains stubbornly You-coded. (I've had some limited success with Gitlab group tokens, too, which are properly bot-coded, but they're clearly not designed for this.)
This will need to be in every service everywhere. It will need to be easy enough for Mom to set up, and difficult to get wrong.
The rules, the authorization, the ask-permission application fundamentally doesn't belong as an opaque configuration on some vendor-supplied service, or implemented by the binary they ship you. (At a minimum it should be a portable format.)

agent management

The buzzwords rule San Francisco. "Agentic agentic agentic agentic." Someday in the abstract future, a user will sit down at her computer and say "I would like to run a new agent" in the same way they think of "I should have a calendar app."

Are our computers really trying to be ready for this?

Tracking agents is a key responsibility for the OS of the future. Today the kernel tracks programs and what resources they're accessing; it tracks users. Some part of the operating system (probably not the kernel) should be tracking agents as first-class objects, generating the workload activity tokens that connect them to its resources. It should track what resources they're using as it goes along: processes, files, inference provider configurations, tools, tool discovery, contexts, history, approvals, memory files.
Deploying those agents is one of the jobs of the OS of the future too -- the application binaries, the processes, the data, the personalities, all the slices-of-system-prompt that are specifically relevant from task to task (the coding agent needs the organization's coding standards; the calendar agent should know when my workday ends, or if lunchtime is sacrosanct for dietary/health reasons). Perhaps one agent will go in a container, another in a lightweight VM. This will not end at the edge of one's laptop. At the office, it may end up deployed on a Kubernetes cluster. Another may run on a Raspberry Pi. You'll need responsibility handoffs. You'll need to be able to load an OS profile full of rules to keep the enterprise's secrets on local inference.

approval workflows everywhere

Someday in the future an agent will help organize my own emails and files and projects and calendars, and sometimes I will be content to let it make changes... but not always. Perhaps on occasions I am like the executive who wants to approve the memo.

... You can't tell me our computers are even remotely ready for this! We check tool calls one at a time!!! Real workflows are complex!

The agent of the future will make a model of all the changes it proposes to make and reason about the specifics. It will do this with a "digital twin," to use the robotics design parlance. Normally this means "a simulation of a robot and its environment that runs on a computer, which is meant to match the reality." We just replace the 3D physics-sim concept with an abstract logic-sim representing "a computer and all its information." This capability will be a feature of the operating system.
This digital twin shouldn't end at the boundaries of a single laptop. You should be digital-twinning the whole Internet... as seen from your individual computer's point of view, anyway. Your simulation should include the emails your agent plans to send, the Jira tickets it intends to update, every integration.
... But part of the digital twin concept is that it's an accurate simulation. If we're going to run our simulation into the future, our integrations need a lot more validation of hypotheticals.

Pro tip: The single best trick I have in my toolbox is, when designing and coding a system, to first build a subsystem such that it can instantiate a valid Plan, and then separately build a subsystem to allow the plan to be Executed. The overhead is trivial, it will keep your code better organized, and it'll make testing things a whole lot easier. It also works well as a Parse-Don't-Validate strategy. You can bundle the two calls together in an all-in-one for convenience if it helps.

If you're a fan of SOLID's Single-Responsibility Principle, this is a subset of it. There are, roughly speaking, three types of responsibility: planning, doing, and orchestrating the planners and doers. Having more than one type of activity in a module is a sign you're mixing responsibilities.

history

Someday in the future my agent will do something I think is wrong, and I'll want to know why.

The digital twin should keep history, including the agent's context and what it has output as reasoning.
And if we have a history system like this, we can reach into the other resources and start performing orthogonal persistence -- making the operating system responsible for loading and saving entire applications and their data, not just individual programs. It will gain a foothold by integrating with existing applications history tracking in, on an app-at-a-time basis, but for the applications of the future it will offer to take over that concern entirely.

security invariants

Someday in the future I might give an agent permission to access to sensitive information. I may also give an agent access to do things like "publish information on the Internet" without asking. But it should never, ever, ever have both at once.

The digital twin will keep track of data sources, sensitivity, and taint. The operating system will use that history to enforce certain permissions automatically. When the agent acquires certain permissions, it will automatically lose the ability to acquire others. Producing detailed work products in the digital twin, for human approval, will make this more workable.

like the olden days of computer

We are not yet at the MS-DOS era of the agentic computer. It is more like the boot-a-5.25"-floppy-disk era. The entire agent-side infrastructure is loaded into a little package named claude.exe, and we have the most basic of standardization on peripherals through the MCP interface. Configuration is managed by the harness. Permission is managed by the harness. Tools are managed by the harness, if not supplied by the harness outright.

We need better than this. We need an operating system.

And it isn't the sort of thing I expect to get from a frontier lab. They're happy to have you locked in, there are too few incentives to play nice. If they do build the operating system, it'll run on their own computers, and your entire enterprise will beholden to the agents in the XyzzyAI Office-Computing Cloud.

A special note where it's due

As of 5 August 2026, CloudflareOS looks like a very good start.