Where This Is Going
AI chats and bots are converging into one thing: a computer for every person, always reachable and mostly asleep, with an agent living in it. Not a chatbot with plugins. A machine that holds your context, your permissions and your tools, wakes up when something needs doing, and goes back to sleep. A chatbot that answers questions doesn’t need one. An agent that does real work over time does: it runs tools, waits on long tasks, and has to pick up where it left off.
Once that exists, most of what we call apps and services stop being places you visit. They become agents spawned for a job, each with the skills and connectors that job needs. A support agent for your network, a travel agent for next week’s trip, a tax agent once a year. Some will come from the big platforms and some will be open source you run yourself. The one piece that stays outside the box is the model, and even that is getting open versions.
The computer is the easy part. What decides who really owns it is everything around it: whether your agent’s memory can leave with you, which permissions it holds and who granted them, and who pays when it gets something wrong. That’s the part of this I care about most.
First, why I think the prediction is closer than it sounds.
Why I Believe It
I was building Nimbus (a stand-in name), a network-support agent, and every chat got its own container. The agent ran diagnostic tools in it, wrote and ran its own code to parse logs and configs, and kept the session’s files there. Chats went idle in the middle of long-running tasks and the containers kept costing money, so I added snapshot and restore. That fixed the bill and gave me a new problem: a restore took about 30 seconds, and users noticed every one of them.
If one support agent needs a computer per chat, every agent that works for someone over time needs one too. A year ago that sounded expensive. This year the clouds started productising the trade-off I was fighting: machines that sleep cheaply and wake fast. They haven’t made it free, since cold starts and storage still cost something, but it’s no longer something every team has to build by hand.
Apps Turn Into Agents
Satya Nadella said it on the BG2 podcast in December 2024: business applications are CRUD databases “with a bunch of business logic”, and in the agent era that logic moves into an AI tier that works across all of them. That’s a strange thing to hear from the CEO of a company that sells a lot of business apps, which is partly why I believe he means it.
The usual answer is that SaaS is the system of record. Your bank’s ledger, your company’s tickets, an airline’s seat inventory: someone is legally responsible for that data, and it isn’t going anywhere. I agree, and I don’t think it contradicts the prediction. The data stays and the interface goes. The service becomes a backend your agent talks to, and you stop visiting it.
The first fights over that have already happened. Amazon sued Perplexity over its Comet shopping agent, and a district court blocked it. In August the Ninth Circuit vacated that injunction, reasoning that when the agent acts on the user’s instruction, it’s the user accessing Amazon. The ruling is narrow and the case goes on, but “your agent is legally you” is now something a federal appeals court has leaned toward. Meanwhile Walmart opened its store to shopping agents. Services are choosing: wall off, open up, or put their own agent at the door to negotiate with yours.
The interface doesn’t vanish completely, it moves into the agent’s window. MCP Apps already lets a service send interactive UI into a chat, and I’ve spent a lot of this year on streaming generated UI into chat and what a sandboxed iframe leaks. Service UI ends up as cards inside someone else’s window: approval screens for paying and signing, the things people enjoy browsing like clothes or holidays, and comparisons that are faster to see than to read. Forms, settings pages and five-step checkouts go.
Open source gets a real seat in this, and it’s the part I like most. OpenClaw and Nous Research’s Hermes Agent are self-hosted agents people already run on a VPS around the clock, talking to them over WhatsApp or Telegram. Hermes goes a step further: it keeps memory across sessions and writes its own skills after a task, close to the self-improving skills I’ve been building. Block’s goose is an open agent framework. Open-weight models like Meta’s Muse Spark Open mean even the model doesn’t have to be rented. You could assemble your own agent computer from open parts today. Most people won’t, for reasons I’ll get to.
The Pieces Are Already Shipping
None of these parts is new on its own. What’s new is that they’re being packaged: an isolated, persistent environment per agent or per session that a developer gets with an API call. This is the shape I keep coming back to, and every layer of it shipped something this year:
On October 22 Google announced Agent Compute Engine: a microVM per agent with a persistent disk, checkpointed when nothing is running, with agents from the same template sharing memory copy-on-write so a restore is fast. That’s my snapshot and restore, built into the platform. It isn’t in preview yet, so I’m going on Google’s description.
Amazon had the pieces first and sat on them: it open-sourced Firecracker, the microVM behind Lambda, in 2018, but on EC2 you only got the KVM it needs on .metal instances, a whole server billed like one. This year it turned on nested virtualization for regular instances and launched Lambda MicroVMs with suspend and resume, my guess being that agent sandboxes made disposable VMs something every AI company wants by the million.
Cloudflare’s docs put the economics in one line: 10,000 agents each active 1% of the time is about 100 running at once.
Consumers already have it: xAI’s Grok Bot gives each bot its own cloud computer that keeps working while your laptop is closed, and Meta’s Muse runs as a background agent on WhatsApp that pays bills and buys things.
The connectors standardised faster than I expected, with MCP now under the Linux Foundation’s Agentic AI Foundation. Skills sit on top, procedures and scripts the agent loads when it needs them. They’re also the new supply-chain risk: a February audit of all 2,857 skills on OpenClaw’s registry found 341 malicious ones.
The models stay outside, at least the smart ones. Tokens keep getting cheaper, but an agent burns through far more of them than a chat does, so for an always-on agent the model bill is bigger than the VM bill. Routine steps will move to small local models and the hard ones will go to a frontier API.
Identity and Money
My day job is agentic products for fintech, KYC included, so this is the part I have the strongest view on. The new payment protocols (Google’s AP2, Visa’s Trusted Agent Protocol, Mastercard’s Agent Pay) are good at proving consent: a signed mandate, a verified agent, a scoped token. What none of them gives you is a named liable party.
In a regulated flow, someone is accountable when money moves the wrong way. With an agent in the middle it could be the user who signed the mandate, the company that built the agent, the platform hosting it, or the merchant who accepted it. The protocols produce evidence. They don’t say who pays. I expect a court to settle that before a standards body does.
Own or Rent
In Nimbus, users owned nothing. The container, the session state and everything the agent learned stayed on our platform when the chat ended, and the user couldn’t take any of it with them. That’s renting in miniature, and it’s the default for every agent product, mine included.
My own split: I rent for convenience and own anything that touches work or money. My MCP servers run locally with my own tokens, the way we built our PR-review server. My skills’ memory is markdown in git, and that’s by design: I built skills that grow their own scripts and skills that learn from corrections around plain files, so any agent can read them and the history lives in the commits. Casual chats and agents live on whatever platform is convenient that week.
That split matters because the lock-in is moving. Switching models is easy now. Switching agents isn’t, because an agent’s value builds up over time: what it knows about you, the permissions you’ve granted, the skills tuned to how you work.
It’s the oldest play in enterprise software, and it explains why leaving is expensive. A CRM rarely keeps a customer because of its features. It keeps them because after five years the records, workflows and integrations all live inside it, and leaving is a migration nobody wants to own. The AI companies are running the same play with memory. Every major assistant shipped a bigger memory this year, and every week of context makes the next switch more expensive. Renting has other costs too: Meta trains on Muse queries by default unless you opt out.
And you can’t really leave yet. There’s no adopted standard for moving agent memory between vendors; exports are partial and imports are copy-paste. My own skill memory moves wherever I go because I designed it to. It took no standard and no vendor’s permission, which tells me the format is the easy part and the incentive is the hard one.
Owning the whole thing is possible, and it has a cost. OpenClaw came with malware in its skills registry and a high-severity flaw that let a malicious link steal an instance’s token, so owning your agent means owning its threat model too.
Email explains the other half: open standards alone don’t fix that. Email is open and federated, and almost everyone rents Gmail anyway. Open protocols didn’t give people ownership. Portability did, for phone numbers: you can take your number to another carrier.
Agents need the same, but memory and permissions move differently. Memory (preferences, notes, learned procedures, history) is data, and I should be able to export it by API in a boring, documented format. Permissions aren’t mine to copy. They’re grants from my bank, my employer, my email provider, and a new host shouldn’t inherit my tokens. It should get the list of what I’d granted and ask each service again. A regulator will probably have to push for the first part. GDPR’s portability right covers some personal data in a machine-readable form, which makes it a starting point, not a solution.
So owning an agent doesn’t mean self-hosting every piece of it. I rent the model and half my tools. It means how much control I keep when I want to switch hosts, revoke access or leave. Without that, the company hosting your agent also ranks which airline it books and takes a cut at checkout, and you can’t walk away.
What Decides Ownership
Every agent will get a computer. That part is already being sold. Who owns it comes down to three things the computer doesn’t settle: whether its memory can leave with you in a format anyone can read, whether its permissions stay grants you can revoke and re-issue instead of tokens a host keeps, and whether someone is named as liable when it acts for you. Get those right and renting is fine. Get them wrong and the most useful software you’ve ever had is also the hardest to leave.
What I’d Bet On
- By mid-2027, every major cloud and every major consumer assistant gives each agent a sleeping computer of its own, billed like Lambda. Half of that has already shipped.
- Per-seat SaaS pricing breaks before SaaS does. If agents do the clicking, “per user per month” stops meaning much.
- Liability for an agent’s payment gets decided in a lawsuit, not in a protocol spec.
- Memory portability arrives because a regulator asks for it, not because a vendor offers it.
I researched and drafted this post with an agent running in a cloud VM, my repo attached and the dev server running inside it, then edited and fact-checked it myself. It was written in the setup it describes.