We built an agent on Keiki that builds Lovable apps over text

Short answer: To show what Keiki can do, we built an agent that connects to Lovable through its public MCP server and builds, edits and publishes apps over text, with each person signing in to their own Lovable account from a link in the thread. Keiki handles the per-user OAuth, background builds, memory, media and delivery on every channel, so the whole agent is one config file, a prompt and kit.sync().

You text +1 (628) 502-4106: "build me a booking page for my yoga studio." A few seconds later you get a sign-in link. You tap it, sign in to your own Lovable account, and the agent replies with your name and "Build started", plus a link to the project that's already being built. A few minutes later a real screenshot of the app arrives in the thread, with a preview link under it. You reply "make it warmer, and add a waitlist." It does that. You say "ship it," and the next message is a live URL.

You don't install anything, open a dashboard, or paste an API key. It all happens in the Messages app you already use.

That's an agent we built on Keiki to show what the platform can do. It connects to Lovable through Lovable's public MCP server, which speaks the open Model Context Protocol. It isn't a partnership or an official Lovable product. It's a Keiki Labs showcase, and the code is open in Mail-0/labs. The most interesting part is how little code it took. The whole agent is one TypeScript file and a prompt, deployed with a single call:

await kit.sync()

Everything else comes from Keiki.

The hard part isn't the model

A demo that chats with an app builder is easy to make. Shipping one that strangers can use over a phone number is much harder, because the conversation is the smallest piece of the work. You also need:

• Identity. Who is this person? Is this their first message or their fortieth?
• Delegated auth. Every user has to connect their own Lovable account. That means a real OAuth flow started from a text message, with tokens that are never shared across users and never seen by the model.
• Long-running work. An app build takes minutes. Text conversations expect an answer in seconds.
• State. "Make the header bigger" only makes sense if the agent remembers which app, which workspace and which design direction you settled on last Tuesday.
• Proof. Users need to see the result, which means real screenshots and real links sent back into the chat, not a description.
• Safety. Project code, web pages and images are untrusted input. Publishing, purchases and destructive changes need clear intent from the user.
• Channels. iMessage, SMS, WhatsApp, Telegram, Slack: each has its own delivery rules, media formats and quirks.

Teams usually spend months building that layer before the product feels like anything. On Keiki, our agent got all of it from config.

What we declared

Our agent's definition reads like a product spec, not infrastructure code. In plain terms, it says:

• Each person connects their own Lovable account. A per-user MCP connection with a pre-registered OAuth client. The deployer's account is never used.
• Remember each conversation. Conversation-scoped memory keeps track of the active project, its preview links and the user's preferences.
• Give each user a private, persistent workspace. A sandbox that stays around between messages, for screenshots, uploads and generated assets.
• Let it see the web. Browser and scraping tools for checking public previews.
• Let it make images. An installable Images capability for artwork the app actually uses.
• Let it follow up on its own. Loops, so a build that finishes ten minutes later still gets reported back.
• Handle messy human input. Voice notes are transcribed, photos and sketches are described, and documents are read.
• Behave like a person on text. Steering settings for bursts of messages and for people who change their mind mid-build.
• Stay safe. Reply guards and prompt-injection screening on inbound text.

Each of those is a line or two of config. The rest of the work happens on the platform.

What Keiki makes possible

1. OAuth that starts in a text message

The first message, even just "hey", starts account connection. Keiki creates a provider sign-in link that belongs to that conversation and sends it in the thread, so it can't be mistyped or faked. After sign-in, the grant is tied to that person and that conversation's identity. Before any work starts, the agent checks who the user is against their own Lovable account.

Lovable only grants its sensitive publish permissions to approved OAuth clients. So Keiki supports both automatic client registration from the MCP spec and bring-your-own clients. With the second, the developer gives the platform the names of stored secrets, never the values. Credentials stay in the platform. The model, the sandbox and the generated code never see them.

If a grant expires or is revoked, the user gets a fresh, working link and their project is kept. Nothing fails silently.

2. Minutes-long work in a seconds-long medium

When the user asks for a build, the agent replies within seconds with the real editor link and an honest status. The build then runs in the background. Keiki gives the agent durable background work and one-time monitors that keep running between messages. When the build finishes, the agent picks up the result, checks it and sends the outcome without waiting for the user to ask "is it done?"

Keiki's steering layer handles how people actually text: three messages in a row, or "actually, make it blue" halfway through a build. Rapid bursts are grouped into one request, and a correction sent mid-turn interrupts the old plan instead of queuing behind it.

3. Specialists, not one overloaded loop

Inside a single turn, Keiki's runtime can hand focused jobs to specialized workers. One handles provider operations, one handles files and binaries, one handles browsing. The agent stays a single, coherent voice to the user while the work happens in parallel underneath. We won't go into how that routing works. What matters is that the agent behaves more like a small team than a chatbot, and the developer didn't write any orchestration code.

4. Real proof, delivered natively

The agent's main deliverable is a real screenshot of the real app, sent as an image in the thread with the preview link in the caption. If the provider's screenshot is older than the latest edit, the agent waits, checks again and sends the fresh one. It never presents an old image as evidence of new work. Keiki handles turning bytes into a native media message on each channel, including the fallback when a channel can't attach a caption.

On iMessage, the agent can also send a real contact card, so its name and logo appear in the user's Messages app like any other contact.

5. Personal state, without leaks

Every user's memory, sandbox and Lovable grant is scoped on the server from their authenticated identity. A phone number or project ID typed into a message is never trusted to pick another person's data. That's a platform rule, not something each prompt has to restate. It's why one agent can serve everyone who texts its number without any of them seeing someone else's apps.

6. One agent, every channel

The same definition works over iMessage, SMS, WhatsApp, Telegram, Slack, email and a web playground. Assigning a line in the Keiki dashboard is the last step of setup. Changing the config is another kit.sync().

Why this matters

Lovable already made building software feel like a conversation. Our agent moves that conversation to where people already talk: their phone's messaging app, with no new app, tab or account to manage.

For builders, the takeaway is broader than Lovable. Any product with an MCP server is now an agent away from a text-native experience. The usual blockers are per-user OAuth from a chat, background jobs, memory, media and channel delivery. On Keiki those are config options, not projects. Developers spend their time on the experience: the voice, the judgment, and when to ask versus when to act.

This agent is our showcase of that. It's one file, one prompt and one sync, and the rest is handled by the platform.

Try it now. Text +1 (628) 502-4106 with something you want built.

Build your own. The full example is open source in Mail-0/labs/agents/lovable. Clone it, add your Keiki key and Lovable OAuth client, run bun run sync, and assign a line.

Start building on Keiki