OpenAI has introduced a managed API for building AI agents that can work across longer sessions, use external tools, run code and coordinate specialized subagents.
The new Agents API does not include a native Telegram integration. Developers still need to connect it to Telegram’s Bot API and build the messaging layer themselves.
But it could change what those bots are capable of doing.
Instead of receiving one prompt and returning one model response, a Telegram bot could start a longer-running task, work across several tools and send the result back when it is finished. That moves the product closer to a persistent assistant than a conventional chatbot.
What OpenAI actually launched
The Agents API gives developers access to the agent harness used by Codex through an OpenAI-managed service.
According to the official Agents API documentation, OpenAI manages the agent’s sessions, orchestration, context compaction and recovery. Developers provide the instructions, connect the necessary tools and choose where execution takes place.
An agent can operate without a sandbox if it only needs to answer questions or call external functions. For tasks that involve files or code, it can use an OpenAI-hosted environment or a self-hosted environment controlled by the developer.
Inside an environment, an agent can:
- Execute code and commands.
- Read, create and edit files.
- Connect to MCP servers.
- Use developer-provided functions and external tools.
- Produce files and other artifacts.
- Delegate work to multiple subagents.
The API is currently in beta. OpenAI’s quickstart demonstrates an agent creating a script, running it inside a hosted sandbox and returning the result.
This is more infrastructure than a Telegram bot receives from a normal model call. The developer is no longer responsible for building every part of the agent loop, compressing long conversation history or recovering the agent’s working state manually.
Why this matters for Telegram bots
Most AI bots on Telegram still follow a familiar pattern: a user sends a message, the bot forwards it to a model API and the resulting text is returned to the chat.
That works well for questions, writing assistance, translation and media generation. It becomes harder when the user asks the bot to complete work involving several steps.
Consider a research bot asked to compare ten products and prepare a report. A basic chatbot may attempt to perform the entire task inside one response. An agent could divide the research between subagents, collect their findings, create a document and report back when the work is complete.
The same structure could support Telegram bots that:
- Review uploaded documents and generate a finished report.
- Investigate a technical problem using files and external tools.
- Monitor a workflow and return when an important change occurs.
- Analyze data, generate a spreadsheet and send it back to the chat.
- Coordinate specialized agents for research, writing and verification.
- Continue a project across several messages without rebuilding its context each time.
Telegram provides the conversation and notification interface. The Agents API supplies the managed agent runtime behind it.
This distinction matters. The AI is not running inside Telegram, and Telegram does not automatically gain access to OpenAI’s agent features. The bot acts as a bridge between the Telegram user and an agent session hosted elsewhere.
Sessions are the most useful part of the model
The Agents API is built around durable sessions rather than isolated requests.
A session keeps the agent’s configuration, conversation and saved work over time. Developers can send additional messages to the same session instead of starting again from an empty context. Turns can run asynchronously, while applications follow their progress through streaming events or receive status changes through webhooks.
OpenAI explains the session lifecycle in its guide to running and continuing agent sessions.
For a Telegram bot, a developer could associate each user, private chat or group topic with a particular agent session. When another message arrives, the bot would route it back to the same session.
That could make conversations feel more continuous. A user might start a research task from a phone, provide another file later and ask the agent to revise its output without repeating the original instructions.
The developer would still need to decide when sessions should be reused, separated or deleted. Automatically placing every conversation into one permanent session could mix unrelated work or retain context longer than users expect.
Telegram support is not included
Despite the potential, the Agents API is not a ready-made Telegram bot platform.
There is no official OpenAI package that receives Telegram updates, verifies users or converts agent events into Telegram messages. Developers must build that integration using Telegram’s Bot API or an existing framework.
The integration layer needs to handle:
- Incoming messages, commands and attachments.
- Mapping Telegram chats to OpenAI session identifiers.
- Converting Telegram files into inputs the agent can access.
- Streaming progress without flooding the conversation.
- Delivering final text, documents and other artifacts.
- Recovering from API, network or bot-delivery failures.
- Cancelling work when a user changes their mind.
- Separating users and group conversations securely.
Telegram already provides interfaces suited to AI products, including streamed replies, private-chat topics and structured messages. Its bot features documentation also describes AI agents as a native use case.
But those interface features do not replace the application logic between the two services.
This makes the Agents API different from Microsoft’s recently introduced Agent Framework channel package for Telegram, which includes a more direct adapter for translating Telegram updates into agent input. OpenAI provides the agent runtime; the Telegram bridge remains the developer’s responsibility.
Long-running tasks need a different user experience
Giving a bot a more capable backend does not automatically make it easier to use.
A task that takes several minutes cannot behave like an ordinary chat response. Users need to know whether the agent is still working, waiting for approval, requesting information or has failed.
Telegram makes progress updates possible, but sending every internal event would quickly overwhelm the chat. A better design might edit one status message, display only meaningful milestones and deliver the final result separately.
The bot also needs a clear way to stop a task. If an agent can browse, call tools or modify files, a simple /cancel command becomes more important than it is for a chatbot producing a single reply.
Approvals are another consideration. An agent reviewing information is different from one sending an email, changing a database or executing a transaction. Actions with external consequences should not be hidden behind a generic “working” indicator.
The most useful Telegram agents will probably expose less of their internal process while giving users more control over important decisions.
Privacy and cost require attention
Moving from single responses to persistent agents also changes the risk profile.
The Agents API retains session state so work can continue across turns. Its documentation states that the service currently supports data residency only in the United States and does not support Zero Data Retention. Using a self-hosted execution environment does not make the Agents API eligible for Zero Data Retention.
That is relevant for Telegram bots handling private documents, business conversations or customer data. Developers should explain what is sent to OpenAI, how long their own application retains Telegram messages and how a user can delete an agent session.
API credentials should also remain outside the agent’s sandbox. OpenAI’s quickstart explicitly advises developers not to place the application API key inside the environment where the agent works.
Costs can be less predictable than those of a one-response chatbot. OpenAI says model usage is billed at the selected model’s API rates, while hosted tools and sandbox containers carry their corresponding charges. A multi-step task involving subagents, web searches and code execution can consume more resources than a simple conversation.
Bot operators will need limits around task duration, tool usage and the number of parallel agents rather than relying only on message quotas.
What this means for Telegram AI tools
OpenAI’s Agents API does not create a finished Telegram assistant with one request. It solves a different problem: managing the runtime behind an agent that may work for longer, use tools and maintain state.
For Telegram developers, that removes some difficult infrastructure while leaving the product layer untouched. Authentication, chat design, permissions, notifications and safe delivery still need to be built around it.
The result could be a new class of Telegram bots that do more than expose a model inside a chat window. They could accept a task, work across tools and files, ask for input when necessary and return with a completed artifact.
Whether those bots are genuinely useful will depend less on how many agent features they advertise and more on how clearly they control them.
The Agents API supplies the machinery. Telegram supplies the interface. Developers still have to turn the two into a product users can understand and trust.
