Telegram channel: a thread sends you a result when you ask, and you answer from the chat

[leorivastech]

This is not a notification system. I have read "notifications are an anti-pattern" and I am not asking to be pinged when something happens. Nothing here fires on its own. The agent sends something only when you tell it to ("send me the report on Telegram when you finish"), and what arrives is the result itself, a file or a message you can act on, not an alert that pulls you back into the app.

Why

At work we use Telegram for everything. When an agent produces something worth showing, a PDF, a chart, a short video, I open T3 Code, find the file and forward it by hand. And when someone answers "ok, now change X", I go back to the app to type it. The chat is already where the conversation is.

What I have working on my fork

It is built, tested, and running on my machine. Set up once in Settings → Integrations → Telegram with your own bot from BotFather:

• Send. One MCP tool, telegram_send: text, or a file that already exists. Images and MP4 show inline, anything else arrives as a document.

  

• Answer. Reply to any message the bot sent and your text becomes a new turn in the thread that sent it, even if that thread was idle.

  

• Pick a thread. /threads lists the open threads, one message each. Reply to the one you want.

  

• Groups can receive. Add the bot to a group, add the id it posts to Settings, and ask for it by name: "send it to the team group". This part is written and covered by tests; I have not tried it against a real group yet.

95-second recording. The settings step is stills from a test build; the rest is a real-time screen recording:

t3-telegram-demo-small.mp4

What I left out on purpose

• Anything automatic. No "turn finished" messages, no mirroring of answers. If that is ever wanted it should be opt-in and a separate decision.
• Voice. No Whisper for incoming voice notes and no TTS for answers. Both are easy to bolt on, but they need an API key or a decent GPU, and I wanted this to work for anyone running T3 Code locally.
• Answers from groups. A reply becomes a prompt for an agent that can run commands on the machine, so only the people you list can answer, and only from their private chat with the bot.
• Making the files. The channel sends what exists. Producing the PDF or the video is the agent's job.

How far this could go

Not part of this proposal, only where the same shape leads:

• Slack or Teams: the same two halves, a send tool and "a reply goes back to its thread".
• Answering from a group or a topic, limited to the listed people.
• Voice in and out, for those who have the hardware or a key.

How it fits the codebase

One server service (long polling, so nothing has to be reachable from outside), one MCP toolkit, one settings section, one small table in the existing SQLite. The bot token lives in the secret store, like the Bitbucket tokens. A thread sends files from its own workspace; only a full-access thread can send a file from elsewhere on the machine. Mobile needs no new screen. Focused tests and a user guide are written.

What I would like to know

1. Is this a direction you would take at all?
2. If yes: the whole thing, or only the sending half first, with replies as a follow-up?
3. Anything you would want shaped differently before I open a PR?

Related: #7046 (completion notifications) and #6933 (outbound completion webhook) are about being told that something happened. This is about getting the result where the conversation already is.

[alimek]

This is close to something I want, so I'd like to build on it rather than open a competing proposal. I agree with what you left out: no automatic messages and no mirroring.

My use case is one step further. I want to message a bot normally, not reply to something it sent, and have that land in one long-lived home thread. The home thread runs a model I chose and has the orchestrator MCP tools, so it can start and steer other threads (t3_thread_launch, t3_thread_send, t3_thread_wait). Someone in #16801 asked for the same thing ("start a thread like openclaw or hermes from telegram").

That needs a small addition to your design, and it raises a question about shape: should this be Telegram-specific, or the first driver behind a small channel abstraction?

Suggestion: drivers and instances, like providers

T3 already separates ProviderDriverKind from ProviderInstanceId, so one driver can have several configured instances. Channels could work the same way:

• Driver: telegram first. Later discord, slack, signal.
• Instance: a configured bot. Settings → Integrations shows a list of bots, not one Telegram section, so you can have a work bot and a personal bot, or two bots of the same type.

Every driver connects outbound, so nothing has to be reachable from outside, which keeps your long-polling property: Telegram getUpdates, Discord Gateway, Slack Socket Mode, signal-cli daemon.

The driver contract stays small. Platform details stay in the driver, and the core only sees normalized messages:

interface ChannelDriver {
  kind: ChannelDriverKind
  capabilities: { threads: boolean; files: boolean; maxTextLength: number }
  probe(config, secret): Effect<{ botName: string }>
  connect(config, secret): Stream<InboundMessage>
  send(target: ConversationRef, message: OutboundMessage): Effect<MessageRef>
  createThread?(parent: ConversationRef, title: string): Effect<ConversationRef>
}

Everything else is shared and written once:

• Allowed senders per instance, checked before anything reaches an agent. Groups receive only. Same rule as yours.
• Routing through one bindings table (instance + conversation/platform thread ↔ T3 thread):
  1. A reply to a bot message goes to the thread that sent it (your current behavior).
  2. A message in a platform thread or topic bound to a T3 thread goes to that thread.
  3. Anything else goes to the instance's home thread, if one is set. If none is set, keep today's behavior.
• One MCP tool, channel_send, instead of one tool per platform.
• Inbound messages start turns through an orchestration command, as scheduled tasks do, so idle threads whose provider session was released still wake (Process externally queued Codex messages without opening the T3 thread #12448).

On platforms with threads (Discord, Slack, Telegram topics), a T3 thread started from the home thread can get its own platform thread. Each piece of work then has its own place in the chat.

Scope

To keep this small, the first PR would add only the Telegram driver behind the contract: essentially your implementation, reshaped, plus the instance list and the home-thread setting. Discord would come later as the second driver. It would test whether the abstraction holds, and I'd rather find that out than design for it ahead of time.

Still out of scope: automatic notifications, voice, and answering from groups.

Questions

• @leorivastech, are you open to reshaping your fork this way? I'm happy to help with the work, or to take the home-thread part on top of yours.
• Maintainers: is a driver/instance channel abstraction an acceptable direction and scope, or would you prefer Telegram-only first and generalizing later?