Who actually handles the messages you send an AI agent
Four companies touch a message before an AI agent answers it. Of 79 that publish a policy, 3 name all four and 13 name none.
When you text an AI agent, your message does not go to the company whose name is on the website. It goes through four of them, and 13 of the 79 products here name none of those companies.
Three name all four. That sentence used to read "not one", and it changed because every listing here was read again over a single day rather than because anybody published anything new. How we found the ones we found turned out to be the useful part, across all 90 agents in this directory.
The four sets of hands
Somebody carries the message from your phone. Somebody runs the model that reads it. Where the agent uses a website on your behalf, somebody operates that browser. And somebody holds the result, under some country's law.
| Who | Names it |
|---|---|
| Carries the messages | 27 of 79 |
| Runs the model | 40 of 79 |
| Drives the browser | 12 of 79 |
| Holds it, under whose law | 52 of 79 |
Three products name all four and thirteen name none; the second figure was five when this was published on 10 September and has grown with the directory, six of the nine on 16 September being listings added since whose policies name nobody. Both ends of that are small, and the middle is where almost everything sits: a policy that names the model vendor and not the carrier, or the jurisdiction and nothing else.
The blanks are the point, and they are not blanks in the world. Somebody runs that model whether or not the policy says who. Each listing whose policy we have read carries its own chain, linked from the policy wall, with the count of products that name each link beside the ones it does not.
The rest of this piece is about the first row, because it is the one we could investigate rather than only count.
Two vendors, and the split is not what it was
| Agent | Runs on | Source |
|---|---|---|
| alfred_ | Linq, named for SMS delivery | Their page |
| allora | Twilio, named for SMS and WhatsApp delivery | Their page |
| Arlo | Linq (iMessage and FaceTime), Telnyx (phone calls and A2P SMS) | Their page |
| Beside | Apple, named directly for iMessage delivery rather than any of the iMessage providers other listings use | Their page |
| Bo | LINQ Corporate Solutions Private Limited, which the policy names for SMS delivery. See the note below: this is not the Linq listed in this directory. | Their page |
| Boski | Apple or Linq for iMessage, Twilio for SMS, Meta for WhatsApp, each named as the possibility for its channel | Their page |
| Caddy | Linq and Photon (both listed as iMessage delivery infrastructure) | Their page |
| Coral | Photon, named for messaging infrastructure alongside Apple | Their page |
| Ditto | Photon (named as a customer on Photon's own engineering blog: a dating agent where uptime is non-negotiable) | Their page |
| Fambot | Twilio and Linq, both named for delivering its texts | Their page |
| Flip | Photon (named as a customer on Photon's own blog, a Photon-managed iMessage line) | Their page |
| folk | Linq (iMessage and SMS), Photon (WhatsApp), Twilio (number verification) | Their page |
| Hermes | Photon (named as a customer, as Hermes Agent, on Photon's own engineering blog) | Their page |
| Juke | Linq, named for message delivery | Their page |
| Lindy | MessageBird and Twilio, both named among its communication service providers | Their page |
| Manoa | Twilio, named for SMS delivery | Their page |
| Matcha | Photon (Spectrum) and Linq, both named for iMessage delivery | Their page |
| Maxi | Linq | Their page |
| Mochi | Photon, named for iMessage delivery | Their page |
| Muse | Meta | Their page |
| Ollie | Linq | Their page |
| OpenInstinct | Linq, provisioned as an iMessage connector by the project's own one-click deploy | Their page |
| Orchid | Linq (SMS and iMessage) | Their page |
| Pally | Photon (iMessage and RCS), Linq (iMessage, RCS and SMS on some numbers), Twilio (call audio), plus a Pally-operated Cloud Mac on the paid add-on | Their page |
| Poke | Linq (on Linq's customer logo wall for the iMessage API) | Their page |
| Sabi | Linq, named for delivering iMessage and text messages | Their page |
| Slashy | Photon | Their page |
| textmyagent | Twilio, named for SMS delivery | Their page |
| Tomo | Linq (named as its infrastructure partner in a testimonial on Linq's own site) | Their page |
52 publish a privacy policy that names no messaging vendor: 222, Airtap, Alfi, Arlo (arlomind.com), asaply, Boba, Brea, Catch, dots, Duckbill, Dunnit, Espa, Eugene, Homer, Howie, iHermes, Instinct, Iris, Jarvie, Kachi, Lucas, Martin, Miso, Navi, Notis, Nudge, Ohai, OpenClaw, Orbits, Otty, Persona, Predicts, remi, Rene, Series, Served, Shuffle, Sidekicks, Soar, Stanley, Super, szn, Tab, Tempo, Town, TryOpenClaw, Vellum, Wajo, Wis.ai, Zapia, Zeme, Zo Computer.
9 publish no policy page we could find: Air by WZRD, Boardy, brobot, DUO, Ember, Hue, iChatWithGPT, Mae, Ori.
Twenty-nine of 90 listings can be tied to a vendor. Seventeen run on Linq and ten on Photon, and the two sets overlap. Caddy lists both as iMessage delivery. folk uses Linq for iMessage and SMS and Photon for WhatsApp. Pally uses both, plus a Mac it operates in the cloud for the hosted-companion add-on.
The twenty-fourth arrived on 23 September 2026 without anybody here going looking. Slashy was listed that day with a security page that names every subprocessor with a purpose and a country, Photon among them, which makes it the rarest thing in this set: a product that answered the question on its own page before being asked.
This section said something different a few days ago. Every listing tied to a vendor was on Linq, and no competitor appeared even once.
It also said something different this morning. The count of products that can be tied to a carrier at all has roughly doubled since, and not one of them changed a policy. The disclosures were already published and nobody here had opened them.
Where the new ones came from is the part worth keeping. Two arrived in documents under four thousand characters. One arrived as a query parameter in an open-source project's deploy button. And one turned out to be a company whose legal name collides with a vendor listed here, and is a different business entirely.
That was true of what could be established then, and it was an artefact of where we had looked. The evidence had come from what agents publish about their vendors, and Linq is the vendor its customers name. Photon names its customers instead, in prose on its own engineering blog, with a sentence about each. Three of the six products it names are listed here.
The lesson is about method rather than about market share. A concentration you find by looking in one direction is a fact about the direction.
Nobody in this set is confirmed on Twilio, Sendblue or LoopMessage for iMessage. Twilio appears three times, but never for blue bubbles: Arlo uses it for phone calls and A2P SMS, Pally for call audio, folk for phone number verification.
Why this is hard to find out
The obvious method does not work. The sweep below was run on 6 September 2026, and the figures describing it are counts of what was fetched that day rather than of the directory today. We checked the page source of 25 agent sites for the tells that usually give away infrastructure, and found zero. Nothing in the markup of an agent's site names who carries its messages. Unlike analytics or payments, an iMessage provider leaves no script tag, no cookie and no DNS record on the customer's domain.
What works is the disclosure a company is obliged to make. A business that processes personal data has to name its processors, and naming them is the entire purpose of that document. So the answer is published on purpose, on a page almost nobody reads.
The single highest-yield path is /subprocessors. Four of the Linq eight came from a vendor table at exactly that URL. Two more named their provider in the body of the privacy policy instead.
Guessing paths has a ceiling, though. We then read every site's sitemap and footer and fetched everything legal-shaped, 79 pages across 26 agents, and it produced nothing new. At that point the 25 are not hiding it in an unusual place. They are not publishing it.
The other direction: ask the vendor
Three of the Linq eight came from the opposite approach, reading what the providers say about their customers rather than what the agents say about their vendors. Every Photon entry came that way too.
- Tomo appears in a named testimonial on Linq's site calling Linq its closest infrastructure partner and citing hundreds of millions of messages.
- Poke appears in the logo wall under "Trusted by 1,000+ world-class teams", where the image files are served from a folder named Customer logos.
- Ollie appears through its own account, quoted on Linq's site, calling Linq a partner.
Two candidates were rejected, and the reasons matter more than the additions.
Several agents appear in a carousel on Linq's homepage labelled iMessage Agent Store. That is a marketplace, not a customer list. Its own submission form asks you to pick your infrastructure from a dropdown that includes Sendblue, LoopMessage, Photon, BlueBubbles, Blooio, Tuco and self-hosted, so a listing there says nothing at all about who carries the messages. A directory listing is not evidence of infrastructure, and that applies to this directory too.
The second rejection was a testimonial reading "Powered by the best @thelinqapp", signed by a person whose first name matches one of the agents in this directory. He is not connected to it. A name match is not a fact.
What the silence means
Sixty-one agents cannot be tied to a vendor at all. They split into two groups that are worth keeping apart.
Most of them publish a privacy policy that names no messaging vendor at all. They name model providers, analytics and hosting, then stop before the company that holds the actual message content. Every policy we could read is quoted with the date.
Eleven publish no policy page we could find at all, which is a different and larger problem for a product that receives personal messages.
None of this is an accusation of wrongdoing. There is no legal requirement to publish a subprocessor table, and plenty of well-run companies do not. But the gap is worth seeing clearly: your messages pass through a company you cannot name, and for 61 of 90 products there is no published way to find out which.
One more method, and it found one thing
There is a signal that does live in DNS, only not on the agent's domain. Some agents answer from an email-style address rather than a number, the kind an iMessage provider hands out, and the domain in that address belongs to somebody. brobot answers as brobot@a.imsg.co, and imsg.co resolves through the same Cloudflare nameserver pair as loopmessage.com. Cloudflare assigns a pair per account, from a finite pool, so a shared pair is usually one account and occasionally a coincidence.
Run across every address that is an address, every listing's own domain and every managed provider's, on 11 September 2026, that is the only match. Forty of the eighty domains sit on registrar or host nameservers that everyone shares and say nothing. Two listings share a pair with each other rather than with a provider, and those two already share an operator. So the method is real, it is cheap to repeat, and the sentence it produced is on one listing, where it belongs, as evidence rather than as the provider row.
The same sweep loaded every front page five times to see whose number changes. Ember's does on every load, five numbers across five area codes on the second read as on the first. Orchid's and Shuffle's alternate between two. Flip's front page gave one number on 10 September and a different one on 11 September, both in the same area code. Every one of those is a pool of Apple IDs behind one product, which is how iMessage sending works at any scale, and it decides something practical: the number on the page is not always the number to save.
Are the numbers 10DLC? No, and the blocks show it
A related finding, from the twenty-eight agents that publish a contact number.
We looked up the block each number sits in, using public allocation data. All six sit in wireless blocks: five T-Mobile, one Verizon. None sits in the CLEC block a Twilio or Bandwidth number would come from.
Five of those six were recorded in this directory as 10DLC and that was wrong. 10DLC is a long code registered for A2P traffic on the carrier SMS network, and iMessage does not use the carrier SMS network. An agent that reaches you in a blue bubble is not doing 10DLC, whatever else it may also run.
The caveat is on every row: this is the block holder, before number portability, so a number ported away from its original carrier still shows its original assignee. We could not resolve porting, because every free lookup that would settle it requires an account.
Two of the twenty-eight are among the twenty-nine that disclose, both on Linq, and both sit in T-Mobile wireless blocks. Three more unexplained agents sit in T-Mobile wireless blocks too. That is suggestive and nothing more, so their provider stays unrecorded rather than inferred. Two data points do not support publishing a guess about a named company.
If you are choosing an agent
Ask where the messages go. The company you are talking to is rarely the company holding the thread.
The 29 that can be tied to a vendor at all are giving you something real, and it costs them nothing but candour. That is a reasonable proxy for how a company treats the rest of its disclosure, which is why this directory records it as a field rather than a footnote, and ranks on it.
If you are building one
The concentration is the useful signal. If you are choosing infrastructure, the shipped products that disclose have converged on one vendor, and you should understand why before you either follow them or deliberately do not.
It also tells you what your competitors' disclosures will look like. Publishing a subprocessor table is cheap, it is the kind of thing procurement asks for, and right now it puts you in a minority of twenty-nine.
There is a fifth set of hands this piece does not count, and it holds the most dangerous thing. When an agent signs into a site for you, somebody ends up with the credential. What each product says it is given is recorded on every listing here, and 39 of 90 do not say.