AgentSDK: Run Your Agent on One Platform

For years, Telnyx has been building the infrastructure that agents need to operate. Inference on owned GPUs, with open models catching up to frontier at a fraction of the cost. Speech-to-text and text-to-speech from the best engines in the world, hosted on our network. Voice AI Agent builders and orchestration that connect directly to the PSTN in over 140 countries on a global telephony layer that carries the calls. Last month we shipped Edge Compute, bringing the agent runtime onto the same platform so the code that orchestrates an agent lives next to the models it calls and the network it talks through.

Each piece works on its own, and each piece ships. What was missing was the thing that holds them together.

AgentSDK is that thing. It is the developer entry point to the entire platform, and it is available on Telnyx today.

The problem was never the framework

Every developer who has built an AI agent knows the wiring problem. You pick a framework for agent logic, then you wire up Redis for state, Celery or BullMQ for task queues, Postgres for message history, an inference provider for model calls, and a telephony API for phone and SMS. Each service you add brings its own network hop, its own credentials to manage, and its own failure domain that sits between your agent and the world it needs to reach.

The frameworks themselves are good at agent logic. LangGraph's node graphs and the Vercel AI SDK's streaming handle the reasoning well. What they do not handle is durable state, task queues, timers that survive restarts, or a platform that manages routing and serialization for you. You build and maintain all of that infrastructure yourself, one service at a time.

AgentSDK runs your framework unchanged and gives it everything else.

One platform, one subclass

AgentSDK is a TypeScript base class that ships inside @telnyx/edge-runtime. You subclass Agent instead of StatefulActor and bring your framework as-is, so the platform handles persistence, routing, serialization, and scheduling while your framework handles agent logic. Neither steps on the other.

import { Agent } from "@telnyx/edge-runtime";
import { createReactAgent } from "@langchain/langgraph/prebuilt";

const agent = createReactAgent({ llm, tools });

class SupportAgent extends Agent {
  async receive({ text, from, to }) {
    await this.setState({ from, to });
    await this.messages.add("user", text);
    await this.queue("process");
  }

  async process() {
    const history = await this.messages.toLangChain();
    const out = await agent.invoke({
      messages: [{ role: "system", content: "Helpful support agent." }, ...history],
    });
    const reply = String(out.messages.at(-1)?.content ?? "");
    await this.messages.add("assistant", reply);
    const { from, to } = await this.getState();
    await this.env.TELNYX.messages.send({ from: to, to: from, text: reply });
    await this.schedule(86400, "nudge", null, { id: "nudge" });
  }

  async nudge() {
    const last = await this.messages.last();
    if (last?.role !== "assistant") return;
    const { from, to } = await this.getState();
    await this.env.TELNYX.messages.send({ from: to, to: from, text: "Did you need anything else?" });
  }
}

Your LangGraph graph runs unchanged. The platform adds message tables, task queues, durable timers, and framework-shaped history behind the scenes, so your agent logic does not change. Lifecycle hooks like initialState, onTask, and onConnect let your agent react to events without manual wiring, so it boots with state, picks up queued work, and opens connections on demand.

What the platform gives your agent

The wiring problem exists because agent state, memory, and scheduling have always lived outside the framework, bolted on as external services that you stitch together and hope hold up in production. AgentSDK brings them inside the agent itself, and that changes what your agent can actually do.

Persistent message history stores every message your agent sends and receives in a structured table that is queryable by role, time, and topic, with one-call adapters for LangChain, OpenAI, and Anthropic formats that give your framework history in the shape it expects. Your agent can recall a conversation from three days ago without a database lookup, because the history belongs to the agent rather than to a session store you wired in.

Durable scheduled tasks give you timers that survive restarts, so you can schedule a follow-up nudge 24 hours out, queue a background task for processing, or run a recurring check every hour, and the actor wakes when the timer fires. Your agent can promise to do something later and actually follow through, because the timer lives in the platform instead of in a cron job you host on a separate server.

Merge-patch state gives your agent durable state on a single KV key with concurrent-update safety, so two handlers writing at the same time do not clobber each other. Your agent can hold a complex conversation across channels without losing track of where things stand, because its state persists across restarts rather than evaporating when the process cycles.

Real-time WebSocket communication gives your agent a live connection with clients, so streaming responses, tool-call updates, and state changes reach the user as they happen. Your agent can hold a bidirectional session with a browser or a real-time client the same way it talks to the platform, because the connection lives in the actor.

When the actor restarts, the state, history, and timers are all still there. They belong to the agent, not to a sidecar service you wired in, which means your agent fails less, picks up where it left off, and follows through on what it said it would do.

Everything the agent touches, on one platform

Your agent reaches the rest of the platform through bindings, which are zero-credential, zero-hop connections to Telnyx primitives. Voice makes and takes real phone calls on carrier infrastructure, with speech-to-text and text-to-speech from the engines we have been integrating for two years. Messaging sends and receives SMS, MMS, and WhatsApp globally. KV provides globally distributed key-value storage. CloudFS gives your agent a shared POSIX filesystem. Cloud Storage offers S3-compatible object storage for assets and artifacts. RAG embeds a bucket and auto-syncs, so your agent runs similarity search and retrieval in chat completions without a separate vector database.

Inference is not a binding, it is the platform itself. Your agent calls models that run on owned GPUs in the same facility as your code, so the request never traverses the public internet. The model is there, the agent is there, and the distance between them is a function call instead of a network hop.

These are not integrations in the usual sense. A binding is a platform-level connection with no credentials to manage and no network calls to configure, so the request never leaves the platform.

What changes when you build on AgentSDK

Less maintenance is part of the story. You stop wiring services together and start writing agent logic, you stop managing six configs and start managing one subclass. But the real payoff is what your agent can do when nothing stands between it and the platform it runs on.

Response times drop because there are no network hops between your agent's code, its state, and its model. Conversations hold together across sessions and channels because state and history persist in the actor. Follow-ups actually fire because timers survive restarts. Your agent can take a phone call, run inference, send a text, and write to storage in one turn, on one platform, without leaving it. That is the difference between an agent that demos well and an agent that holds up in production.

The infrastructure your agent runs on and the infrastructure your agent talks through are the same thing. That is the vision, and AgentSDK is how you get there.

What's next for AgentSDK

AgentSDK is in beta and the API surface may change before GA. The AgentClient browser SDK is in progress, with Operating Envelope for agent governance and cross-channel conversation memory planned next.

Read the docs to get started.