Your Agent Should Live in iMessage, Not Another App

Every agent product I have seen so far ships a chat UI you have to install. Operator Uplift ships the same agent into the chat app you already keep open. iMessage is shipping today, Telegram and WhatsApp are ready, all through a single Photon Spectrum webhook. Here is why we picked that route and how it actually works.

The default agent UX is wrong

Pick any agent product. Sign in, look at the chat. It is a clone of ChatGPT. Same layout, same input, same response. You learn to use it for thirty seconds, then close the tab and go back to your inbox. The agent that drafts your reply lives behind a tab you do not have open when you need it. That is the failure mode every consumer AI product has.

The reason is that "agent" still gets confused with "chat product". The chat is the surface, not the thing you bought. You bought the actions the agent takes. Putting the agent in its own app means you have to remember to go there. Putting the agent in the apps you already check obsessively means you do not.

Why iMessage first

Two reasons. Identity and ubiquity. Identity: an iMessage thread is bound to your phone number, which means the bot knows who you are without a separate login. We bind your verified phone to your Privy account once, on /integrations, and after that every iMessage you send routes through the same approval gate as /chat. Ubiquity: every iPhone owner has iMessage open or one swipe away from every other app they touch.

The wiring is in app/api/webhooks/photon/route.ts. An iMessage hits Photon Spectrum, Spectrum POSTs to our webhook with an HMAC signature, the webhook runs a five-stage dispatch chain (opt-out gate, pending YES/NO, keyword short-circuit, intent classifier, agent fallback), and the agent reply goes back through Photon. Round-trip is typically 2 to 4 seconds. The agent loop is identical to the web one; only the transport differs.

Telegram and WhatsApp, same loop, different transport

Photon Spectrum is provider-agnostic. The same webhook handles inbound from any platform Spectrum bridges. Telegram and WhatsApp are ready because nothing in the agent code is iMessage-specific. The dispatch chain takes a normalized inbound message, routes it through the intent classifier, and emits a reply via the adapter. Swapping iMessage for Telegram or WhatsApp is a Spectrum-dashboard configuration change, not a code change.

We label both Ready instead of Shipping on the homepage Channels section because we have not stress-tested an inbound on those platforms in production. The code path is identical; the difference is rehearsal. The honesty is in the pill.

What we cut

Slack, Discord, and Phone (voice) used to be on the Channels section with status pills. They got trimmed in PR #483 under the "make it work or remove it" rule. Slack and Discord adapters exist as roadmap, not as wired loops; voice exists as a server endpoint (/api/voice/synth for the demo recording, see the Filecoin and ElevenLabs post) but not as a runtime user channel. Putting them on the marketing surface implied they worked. Pulling them is the right call until we ship the round trip end-to-end.

This is the rule we keep running into: every channel that surfaces in marketing has to have a verified end-to-end loop, or it does not surface. iMessage has the loop. Telegram and WhatsApp have the code but not the rehearsal, so they wear a Ready pill. Slack and Discord do not surface at all.

What this changes for the user

If you keep iMessage open all day for personal life, that is the chat app you talk to your assistant in. The bot drafts the email, you tap yes, the draft lands in Gmail. The bot creates the calendar event, you tap yes, the event lands in Calendar. The agent never sees your phone number, your iMessage history, or anyone else you talk to. It just receives the messages you choose to send it. The privacy boundary is the same as any other contact in your iMessage.

Building on iMessage instead of in a new app means we lose the ability to dictate the UI. We gain the ability to be the assistant you already had room for. That trade only makes sense if the agent is good enough that the constraint is interesting. Which is the whole reason we built the approval-gated trust layer first, before any of the channels.