Skip to main content
An agent runs on Edge Compute as two things: a function and a stateful actor type. The function is the entry point; it owns the public address and the webhooks. The actor type is the agent; the class behind it runs every conversation, one instance per conversation. Declared in configuration or implemented in code, every agent is deployed this way, and nothing is sized or kept running by the user.

​
One Project, One Function

deploy registers one function named after the agent and ships the agent as its actor type. The function answers at https://<name>-<function id, first 10 characters>.telnyxcompute.com; the agent is mounted under it at /agents/<name>/<conversation>, and the function’s webhooks are where calls and texts arrive. The first deploy builds the function, which typically takes about ten minutes; every deploy after that is a new revision, covered under versions.

​
One Conversation, One Instance

A conversation is one instance of the actor type, named by the last segment of its address. The platform places an instance on first touch, in whichever container of the agent’s code has room, keeps it warm while it is busy, evicts it when idle, and may relocate it; its message log, state and scheduled tasks are written to storage before a call returns, so an instance that moves or restarts resumes where it left off. Calls to one instance run one at a time; instances run in parallel. The model is called through the function’s binding to the Telnyx inference endpoint, and Agent Memory, messaging and Call Control are reached the same way, with the account’s credential and no key in the code. A third-party model (openai/*, anthropic/*, google/*, groq/*) needs your provider key as a secret, OPENAI_API_KEY for example. The Abstraction Model that follows takes each of these apart.

​
Runtime Platform Characteristics

Framework agnostic. The runtime can accommodate any framework, or none at all. The user only needs to write glue code against the runtime SDK. Model flexibility. The runtime supports BYOK for third-party hosted models and natively hosted open-weight frontier models. Conversation isolation. Each conversation is its own instance of the agent, with its own state and one call at a time; compute is shared per agent, as Isolation describes. Persistence across invocations. Conversation state survives instance eviction. Background tasks. Work queued or scheduled on a conversation runs after the request returns, is retried on failure, and survives restarts. Protocol support. Every conversation of a configuration agent answers at one address over three transports: WebSocket, Server-Sent Events and RPC. A code-based class serves what it implements. Voice native. STT and TTS models are natively hosted and supported. The user does not need to stitch together third-party providers for voice agents.