← Back to all posts

The Personal App Store

Isomux has an app store for vibe-coded software: you ask an agent to make a web app, and then other users in your office can see it on their browsers or install it on their phone's home screen in one click.

The Apps page with six running apps in two columns: business-health, commit-plot, game-video, loop, policy-elo and todo. Each row has a thumbnail of the app with an open icon, the app's name, its short address under office.example.com, a one-line description, the agent that created it and the owner, and a menu button. Filters at the top read 'Only mine' and 'All rooms'

In this post, I explain how that works; and, more broadly, I make a case for personal app stores as a meta-harness feature.

Harness vs Meta-harness

  • A harness wraps a model into an agent.
    • Features: tool calling, compaction, thinking effort, etc.
    • Examples: Claude Code and Codex.
  • A meta-harness sits one layer above: it manages the runtime of multiple agents, often across providers.
    • Features: cloud hosting, multiuser conversations, cross-platform UI with real-time sync, cross-provider orchestration, persistent agent identity, dreaming (async memory and skill refinement), etc.
    • Examples: Omnigent by Databricks, qm by YC, and my own Isomux.

The boundary is blurry, but a useful framing is that the harness is model-centered while the meta-harness is human-centered:

Three nested boxes. The innermost is the model. Around it is the harness, which asks how we make the most out of a model, with Claude Code and Codex as examples. Around that is the meta-harness, which asks how humans make the most out of agents, with Omnigent, qm, and Isomux as examples.

Personal software

The terms software-for-one, personal software, and just-in-time software all represent the same concept: an app spun up by an agent on the spot, for a specific user and use case.

This category became possible when agents started one-shotting simple apps, and it supplements the LLM's default way of interacting with you. Chat is not always the best interface!

Say you are planning a trip. The agent can build a web app showing the itinerary, find an unused port, and point you at something like localhost:5173 to see it.

Despite their simplicity, personal software has some cool features that normal software doesn't. Here's the core architecture:

A four-node loop. The user sends natural language inputs to the agent and gets natural language outputs back; the user sends interactive inputs to the just-in-time app and gets interactive outputs back. The agent writes the app's implementation and the app sends the agent notifications. The agent maps natural language requests to structured state updates and reads back data to base answers on; the app writes state updates and reads back data to display.

The full graph is not needed for every app, but it can be convenient:

  • You can engage with the app via both natural language and an interactive UI. Consider a to-do app. Sometimes, you want to look at a dashboard and tick items off. Sometimes, it's better to ramble at the agent and let it figure out how to map that into to-do list updates.
  • The arrow going from the app to the agent forms a closed loop: agents can build apps that message them back (we'll see how soon). For example, imagine a service monitoring app that messages the agent when a health metric crosses a threshold.

Personal software is typically vibe coded (the user often doesn't even know the tech stack), and version control is optional.

Scaling Personal Software

As people reach for personal software more and more, we hit some scaling pains:

  • A port coordination problem: ports are hard to remember, can collide, and are hostile to non-technical users.
  • A lifecycle problem: depending on how agents spin up apps, the apps may go down when the user clears the session.

In fact, personal software benefits from many meta-harness features: 24/7 access independent of the agents, multi-device support, and human collaboration with authentication.

The App Orchestrator

The clean solution is an app orchestrator module in the meta-harness itself. The meta-harness already solves the hard parts! That is:

  • An always-on box
  • accounts and permissions
  • multi-device
  • an API agents already call

The app orchestrator piggybacks on all of that and adds centralized port assignment. Ideally, it also hides ports from the end user and shows them a nice UI with all their apps: the personal app store.

One box labelled meta-harness, noted as the always-on host. Inside it are two runtimes side by side: a group of agents on the left and a group of apps named todo, commit-plot, and business-health on the right. Between them run the two legs of a loop. On the outbound leg the agents register apps with the app orchestrator, which assigns ports and keeps apps alive, and the orchestrator runs them. On the return leg an app calls message queueing, which queues if the agent is busy and then delivers to the agents. Below, users reach both runtimes with one login from any device.

How it works:1

  • The app orchestrator manages an app registry.
  • The agents register apps by name via the meta-harness API (which they know about via the meta-harness system prompt).
  • The orchestrator finds a free port for the app and gives it a name-based URL, like metaharness-url/todo-list (metaharness-url is where you manage your agents).
  • Apps share the lifetime of the meta-harness, not the agents. They survive individual sessions.
  • Apps ride the same authentication as the meta-harness, so privacy and multiplayer features come for free.2
  • The user can install an app on their phone's home screen, like a native app.3
  • The meta-harness UI includes a page where the user can see and manage all their apps, like a personal app store.
  • Each app has a chat widget, so the user can talk to the agent that built it without leaving the app. The user can paste screenshots of the app into it.
The chat widget open on this blog's preview app. The panel is titled 'Chat with Personal Site Agent', with 'Open without chat' and 'Install as app' links, and notes that the chat is shared with members of the agent's room. It shows a screenshot the user pasted and the agent's last reply about the post in review. Below are a message box with a draft reply, a hint to paste a screenshot, and Attach image and Send buttons. A 'Chat' button with the agent's avatar sits in the bottom-right corner.

Meta-harnesses often have API endpoints for messaging agents, which means that the infrastructure to implement the closed-loop is already there.

Demo

Here is the full workflow in Isomux (follow the captions):

An Isomux conversation. The user asks for an app that plots their commits over time at weekly resolution, where clicking a week sends the agent a message; further down, a 'Register app' tool call carries the app's name, command, working directory, and description.
1 / 4
I ask an agent for a personal-software app (1), and the agent registers it with Isomux (2).

Examples

This section is to give readers ideas for things they can use personal software for.

Despite the feature being fairly new, as of 2026-10-28, my office is running 29 apps, built by 25 agents for 5 different users.4

Four guests in my office, including family members, got apps built for them without ever seeing a port, a terminal, or a deploy. They asked an agent for something, and a URL appeared.

A cute detail is that the app orchestrator gives each one a different favicon:

A browser tab bar with seven tabs open side by side, each showing a different favicon: the office itself, then Aurora, Business health, Commit Plot, Wall Game video, and two more.

Loop Engineering App

My biggest app runs the development loop of Isomux itself.

The loop app open at its short address, with the chat widget open on the right. The app shows its task-state diagram on the left and a design packet card in the Triage queue in the middle. The widget panel, titled 'Chat with Isomux Curator' with an 'Open app directly' link, notes that the chat is shared with members of the agent's room, shows the curator's last reply summarizing triage decisions, and has a hint to paste a screenshot, a message box, and Attach image and Send buttons. A 'Chat' button with the curator's avatar sits in the bottom-right corner

The Isomux backlog had hundreds of tasks, so I made an app to help me clear them. It moves them through a pipeline of agents, and only stops for me at triage and sign-off.

It plugs into the office in many ways:

  • Task board: the board is the loop's only state. Every 2 minutes, the app gives the next ready task to each free worker agent.
  • Agent messaging: Agents send "design packets" for tasks to the app, where I triage them. Triage decisions go back to the agents to kick off implementation.
  • Chat widget: I refine the app as I go by talking to the agent that built it.

Other Examples

Six personal examples:5

The business-health dashboard, with customer-identifying fields blacked out. Six status cards read OK: Neon Allowance with its plan and byte usage, Customer Offices, Control Plane, Billing, Provisioner with one machine started, and Signup with HTTP status 200. Below them a Customer Offices table lists billing state and paid-through dates.
1 / 6
A monitoring dashboard for Hosted Isomux (isomux.app). It queries the DB, Stripe, etc. every 30 min, and automatically messages my Isomux Tech Lead agent if there are any issues.

Conclusions

The personal app store fits naturally in the meta-harness and doesn't really have any downside, which is rare.6 The main pieces were already there; the missing connection was the app orchestrator module.

I expect the idea to catch on or be re-invented by a bigger player soon. If you are building on top of harnesses, copy it! Or hire me and I'll do it :)

But if you just want your own app store, check out Isomux.

Want to leave a comment? You can post under the linkedin post or the X post.

Footnotes

  1. Implementation details are at agent-apps-design.md. ↩︎

  2. The way it works in Isomux is that the office owner can see apps registered by every agent, whereas office members can see only apps registered by agents in rooms they have access to. ↩︎

  3. Isomux is a PWA (Progressive Web Application), so "Add to Home Screen" installs it as a native app. Each app inherits this behavior, so "Add to Home Screen" works on them too. ↩︎

  4. I don't know their tech stacks, but I've seen at least JS and Python apps. I also don't know which ones are on GitHub, if any. As mentioned, these are non-concerns for just-in-time apps. ↩︎

  5. I made one just to write this post - my usual blog previewer was being slow, so I asked the agent to spin up a new one. ↩︎

  6. Another major upside that didn't even make it to the post is that, by controlling ports at the meta-harness level, you can lock down security a lot more tightly than if random agents are exposing ports willy-nilly. ↩︎

Stay in the loop

I'd love to tell you when I publish a new post.

Get notified when I write about DS&A or software engineering. Unsubscribe anytime if it's not your vibe.

Prefer RSS? Subscribe via rss.xml.

Want to read more? Here are other posts:

Loop Engineering

Loop Engineering

IsomuxAI

What I learned from moving Isomux development from work sessions to a continuous loop of agents.

Read more

Nil Mamano

Computer scientist, software engineer, author.