An open-source Telegram AI agent still needs permission

Your Telegram AI agent can answer a message while you still have no clear rule for what it may do unattended. Kortix is the open-source CompanyOS: your agents, their skills, your company memory, and every connector in one git repo you own, with the agents working on real cloud computers. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.

That repository belongs to the company, not to the bot. It holds the agent's instructions, its skills, and the kortix.yaml that lists what the agent may use. A Telegram chat can carry a question and its answer in one tap. It cannot carry the grant that decides whether the answer becomes a customer email or a merge.

The allowed-user list admits people to the conversation

You can put an agent in Telegram in an afternoon. Message @BotFather, send /newbot, and copy the token. In Kortix, open Customize → Connectors, select the Channels scope, and select Connect on Telegram. Paste the bot token and the Telegram user ids you want to admit. Kortix stores the token on its server.

The Telegram channel instructions draw the identity line: “Telegram has no account link: the allowed-user list decides who may talk to the bot, and only an allowed person’s taps count.” Admission is not authority. The list says who may type at the bot. Connector policies govern its calls into a company system. A Telegram user id proves that someone controls that account, and nothing about their role in the company.

In a group, the bot reads only commands, replies to it and mentions. To let it read every message, send /setprivacy to @BotFather, or make the bot a group admin. One chat is one session, and in a forum group each topic is its own session. After /new, the next message starts a new session. A shared group needs a deliberate allowed-user list, because every member sees the bot's replies, including people who are not on it.

Question buttons collect answers

Release v0.14.16 on 3 November 2026 added the feature: “Answer agent questions with Telegram buttons, including several questions at once” (release notes). The agent asks with its question tool, and the chat renders one button per option.

The buttons have a precondition. Kortix posts a question with buttons only where the agent may send a Telegram message without approval. Where it may not, the agent asks in its own words, and that message waits for approval or is refused. A team that has tightened the Telegram send policy will see fewer buttons, not a broken bot.

One question shows one button per option. Several questions arrive in one message, in sequence, and the agent receives every answer after the last tap. That is a good way to collect a missing detail: which draft to send, or which recipient to use.

It is a poor way to record a company decision. A tap tells the agent which option the person prefers. It does not tell the connector policy that the send is allowed, and it does not tell the repository that the agent may merge. Those two questions are answered in files, by people with the authority to edit them.

The manifest separates grants from connector rules

The developers reference prints an example project. Its support agent lists two permissions, one of them git, and leaves merge out:

agents:
  support:
    description: Answers help desk tickets.
    mode: primary
    prompt_file: agents/support.md
    permission:
      bash:
        "*": allow
        "git push *": ask
    tools: all
    skills: [refund-policy, kortix-cli]
    subagents: [researcher]
    commands: all
    extensions: [web-access]
    connectors: [helpdesk]
    secrets: [HELPDESK_TOKEN]
    kortix_permissions: [project.session.read, project.gitops.push]
    workspace: { project_repository: true }

policy:
  default_mode: risk
policies:
  - match: "helpdesk.delete_*"
    action: block
  - match: gmail.send_email
    action: require_approval
    conditions:
      - arg: to
        match: "*@example.com" # a glob, or /regex/ in slashes
  - match: gmail.send_email
    action: block
approvals:
  ttl: 4h

The block is the reference's example, with the email rules from its connector section added. The support agent declares helpdesk as its connector, and the Gmail rules do not grant it Gmail. Read the two halves separately. kortix_permissions says what the agent may do to the project. policies says what happens when it calls a connector.

policy.default_mode starts at allow_all. Set it to risk and reads run while writes and deletes wait for approval. The delete rule blocks matching helpdesk calls outright. The email rules hold a send to the named recipient pattern and block the rest. First match wins, so the recipient condition has to sit above the blanket block.

Approval gates you set. Off until you set them. Nothing in a Telegram chat creates one; it exists only after someone writes it into the repository.

A held call waits in Review

A connector call that a policy holds does not wait in the Telegram chat. It waits on Kortix's Review page, as the item call:<id>. The Guide lists the ways to reach it: Review → Needs you, the approval link, or the approval card in a Slack or Teams thread. Telegram has no account link, so it has no approval card.

The decision belongs to a project manager or to whoever launched the session. Being on the allowed-user list does not put you in either group. That is the gap a button hides: the person who taps may be the one who launched the session, or may not, and the chat cannot tell you which.

Each approval authorizes a single call. Change an argument and the call needs a new decision. A held call lapses when nobody decides within 24h, unless the project configures a different window. approvals.ttl sets that window, and the example sets 4h. Assign a reviewer before the window closes, because an unanswered approval in Telegram leaves the connector call unresolved.

A chat answer cannot supply the missing merge grant

Say the agent proposes a change to a support skill. The conversation stays in its Telegram session. The change goes out as a change request, because agents land work that way by default. project.gitops.push lets the agent push and open the request. project.gitops.merge lets it merge.

The example agent has the first and not the second. A session cannot merge a change request it opened unless its grant in kortix.yaml includes project.gitops.merge; without it the merge returns 403 CR_SELF_MERGE_REFUSED. An agent that lists no kortix_permissions cannot merge at all. Typing “use that version” in the chat adds nothing to the file.

A project Manager holds all five git permissions, merge among them. Keeping the agent's list narrow and letting a manager merge is the ordinary arrangement. Our Slack grant explainer covers the same split between connecting a channel and granting authority. Telegram makes it sharper, because the chat cannot name the person behind the tap.

Budget for the bot, model, compute and review

A Telegram bot's cost has parts that are easy to conflate: the bot, the model that answers, the computer the agent runs on, and the person who reviews held calls. A bot token is free. It tells you nothing about the other three.

Kortix's pricing page, checked in November 2026, lists Free at $0, with 500 credits a month for a single project. That is an account allowance, not a statement about which model a Telegram chat may use. The channel documentation is narrower: a Telegram chat uses only models and provider keys that the whole project shares, never one person's key or subscription. A ChatGPT subscription on a personal account does not carry into the chat.

You can run the whole Kortix platform on a server you control. Sessions still run on cloud sandboxes, not on your server, so budget for those as well as the model. A hosted Telegram assistant is less work when the chat is personal and no company system is involved. For company work, add the reviewer's time to the total.

Start with one narrow task and one named reviewer. Choose the allowed Telegram ids, read the agent's grant list, and decide which connector calls must wait. Try Kortix when you want those rules to live with the work.