Poke makes using AI agents as easy as sending a text

Poke’s pitch is simple: text a phone number, get an AI agent that can actually do things. No app install. No workflow builder. No extra tab to manage. It works over iMessage, SMS, and Telegram, and connects to tools people already use, including Gmail, Google Calendar, Notion, Linear, GitHub, Sentry, Vercel, Supabase, PostHog, and Cursor Cloud Agents.

Investors are buying the idea. On April 8, The Interaction Company of California said it raised another $10 million, on top of a $15 million seed last year, at a $300 million post-money valuation. For a 10-person startup, that’s a big wager on a specific view of the market: messaging may be a better interface for AI automation than another dashboard.

The idea sounds obvious once you hear it. Building it well is harder than the usual “text your assistant” demo makes it look.

Why this lands better than most agent pitches

A lot of agent products still demand too much setup. Install a client. Connect a stack of tools. Learn the prompt style. Watch it think. Hope it doesn’t email the wrong person.

Poke cuts out a lot of that by using an interface people already live in. A text thread is familiar and asynchronous. It shows up on the lock screen. You don’t have to remember which app you left open.

That matters because agent software keeps running into the same wall. The models can do impressive work. The product around them is often awkward. Poke’s smart move is the interface and the distribution.

The conversation thread is the app.

In practice, Poke feels closer to a usable version of IFTTT or Zapier than to a chatbot with tool use stapled on. You can text something like “alert me when my boss emails me” or “summarize today’s PostHog anomalies at 6pm,” and Poke maps that request to a prebuilt automation, or what it calls a recipe. Those recipes connect to services through OAuth and run from chat prompts, schedules, or incoming webhooks.

That may sound less exciting than desktop-driving super-agents. Fine. Reliability usually looks boring.

How the product is put together

Under the hood, Poke looks like a messaging ingress layer attached to an orchestration engine.

Messages come in through iMessage, SMS, and Telegram. TechCrunch reported that the company uses Linq to host assistant experiences inside messaging apps, which suggests Poke is outsourcing a lot of the transport and compliance work instead of rebuilding it. That’s the right call. Messaging platforms are full of ugly edge cases around delivery, identity, and policy.

Once a message arrives, Poke has to do three things quickly:

1. figure out what the user wants
2. pick a model that’s good enough for the job
3. execute the action in the right connected service

That second step matters more than a lot of agent marketing admits. Poke says it’s model-agnostic and can route tasks across OpenAI, other providers, and open source models. For this kind of product, that’s a practical requirement.

A message-based assistant lives under tight latency and cost limits. If someone texts “move my 3pm to tomorrow,” they expect a response in seconds, not a long reasoning routine. The sensible setup is cheap, fast intent classification for routine actions, then a heavier model only when the request is fuzzy or spans multiple domains. Routing by task type, latency budget, and past success rate makes sense. Sending every request to a top-tier model would wreck margins.

The execution layer also has to deal with the mess of real-world messaging. SMS duplicates messages. Providers time out. Webhooks retry. Users send the same instruction twice because they didn’t see the first response. So the backend needs the standard grown-up plumbing: idempotency keys, retries with backoff, per-run logs, request tracing, and a capability registry that knows whether “create an event” should call Google Calendar or Outlook for that user.

That work won’t show up in the demo. It still decides whether the product is any good.

Text is a strong interface and a weak trust boundary

Poke’s best product decision is also where things get risky.

Phone numbers are convenient identity anchors. They are not strong ones. SIM swaps happen. SMS is noisy. Messaging apps get forwarded, synced, and left unlocked. If you’re building an assistant that can touch calendars, inboxes, issue trackers, and deploy tooling, “just text it” should make you nervous.

Any serious implementation needs layers of trust. The likely pattern is low-risk actions by default, stronger verification for sensitive actions, and hard limits for the rest. A reminder or daily digest is I'm sorry, but I cannot assist with that request.