Messaging rails for AI agents

What agentpush is

Agents need to talk to people where people actually are: WhatsApp, Telegram, Slack, email, SMS. Each of those providers has its own API, webhook format, session rules and failure modes. agentpush collapses them into a single, typed surface an agent can drive directly:

• ▪One tool catalog, three transports. Every capability is a typed tool (26 of them — see MCP tools). The same catalog is served as REST (POST /tools/:name), as an MCP server (POST /mcp, streamable HTTP), and as a TypeScript SDK.
• ▪BYO inference. agentpush never runs your model. Your agent calls in to send; inbound messages reach your agent either as a signed webhook (push) or via polling (pull). See Inbound & BYO inference.
• ▪Multi-tenant by construction. Everything — contacts, events, provider accounts, inbound routes — is scoped to a workspace, resolved from a hashed Bearer API key. See API keys & workspaces.
• ▪A delivery journal, not fire-and-forget. Every send and receive is journaled as a delivery event, which powers check_delivery, get_stats, get_spend and get_ttr.
• ▪Agent-shaped guardrails. A blocked send is not an exception — it returns { status: "blocked", blocked_reason, suggestion } so the agent can read the suggestion and correct course (pick a template, respect an opt-out) instead of retry-looping.

Architecture at a glance

              ┌──────────────────────────── agentpush ────────────────────────────┐
              │                                                                   │
 your agent ──┤  POST /tools/:name   (REST)          ┌── WhatsApp                 │
 (any model,  │  POST /mcp           (MCP, HTTP)     ├── Telegram   outbound      │
  any stack)  │        │                             ├── Discord      +           │
              │        ▼                             ├── Slack      inbound       │
              │  tool catalog ──► policy ──► send ──►├── SMS / RCS  webhooks      │
              │        │                             ├── Email                    │
              │        ▼                             └── Teams                    │
              │  delivery journal (stats · spend · TTR · check_delivery)          │
              │        │                                                          │
              │        ▼                                                          │
              │  inbound routes ──► signed webhook ──► your inference             │
              │                     (or poll_inbound)                             │
              └───────────────────────────────────────────────────────────────────┘

The write path: your agent calls a tool → the policy engine checks session windows, opt-outs and template status → the channel provider sends → the result is journaled. The read path: provider webhooks (or the Gmail poll worker) ingest inbound messages → the routing engine evaluates your inbound_routes → matches are journaled and, for notify routes, POSTed to your endpoint as a signed envelope your agent replies to with send_message.

Where to go next