The next generation of messaging infrastructure for AI agents.

We believe the best place for an AI agent isn't another app. It's where people already communicate.

We started Photon one year ago with iMessage, hoping to make talking to an AI agent feel as natural as texting a friend. As more developers built on Photon, we saw how much work went into creating that seemingly simple experience. We also started hearing the same question: could their agents reach people on the other platforms they use every day?

Over the past few months, we've rebuilt Photon to make that possible. Today, we're introducing Photon 2.0, with a new iMessage engine, a redesigned dashboard, and a unified API for iMessage, WhatsApp Business, Telegram, SMS, RCS, email, and voice.

Rebuilding iMessage from the inside out

When someone sends a message to an agent, they expect a reply. They don't see the macOS cluster running underneath, the Apple Account registration, or the services coordinating delivery. They just see a conversation, and notice when it doesn't work.

As Photon grew, we learned how much effort it takes to keep that experience consistent. We ran into kernel leaks, inconsistent macOS state, and encryption-related failures that couldn't always be fixed by restarting a process. Those problems pushed us to look beyond individual fixes and rethink the engine itself.

In Photon 2.0, we've rebuilt the iMessage engine and developed our own macOS state-management layer (Astrolabe) to make it more resilient in production. The new engine is approximately 1.6× as fast as the previous version, with latency around 100 ms in our measurements.

We're proud of the speed improvement, but what matters most to us is what it makes possible: developers can spend less time keeping their iMessage infrastructure running and more time thinking about the experience their agents deliver.

Conversations don't happen in just one place

Think about the conversations you have in a day. You might text a friend on iMessage, plan something with a group on WhatsApp, catch up with a community on Telegram, and reply to a customer by email. Sometimes it's easier to make a call.

The scale of these networks is remarkable. WhatsApp has more than 3 billion monthly active users, while Telegram has passed 1 billion. Yet the way people communicate is still spread across different apps, identities, and formats.

For a developer building an agent, each channel has usually meant learning another API and maintaining another integration. And for the person talking to that agent, it may mean moving to a different app just to get something done.

We wanted to remove that extra work on both sides. With Photon 2.0, developers can connect agents to iMessage, SMS, RCS, WhatsApp Business, Telegram, email, and phone calls through one platform. The underlying channels are still different, and we don't try to hide the capabilities that make each one useful. Instead, Photon handles more of the common infrastructure so developers can choose the right place for each conversation.

Designing an API around the conversation

Once we started bringing more channels into Photon, we had to answer a basic question: what should stay the same when a conversation moves from one kind of messaging platform to another?

One service calls something a chat. Another has groups and threads. Reactions, attachments, and replies can look completely different. We didn't want developers to rebuild their application around every one of those differences.

That led us to three core concepts in the Photon 2.0 API: Users, Spaces, and Messages.

A User represents an addressable identity on a platform, scoped to a project. A Space represents the context in which people talk, whether that's a direct message, a group conversation, or a thread. A Message represents what happens there, including text, media, and actions like reactions.

The model is deliberately consistent, but not at the expense of accuracy. A User on one platform isn't automatically the same person on another, and not every channel supports the same features. Developers can use a common API while still handling those differences when they matter.

For an agent, that makes conversations easier to work with. For its developer, it means the code written for one channel can be a useful starting point for the next.

Here's what that looks like in practice:

import { randomUUID } from "node:crypto";

const api = `https://api.photon.codes/v1/projects/${process.env.PHOTON_PROJECT_ID}`;
const agentId = process.env.PHOTON_AGENT_USER_ID; // your agent's User on this platform

async function post(path: string, body: object) {
  const res = await fetch(api + path, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.PHOTON_API_KEY}`,
      "Content-Type": "application/json",
      "idempotency-key": randomUUID(),
    },
    body: JSON.stringify(body),
  });
  return res.json();
}

const platform = "imessage"; // or "whatsapp_business", "telegram", "sms", "email"

// A User is an addressable identity on one platform
const customer = await post("/users", { platform, handle: "+14155550123" });

// A Space is where the conversation happens
const space = await post("/spaces", {
  platform,
  participantIds: [agentId, customer.id],
});

// A Message is what happens there
await post("/messages", {
  spaceId: space.id,
  senderId: agentId,
  content: { type: "text", format: "plain", text: "Hi! How can I help?" },
});

import { randomUUID } from "node:crypto";

const api = `https://api.photon.codes/v1/projects/${process.env.PHOTON_PROJECT_ID}`;
const agentId = process.env.PHOTON_AGENT_USER_ID; // your agent's User on this platform

async function post(path: string, body: object) {
  const res = await fetch(api + path, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.PHOTON_API_KEY}`,
      "Content-Type": "application/json",
      "idempotency-key": randomUUID(),
    },
    body: JSON.stringify(body),
  });
  return res.json();
}

const platform = "imessage"; // or "whatsapp_business", "telegram", "sms", "email"

// A User is an addressable identity on one platform
const customer = await post("/users", { platform, handle: "+14155550123" });

// A Space is where the conversation happens
const space = await post("/spaces", {
  platform,
  participantIds: [agentId, customer.id],
});

// A Message is what happens there
await post("/messages", {
  spaceId: space.id,
  senderId: agentId,
  content: { type: "text", format: "plain", text: "Hi! How can I help?" },
});

import { randomUUID } from "node:crypto";

const api = `https://api.photon.codes/v1/projects/${process.env.PHOTON_PROJECT_ID}`;
const agentId = process.env.PHOTON_AGENT_USER_ID; // your agent's User on this platform

async function post(path: string, body: object) {
  const res = await fetch(api + path, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.PHOTON_API_KEY}`,
      "Content-Type": "application/json",
      "idempotency-key": randomUUID(),
    },
    body: JSON.stringify(body),
  });
  return res.json();
}

const platform = "imessage"; // or "whatsapp_business", "telegram", "sms", "email"

// A User is an addressable identity on one platform
const customer = await post("/users", { platform, handle: "+14155550123" });

// A Space is where the conversation happens
const space = await post("/spaces", {
  platform,
  participantIds: [agentId, customer.id],
});

// A Message is what happens there
await post("/messages", {
  spaceId: space.id,
  senderId: agentId,
  content: { type: "text", format: "plain", text: "Hi! How can I help?" },
});

A dashboard that tells you what's happening

We also spent a lot of time thinking about the moments when developers have to leave their code and figure out what's going on.

Perhaps an iMessage line appears online, but new conversations aren't starting from the expected phone number. Or an Apple Account is active, but SMS relay isn't available. A single green status indicator doesn't tell you enough to understand either problem.

We've redesigned the Photon dashboard to make those details easier to find. You can inspect Apple Account status, Photon service health, SMS and MMS relay availability, outbound identity, and calling configuration from the line view. The rest of the interface has been reorganized around clearer actions and simpler navigation.

Underneath, the dashboard now uses Vite and React with a globally deployed serverless frontend. But the change we hope people notice is simpler: when they open Photon, they can understand what is configured, what is working, and what needs attention without having to piece together clues from several places.

Following a message beyond the API response

Another lesson from operating messaging infrastructure is that accepting a request and delivering a message are two different things.

An HTTP 202 Accepted response tells you Photon accepted the request. It doesn't mean the recipient has received the message. Between those two moments, a message can pass through several systems, each with its own timing and possible failures.

We wanted developers to be able to follow that path instead of guessing where something went wrong. Photon 2.0 brings API logs, OpenTelemetry-compatible traces, and request and event-delivery details into the dashboard. You can inspect a trace, review recorded request and response information where available, and see the results of individual webhook and WebSocket delivery attempts.

For investigations that need more flexibility, there's also a ClickHouse-backed SQL query API. The point of these tools isn't to make every developer an infrastructure detective. It's to make the answers available when something unexpected happens.

Bringing the rest of the stack together

Messaging isn't always text. Sometimes an agent needs to answer a call, and sometimes a business needs to register a number before it can send messages in the United States.

Photon 2.0 supports inbound and outbound calling through SIP, allowing developers to connect Photon numbers to the voice tools they already use. We've put together cookbooks for Retell, ElevenLabs, LiveKit, and Twilio to help with that setup. For U.S. SMS, A2P 10DLC brand and campaign registration can now be managed in the dashboard, alongside the numbers it applies to, while carrier requirements and review still apply.

As projects grow, there are also more people and services that need access. We've improved API-key management, organization controls, and role-based permissions, and expanded integration options through HTTP APIs, WebSockets, Standard Webhooks-compatible delivery, OAuth connectors, and Apps.

These changes came from the same work as the new engine and API: trying to make the many pieces of a messaging product easier to build, understand, and operate together.

What's next

A year ago, we began with the idea that an AI agent should be able to join a conversation on iMessage. Building that first experience taught us just how much infrastructure sits behind something that feels ordinary to the person sending a text.

Photon 2.0 is the result of that year of learning. We've improved the iMessage experience that brought developers to Photon, and extended what we've built so agents can communicate through more of the channels people already use.

Photon 2.0 is available in public beta, with $100 in free credit to start building. We'd love to see what you create with it.