My phone has a handful of apps on it that nobody else will ever use. One watches a few dealer pages and subreddits for watch listings I care about. Others are smaller and stranger. They run on a Mac Studio at home, and Claude, Codex and Antigravity wrote all the code. My contribution was describing what I wanted solved and in some occasions picking between options to solve it. I reach these apps from my phone over Tailscale, which puts them on a private network made of my own devices.
What I have never done is put any of them in the App Store. Consider what that would take: a developer account, code signing, review, privacy disclosures and a public listing, all for software with exactly one user. For software whose only user is me, the distribution problem mostly disappears. I know who commissioned it, where it runs and who is allowed to use it. What I don’t know for sure is whether the agents got it right, and that turns out to be a different kind of trust problem.
That small absurdity points at something bigger. Nearly every layer of modern computing assumes software is a product, made by professionals and shipped to strangers. Strangers can’t read the code, so trust gets anchored to the maker. Who are you, has anyone checked your work, will you still be around next year? Access models, security models, distribution and billing all grow out of that one assumption.
It was a reasonable assumption, because building software was expensive, and most people never wanted to build it anyway. They want a job done. Today that means picking an app that roughly fits the job and learning how to drive it. The app is a workaround for the cost of building the exact tool.
Walk down the stack and you find it everywhere.
Distribution. Code signing, notarization and store review are built for software crossing a trust boundary, from a developer to a user. When those are the same person, some of that protection still matters, but the identity check turns circular: the platform is verifying me to me.
The operating system. On a phone, and in the permission model of a Mac, the application is the unit of everything: install, sandbox, permissions, updates. A tool an agent builds for one task doesn’t fit that shape. It might live for an afternoon, touch data that belongs to three different apps, and never need an icon.
Cloud APIs. This is where it hurts most. I pay for Google Drive (all those raw photos are huge!). The files in it are mine. This evening’s project, after a corrupted file bit me, is a small tool that catches bad files in my photo archive before they sync up. The hard part isn’t spotting a broken file. It’s getting permission to touch my own Drive. The path runs through a Cloud Console project, an OAuth consent screen and a set of scopes. Take the app out of testing and some scopes trigger Google’s verification machinery; leave it in testing and the refresh tokens expire every seven days. Each step makes sense for a company asking a million strangers for their data. For me, it amounts to filing paperwork to ask myself for permission.
The network. The public internet assumes anyone can knock, so every app builds its own front door. For personal software, “only me” should be a basic building block. Today it takes something like Tailscale to get it.
There is a tell that the plumbing doesn’t fit. The most capable consumer agents spend much of their time opening browsers and filling in forms, operating screens designed for human hands. They do this because the programmatic front door was built for developers shipping products, not for an owner sending a helper to fetch their own things.
None of this is new as an idea. Personal computing started out personal. Spreadsheets, HyperCard, AppleScript, Unix pipes and Excel macros all let people make tools for themselves, and some were wildly successful. None of them made building software something most people do, because making the tool still meant becoming its author. The center of gravity moved to products: the web, SaaS, app stores. The assumptions hardened around that.
What’s different now is that nobody has to become an author. The agent writes the tool as a side effect of doing the job. When the cost of building drops toward zero, the assumptions that were merely annoying start to bind.
Personal software doesn’t mean we get to drop security. It means the threat model moves. The risk is no longer a malicious vendor. It’s a semi-trusted author, the agent, writing code that runs with my credentials. A bug, a misread instruction or a prompt injection buried in a web page becomes an action taken in my name.
So personal software needs finer control, not looser. Least privilege, applied to tasks rather than apps, with permissions that expire when the task is done. Provenance: what made this tool, from what request, and when. Reversibility as a system feature, with snapshots, undo and dry runs, so the cost of a mistake is a rollback rather than an apology.
Concretely, that points at a few changes. Operating systems could treat owner-signed code as a first-class tier instead of an unsigned oddity. Cloud services could offer an owner data plane that sits apart from the developer platform; fine-grained personal access tokens, the way GitHub does them, would be a start. And private-by-default hosting would make “only me” a setting rather than a weekend project.
Meta’s Muse, which launched last month, is the clearest attempt I’ve seen to put a capable agent in front of normal people. It books travel, sends email, fills in forms and buys things. It also looks a lot like the trust model above. Each person’s agent runs in its own cloud VM alongside their data. A separate Sentinel agent controls what goes out to the internet, credentials are stored where Muse itself can’t see them, users choose which actions need their approval, and there is an audit trail. It is already being tested in public. Within weeks of launch, a user reported that Muse, handling his Facebook Marketplace sales, gave a buyer his home address and accepted a lowball offer without checking with him. Whether the fault was a too-broad permission or the agent overreaching, “the user authorized the agent” is clearly not a fine enough security model.
Put that next to my setup and you get two ends of the same shift. Mine runs on my own box, and the trust boundary is me: Tailscale keeps strangers out and I review what the agents build. The tools persist, and I keep reusing them. Muse runs on Meta’s machines, Meta is the trust boundary, and whatever tools it builds along the way are disposable. The interface is a chat thread. I’m accumulating software. Muse is accumulating capability. What the two have in common is that the trust layer had to be built from scratch, by me or by Meta, because the operating system and the cloud underneath don’t provide one.
I should be honest about where I sit. I spend my days around developer tools and my evenings arguing with coding agents. People like me are reliably bad at guessing how fast things spread, and personal software has been about to happen several times before.
Muse is a fair test, though. It is free for most tasks, and it shows up in WhatsApp, a chat app people already use, so there is no price barrier and no new icon to learn. If it stalls under those conditions, the obstacle is habit and trust, not plumbing. It is less than a month old, so it proves nothing yet. I’m watching it like everyone else.
Which leaves me with questions rather than a conclusion.
Will people hand jobs to an agent, or is the grid of app icons too ingrained? Icons are a mental model as much as an interface: a row of known tools, each from a known maker, each doing a known thing. Picking an app is also picking whom to trust. When an agent builds the tool on the fly, what replaces that choice for someone who will never look under the hood?
And the one I keep coming back to: does a normal person ever need the persistent tool, or is “the job got done” enough? If it’s the latter, my Mac Studio isn’t an early look at the mainstream. It’s a different road, and the two may never meet.
Either way, the plumbing on my road needs work. We’ve made personal software cheap to build well before working out how to trust it.
