Picture the moment right after the magic. You typed a sentence into an app maker — something like “a shared tracker for who is feeding the cat this week” — and forty seconds later a working thing exists. It has buttons. It saves state. It is yours. And then you hit the part nobody designs for: you need to get it to your roommate. So you copy a link, drop it into a message thread, and watch your beautiful generated artifact become a gray rectangle in someone else’s chat app.
That gap between generating software and living with software is where I suspect most of the interesting engineering of the next two years gets done. Which is why the chatter about Wabi moving toward a messaging experience caught my attention — even though, and I want to be precise here,
What is actually on the record
The verifiable picture is thin. Wabi is an AI-powered social platform for app creation, founded by the person behind Replika. It raised $20M with the stated aim of opening AI app creation to a general audience. That is the confirmed material. Reporting on a pivot to messaging is not something I can substantiate from available sources, so treat the rest of this piece as architectural analysis of a plausible direction, not as news.
Worth separating those two things carefully, because the architecture question is interesting regardless of what any single company ships.
Why a message thread is a reasonable runtime
Agent systems have a persistent structural problem: they produce output that needs somewhere to live. A generated app is not a file and not quite a webpage. It has state, it has participants, it has a lifespan, and it usually has a reason to notify someone. Traditional app distribution — install, icon, launch — is an enormous amount of ceremony for a cat-feeding tracker that will matter for nine days.
A messaging thread already solves several of those problems as a side effect of being a messaging thread:
- Identity and membership. The set of people who can see the thread is the set of people who can use the app. No separate auth flow, no invite system to build.
- Persistence and ordering. Threads are append-only logs with timestamps. That is not far from what agent memory wants to be anyway.
- Turn-taking. Chat interfaces have a native concept of whose move it is, which maps cleanly onto human-in-the-loop agent designs.
- Addressing. Mentioning a participant is a routing primitive. If one of the participants is an agent, you have invocation for free.
Put those together and the message thread starts looking less like a place you share apps and more like the process table they run in. Each generated app becomes a participant with scoped permissions rather than a standalone binary.
The parts that get genuinely hard
I do not want to make this sound clean. Collapsing app distribution into a social surface creates trust boundaries that are difficult to draw.
Untrusted content sharing a channel with agent instructions
If agents read a thread to understand context, then anything any participant types is potentially instruction-shaped. A shared thread containing both human conversation and agent-readable state is a prompt injection surface with a social graph attached. The mitigation is not clever prompting. It is structural: separating the channel that carries instructions from the channel that carries data, and treating everything in the latter as inert.
Capability scoping per app, not per user
A generated app that can read a thread’s history is very different from one that can post to it, and different again from one that can reach the network. Most permission models today are attached to users or to whole applications. Ephemeral, user-generated apps need capability grants that are narrower and shorter-lived than anything in the mobile permission model.
The absence of a review step
App stores are slow and often frustrating, and they also catch things. Software generated on demand and shared instantly into a group has no equivalent chokepoint. That pushes the entire safety burden into the sandbox and the runtime, which means the sandbox has to be much better than the ones we ship today.
What I would want to see before believing it works
The interesting metric is not how fast an app gets generated. It is what happens on day five. Does the thing still work when the underlying model version changes? Can a participant who did not write it understand what it does? When it breaks, does anyone find out?
Observability is the tell. If a platform in this shape ships without a way to inspect what a generated app is doing with thread data, the architecture is a demo. If it ships with capability manifests, per-app audit trails, and a clear story about which surfaces are instruction-bearing, then someone has thought hard about the failure modes.
Either way, the underlying idea — that conversation is a better container for small software than the desktop metaphor — deserves more attention than it currently gets. Whether Wabi is the company pursuing it is a question I would rather leave open until the reporting firms up.
🕒 Published: