fluid-telegram/TelegramCapabilityCanon.md

Telegram Capability Canon

Status: Draft v0.1
Date: 2026-09-03
Purpose: Canonical capability model for using Telegram as a messaging, publishing, community, application, commerce, and human/agent interaction platform.

---

1. Purpose

This canon provides a durable capability model for Telegram.

It is intentionally not organized around the Telegram user interface or a chronological list of product features. Instead, it describes Telegram as a set of reusable platform capabilities that can be mapped to concrete products, communities, businesses, automations, and agentic systems.

The primary questions are:

1. What capability does Telegram provide?
2. Which Telegram surface exposes it?
3. Can it be accessed or controlled programmatically?
4. Can a bot or autonomous agent participate?
5. What are the important operational, security, and commercial constraints?
6. When should Telegram be treated as the system of record, and when should it remain only an interaction surface?

The canon is designed to support projects such as telegram-edge, community platforms such as the Coulomb Society, agentic personalities, publishing systems, customer communication, and Telegram-based applications.

---

2. Platform Model

Telegram should be treated as six overlapping platforms:

Telegram
│
├── Messaging Platform
│   ├── person ↔ person
│   ├── person ↔ bot
│   ├── group interaction
│   └── voice / video
│
├── Publishing Platform
│   ├── channels
│   ├── stories
│   ├── public posts
│   └── live media
│
├── Community Platform
│   ├── groups
│   ├── topics
│   ├── channels
│   ├── communities
│   └── moderation
│
├── Application Platform
│   ├── bots
│   ├── mini apps
│   ├── identity
│   ├── payments
│   └── external integrations
│
├── Commerce / Business Platform
│   ├── business accounts
│   ├── customer communication
│   ├── payments
│   ├── subscriptions
│   ├── monetization
│   └── advertising
│
└── Human / Agent Interaction Platform
    ├── AI bots
    ├── streaming responses
    ├── guest bots
    ├── managed bots
    ├── bot-to-bot communication
    └── delegated business automation

These platforms share identity, messaging, discovery, media, permission, notification, and payment primitives.

---

3. Capability Levels

Each capability in this canon can be considered at five implementation levels.

Level	Meaning
L0 — Human UI	Available to a normal Telegram user through an official client.
L1 — Bot Accessible	A Telegram bot can participate using the Bot API.
L2 — Application Accessible	Mini Apps or external services can integrate with the capability.
L3 — Client/API Accessible	Full Telegram API / MTProto / TDLib clients can access or implement the capability.
L4 — Agentic	The capability is suitable for delegated or autonomous software-agent participation.

A capability may exist at more than one level.

---

4. Messaging Capabilities

MSG-01 — One-to-One Messaging

Telegram provides persistent cloud-based one-to-one conversations.

Functions

• text messages;
• replies;
• forwarding;
• message editing;
• message deletion;
• reactions;
• rich formatting;
• links;
• media;
• files;
• contacts;
• locations;
• voice messages;
• video messages;
• polls where supported;
• search;
• pinned content;
• scheduled messages;
• repeating scheduled messages.

Automation

Bots provide a first-class machine participant in private chats.

Agentic relevance

High.

A private bot conversation is one of the cleanest Telegram surfaces for:

• personal assistants;
• AI agents;
• workflow interaction;
• approvals;
• notification delivery;
• command interfaces;
• conversational applications.

Design note

Telegram should normally be treated as the interaction surface, not the sole persistent state store for sophisticated applications.

---

MSG-02 — Group Messaging

Telegram supports large multi-party conversations.

Functions

• persistent shared history;
• replies;
• mentions;
• reactions;
• member permissions;
• administrator roles;
• pinned messages;
• media and files;
• polls and quizzes;
• bots;
• topics;
• moderation;
• member tags;
• voice/video sessions;
• join requests;
• invite links.

Scale

Telegram groups can support very large communities, including supergroups with up to hundreds of thousands of members.

Agentic relevance

Very high.

Groups can host:

• moderator agents;
• research agents;
• question-answering agents;
• community managers;
• workflow bots;
• onboarding assistants;
• summarization agents;
• security and policy enforcement systems.

---

MSG-03 — Topics / Forum Conversations

Groups may be divided into topic-oriented threaded spaces.

Uses

• project discussions;
• support cases;
• subject-specific conversations;
• working groups;
• structured community areas;
• agent-specific work contexts.

Agentic relevance

High.

Topics provide a practical scope boundary for context and agent behavior.

---

MSG-04 — Ephemeral Bot Interaction

Telegram supports bot responses inside groups that are visible only to the invoking user.

Uses

• private AI summaries;
• account information;
• administrative actions;
• personal recommendations;
• sensitive workflow feedback without polluting the group timeline.

Agentic relevance

High.

This allows shared social spaces to contain private machine interactions without forcing users into a separate chat.

---

5. Media Capabilities

MED-01 — Rich Media Messaging

Telegram supports:

• images;
• video;
• animation;
• audio;
• voice notes;
• video notes;
• arbitrary documents;
• stickers;
• GIFs;
• live photos;
• maps and locations;
• albums and grouped media.

Bots can send and receive many of these media types.

---

MED-02 — Rich Messages

The 2026 Bot API adds structured rich messages.

Supported constructs include, among others:

• headings;
• paragraphs;
• lists;
• tables;
• quotations;
• expandable sections;
• code/preformatted content;
• mathematical expressions;
• media;
• documents;
• maps;
• audio;
• images;
• video;
• buttons;
• references.

Agentic relevance

Very high.

Rich messages substantially improve Telegram as an output surface for:

• research agents;
• reports;
• dashboards;
• comparisons;
• structured AI answers;
• approvals;
• operational summaries.

---

MED-03 — Live Response Streaming

Bots can stream text while a response is being generated.

Uses

• generative AI;
• search;
• analysis;
• long-running workflows;
• interactive research.

Agentic relevance

Core capability.

Streaming reduces the difference between a dedicated AI application and an AI service operating inside Telegram.

---

6. Publishing Capabilities

PUB-01 — Channels

Channels provide one-to-many publishing.

Characteristics

• potentially unlimited subscriber audience;
• public or private;
• administrator roles;
• persistent post history;
• rich media;
• polls;
• stories;
• comments through linked discussion groups;
• direct messages to channel operators;
• subscriber interaction;
• analytics/statistics;
• monetization capabilities.

Suitable for

• institutional publishing;
• news;
• product announcements;
• research publication;
• creator content;
• corporate communications.

Agentic relevance

High.

Agents can prepare, schedule, curate, moderate, and—in appropriately governed environments—publish content.

---

PUB-02 — Long-Form Rich Posts

Telegram's 2026 rich-text editor allows long structured content.

Capabilities include:

• headings;
• lists;
• tables;
• quotes;
• inline media;
• generated text;
• formulas.

Messages can extend substantially beyond conventional chat-message length.

Consequence

Telegram increasingly overlaps with lightweight:

• blogging;
• newsletters;
• documentation;
• knowledge publishing.

---

PUB-03 — Stories

Telegram supports temporary story-style publishing.

Possible uses include:

• announcements;
• event coverage;
• informal updates;
• creator communication;
• live experiences.

---

PUB-04 — Public Discovery

Public Telegram content can be discoverable through platform search.

Relevant entities include:

• users;
• channels;
• groups;
• bots;
• public posts.

Strategic implication

Telegram is not only a subscribed-content medium. It increasingly provides content discovery.

---

7. Community Capabilities

COM-01 — Community Composition

Telegram introduced Communities as a mechanism for linking several:

• groups;
• channels;
• bots.

Members can access associated spaces through a coherent community entry.

Importance

This creates an explicit organizational layer above individual chats.

A conceptual model is:

Community
├── announcement channel
├── general group
├── specialist groups
├── project groups
├── event group
├── service bot
└── community agent

Agentic relevance

Very high.

Communities create natural scopes for:

• agent permissions;
• institutional identity;
• moderation;
• workflows;
• specialized service agents.

---

COM-02 — Membership Management

Telegram provides:

• private/public spaces;
• invite links;
• join requests;
• member permissions;
• administrator permissions;
• ownership;
• member removal;
• restrictions;
• approval workflows.

---

COM-03 — Moderation

Native and bot-based moderation can include:

• delete messages;
• restrict members;
• ban members;
• approve join requests;
• control media permissions;
• manage topics;
• manage tags;
• enforce community rules.

Telegram has increasingly added AI-related moderation capabilities.

Architecture rule

High-impact moderation should not depend solely on probabilistic model behavior.

Recommended structure:

AI assessment
      ↓
policy decision
      ↓
deterministic enforcement layer
      ↓
Telegram API action

---

COM-04 — Polls, Quizzes and Collective Decisions

Telegram polls provide lightweight collective interaction.

Uses:

• community decisions;
• surveys;
• event planning;
• knowledge quizzes;
• feedback;
• agent-generated voting proposals.

---

8. Bot Platform

BOT-01 — Bot Identity

Bots are first-class Telegram accounts designed for software.

They:

• have usernames;
• have profiles;
• can receive messages;
• can send messages;
• can belong to groups;
• can administer groups/channels if authorized;
• do not require a phone number for normal bot creation.

Bots execute application logic outside Telegram and communicate through Telegram APIs.

---

BOT-02 — Commands

Bots may expose commands such as:

/start
/help
/search
/status
/approve

Commands can vary by chat context and user scope.

---

BOT-03 — Interactive Keyboards

Bots support:

• reply keyboards;
• inline keyboards;
• callback buttons;
• links;
• selectors;
• menus.

These allow chat messages to behave like lightweight application interfaces.

---

BOT-04 — Inline Bots

Bots can be invoked from the message field of other chats.

Conceptually:

@agent query

This makes a service available without requiring users to leave their current conversation.

---

BOT-05 — Deep Linking

Links can open:

• bots;
• specific bot states;
• Mini Apps;
• group invitations;
• channels;
• other Telegram resources.

Deep links enable Telegram to participate in external application workflows.

---

BOT-06 — Guest Bots

Guest bots can answer invocations in chats even when they are not permanent members of those chats.

Agentic relevance

This enables a useful pattern:

conversation
   ↓
invoke specialist agent
   ↓
temporary context access
   ↓
result

This reduces the need to permanently install every specialist bot into every group.

---

BOT-07 — Managed Bots

Telegram supports programmatic creation and management of subordinate bots.

Agentic relevance

Extremely high.

Managed bots enable hierarchical agent architectures:

Agent Manager
├── Research Bot
├── Publishing Bot
├── Moderation Bot
├── Event Bot
└── Support Bot

A management system can create and administer specialized Telegram identities dynamically.

---

BOT-08 — Bot-to-Bot Communication

Telegram supports direct coordination between bots.

Consequence

Telegram can serve not only as a human-agent interaction surface but also as part of an agent communication topology.

This should not automatically make Telegram the internal agent message bus; dedicated infrastructure may be more appropriate for high-volume or security-sensitive coordination.

---

BOT-09 — Business Bots

Business accounts may delegate selected messaging capabilities to bots.

Uses

• customer support;
• lead qualification;
• automated responses;
• workflow initiation;
• CRM integration;
• booking;
• commerce.

Governance requirement

Delegated permissions should be explicit and minimal.

---

9. Mini App Platform

APP-01 — Embedded Web Applications

Telegram Mini Apps are HTML/JavaScript applications displayed inside Telegram.

Telegram describes them as capable of replacing conventional websites for many workflows.

Capabilities

• arbitrary web UI;
• Telegram identity;
• contextual launch;
• local/device storage;
• server integration;
• payment flows;
• push notifications;
• Telegram-aware navigation.

---

APP-02 — Application Authentication

Mini Apps receive authenticated Telegram context.

Suitable for

• personalized dashboards;
• account management;
• member portals;
• approvals;
• settings;
• workflow applications.

Security rule

Telegram identity should usually be mapped to an internal canonical identity rather than used as the only authorization model.

Telegram identity
       ↓
identity mapping
       ↓
internal subject
       ↓
policy / authorization

---

APP-03 — Application UX Extension

Use a Mini App when chat interaction becomes awkward.

Typical threshold:

conversation     → Bot
simple choice    → Buttons
structured form  → Mini App
complex workflow → Mini App / external application

---

10. Identity Capabilities

ID-01 — Telegram User Identity

Telegram provides stable platform identities associated with accounts.

Relevant properties may include:

• user ID;
• username;
• profile;
• display name;
• phone-number relationship where authorized.

Design rule

Do not treat usernames as immutable identifiers.

Use Telegram's numeric IDs for machine identity mapping.

---

ID-02 — Login with Telegram

External applications can authenticate users through Telegram.

Suitable for:

• community portals;
• companion websites;
• membership applications;
• linked services.

---

ID-03 — Privacy-Preserving Contact

Users can communicate without revealing their telephone number, depending on privacy configuration.

This is important for public communities and creator/follower relationships.

---

11. Business Capabilities

BUS-01 — Business Profiles

Telegram Business accounts can expose:

• opening hours;
• business location;
• customized start page;
• quick replies;
• greeting messages;
• away messages.

---

BUS-02 — Automated Customer Conversations

Bots can be attached to business communication.

Possible architecture:

Customer
   ↓
Telegram
   ↓
Business Bot
   ↓
CRM / workflow / agent
   ↓
Business policy
   ↓
response

---

BUS-03 — Direct Customer Interaction

Telegram can function as:

• support channel;
• sales channel;
• account-management channel;
• notification channel;
• service-delivery channel.

---

12. Commerce and Monetization

PAY-01 — Payments

Bots and Mini Apps can support payment flows.

Depending on transaction type and Telegram rules, payment mechanisms may involve:

• external payment providers;
• platform-native payment mechanisms;
• Telegram Stars.

---

PAY-02 — Digital Goods

Telegram Stars provide Telegram-native payment functionality for digital goods and services.

---

PAY-03 — Paid Content

Possible models include:

• paid media;
• paid channel access;
• paid subscriptions;
• premium services;
• creator monetization.

---

PAY-04 — Sponsored / Suggested Content

Telegram provides mechanisms through which channels and creators can monetize audience reach.

This can include:

• sponsored content;
• suggested posts;
• advertising revenue models;
• affiliate-style mechanisms.

---

13. Voice, Video and Live Interaction

RTC-01 — Voice Calls

Telegram supports individual voice calling.

---

RTC-02 — Video Calls

Telegram supports individual video calling and screen sharing.

---

RTC-03 — Group Calls

Groups can host interactive voice/video sessions.

Suitable for:

• community meetings;
• office hours;
• events;
• discussions;
• presentations.

---

RTC-04 — Live Streaming

Channels and other Telegram surfaces can support live broadcast-style interaction.

---

14. Notification Capabilities

NOT-01 — Push Notifications

Telegram provides cross-platform push delivery through its clients.

This makes Telegram useful as a notification edge for external systems.

Examples:

monitoring alert
build result
approval required
event reminder
community announcement
agent completion
security notification

---

NOT-02 — User-Controlled Notification Policy

Users retain significant control over notification behavior.

Therefore:

Telegram delivery does not guarantee user attention.

Applications requiring guaranteed acknowledgement should implement acknowledgement state externally.

---

15. Integration Surfaces

Telegram exposes several distinct integration surfaces.

INT-01 — Bot API

HTTP API intended for bot applications.

Best suited for:

• chatbots;
• automation;
• notifications;
• community tools;
• agent interfaces;
• lightweight applications.

---

INT-02 — Mini App API

JavaScript APIs for applications embedded inside Telegram.

Best suited for:

• forms;
• dashboards;
• account portals;
• commerce;
• complex interactions.

---

INT-03 — Telegram API / MTProto

Provides lower-level access to Telegram's client capabilities.

Best suited for:

• custom clients;
• advanced integration;
• capabilities unavailable through the Bot API.

This surface requires considerably more care than ordinary bot development.

---

INT-04 — TDLib

Telegram Database Library provides an abstraction for building complete Telegram clients.

Suitable for:

• embedded Telegram clients;
• specialized Telegram applications;
• advanced automation requiring real user/client capabilities.

---

INT-05 — Web Login

Telegram can provide identity/authentication to external web systems.

---

16. Agentic Capability Model

Telegram's 2026 feature set makes it useful to explicitly distinguish five agent roles.

AGT-01 — Conversational Agent

Human ↔ Agent

Examples:

• assistant;
• advisor;
• support bot;
• knowledge agent.

---

AGT-02 — Group Participant Agent

Human
Human
Agent
Human

The agent participates in a shared social context.

Examples:

• community manager;
• moderator;
• researcher;
• facilitator.

---

AGT-03 — Guest Specialist Agent

Group
  ↓
invoke specialist
  ↓
Guest Bot

The agent enters the interaction only when needed.

---

AGT-04 — Delegated Operator Agent

Human owner
    ↓ authority
Agent
    ↓
Telegram resources

The agent may:

• answer messages;
• moderate;
• publish;
• manage workflows.

This requires explicit policy boundaries.

---

AGT-05 — Multi-Agent System

Coordinator
├── Research Agent
├── Publishing Agent
├── Moderator
├── Concierge
└── Operations Agent

Telegram now contains primitives supporting bot-to-bot communication and managed bots.

Telegram can therefore expose a multi-agent system directly to users.

---

17. Security Model

SEC-01 — Cloud Chats

Ordinary Telegram cloud chats are encrypted in transit/client-server architecture but are not end-to-end encrypted in the same way as Secret Chats.

This distinction is important for security-sensitive systems.

---

SEC-02 — Secret Chats

Secret Chats provide device-specific end-to-end encrypted communication.

They are fundamentally different from cloud chats and have different automation properties.

Agentic limitation

Secret Chats are not a general-purpose bot interaction environment.

---

SEC-03 — Account Security

Telegram supports mechanisms such as:

• two-step verification;
• passkeys;
• device/session management;
• local application locks;
• privacy controls.

---

SEC-04 — Bot Credentials

Bot API tokens are security credentials.

Treat them as secrets.

Required controls should include:

• secret manager storage;
• rotation;
• least access;
• audit;
• environment isolation;
• revocation procedures.

Never embed production bot tokens in source code.

---

18. Governance Rules for Agentic Telegram Systems

Telegram permits significant automation, but platform capability should not be confused with governance.

Recommended architecture:

                 Agent / LLM
                     │
                     ▼
               proposed action
                     │
                     ▼
            deterministic policy
                     │
              ┌──────┴──────┐
              │             │
           denied         allowed
                            │
                            ▼
                     Telegram Adapter
                            │
                            ▼
                         Telegram

Core principles

G-01 — Deterministic authority

Permissions, credential scope, and irreversible operations should be enforced by deterministic systems.

G-02 — Least privilege

Each bot or agent should receive only the Telegram permissions required for its role.

G-03 — Separation of identities

Prefer distinct bot identities for materially different responsibilities.

G-04 — External source of truth

Important operational state should normally be persisted outside Telegram.

G-05 — Auditability

Agent-initiated actions should carry sufficient metadata to reconstruct:

• who initiated the action;
• which agent executed it;
• which policy authorized it;
• what Telegram action occurred;
• what result was returned.

G-06 — Bounded autonomy

Autonomous agents should have explicit limits for:

• publishing;
• deleting;
• banning;
• payment operations;
• membership changes;
• credential management.

---

19. Telegram as an Edge Architecture

For sophisticated systems, Telegram is best modeled as an interaction edge.

                Telegram
                   │
            telegram-edge
                   │
       ┌───────────┼───────────┐
       │           │           │
    Identity    Workflow     Agents
       │           │           │
       └───────────┼───────────┘
                   │
              Core Systems

telegram-edge should normally own:

• webhook/API integration;
• Telegram identity mapping;
• Telegram entity mapping;
• message normalization;
• outbound rendering;
• Telegram permission translation;
• retry handling;
• rate-limit handling;
• audit correlation;
• attachment handling;
• deep links;
• Mini App launch integration.

It should not become the canonical store for business logic that belongs elsewhere.

---

20. Canonical Telegram Entity Model

A useful normalized model is:

TelegramPlatform
│
├── User
├── Bot
│
├── Chat
│   ├── PrivateChat
│   ├── Group
│   │   └── Topic
│   └── Channel
│
├── Community
│   └── Chat references
│
├── Message
│   ├── Content
│   ├── Media
│   ├── RichMessage
│   └── Interaction
│
├── MiniApp
│
├── Call / LiveSession
│
├── Payment
│
└── Membership / Permission

---

21. Capability Selection Guide

Requirement	Preferred Telegram Primitive
Private conversation	Private chat
Announcement publishing	Channel
Open discussion	Group
Structured discussion	Group + Topics
Multi-space institution	Community
Interactive automation	Bot
AI assistant	Bot + streaming/rich messages
Specialist invoked anywhere	Guest Bot / Inline Bot
Complex interface	Mini App
Customer automation	Business Bot
Event/live discussion	Group Call / Live Stream
Payments	Bot / Mini App + payment capability
Human + multiple agents	Community + Bots
External authentication	Login with Telegram
Full custom Telegram client	TDLib / Telegram API

---

22. Coulomb Society Reference Pattern

A possible Telegram-native structure for the Coulomb Society is:

Coulomb Society Community
│
├── Coulomb Society Channel
│   └── official publishing
│
├── Society Commons
│   └── general discussion
│
├── Research Forum
│   ├── Physics
│   ├── Technology
│   ├── Arts
│   └── Philosophy
│
├── Events
│   └── meetings / lectures / live sessions
│
├── Charles-Augustin de Coulomb Sp.
│   └── community manager / concierge
│
├── Research Agents
│   └── specialist guest bots
│
└── Society Mini App
    ├── membership
    ├── profile
    ├── events
    ├── projects
    └── contribution workflows

The important architectural distinction is:

The Society exists independently of Telegram; Telegram is the primary social and communication surface through which the Society is experienced.

This keeps future federation or expansion to other surfaces possible.

---

23. Capability Maturity Model

For platform planning, capabilities can be scored:

Stage	Description
T0 — Manual	Humans operate Telegram manually.
T1 — Assisted	Bots provide commands and notifications.
T2 — Integrated	Telegram is connected to external services.
T3 — Workflow	Business/community workflows execute through Telegram.
T4 — Agent Assisted	Agents prepare actions; humans approve.
T5 — Bounded Autonomous	Agents execute within deterministic policy boundaries.
T6 — Adaptive Multi-Agent	Multiple specialized agents coordinate while governance remains deterministic.

The goal should generally not be maximum maturity everywhere.

Each capability should advance only as far as its risk, value, observability, and reversibility justify.

---

24. Telegram Strengths

Telegram is particularly strong where a system needs several of the following simultaneously:

• human messaging;
• public publishing;
• large communities;
• notifications;
• programmable bots;
• embedded applications;
• identity;
• payments;
• media;
• AI interaction;
• mobile and desktop availability;
• low-friction onboarding.

This combination is unusual.

---

25. Telegram Weaknesses and Boundaries

Telegram should not automatically be used as:

• a canonical enterprise database;
• a high-assurance authorization system;
• a durable workflow engine;
• a general event bus;
• a secret-management system;
• a regulated document archive;
• a guaranteed-delivery notification system;
• an internal high-volume agent coordination backbone.

These responsibilities normally belong to external infrastructure.

Telegram should expose them through interaction adapters.

---

26. Strategic Interpretation

Telegram can be understood as:

A globally deployed interaction runtime combining identity, messaging, publishing, communities, applications, payments, and increasingly first-class human/agent collaboration.

Its strategic value is therefore larger than its conventional classification as a messaging application suggests.

For agent-active systems, the most significant capabilities are increasingly:

identity
+ conversation
+ community context
+ rich output
+ streaming
+ embedded applications
+ delegated bots
+ guest agents
+ bot-to-bot communication
+ deterministic external governance

Together these allow Telegram to become a practical social edge for agentic systems.

---

27. Reference Architecture Principle

The canonical integration rule for systems built around Telegram should be:

Telegram owns interaction. The application owns truth. The policy layer owns authority. Agents own bounded interpretation and action.

Expressed architecturally:

Telegram
   │
   ▼
Interaction Edge
   │
   ▼
Identity / Context
   │
   ▼
Agent or Application
   │
   ▼
Deterministic Policy
   │
   ▼
Domain Systems

This separation enables sophisticated Telegram-native experiences without making the security, consistency, or longevity of the system dependent on Telegram itself.

---

28. Sources

Primary Telegram documentation consulted for this version:

1. Telegram Bot Platform — Introduction
   https://core.telegram.org/bots

2. Telegram Bot Features
   https://core.telegram.org/bots/features

3. Telegram Bot API
   https://core.telegram.org/bots/api

4. Telegram Bot API Changelog
   https://core.telegram.org/bots/api-changelog

5. Telegram Mini Apps
   https://core.telegram.org/bots/webapps

6. Telegram API — Bots
   https://core.telegram.org/api/bots

7. Telegram AI Features for Bots
   https://core.telegram.org/api/bots/ai

8. Telegram Blog — Communities and Rich Text, July 2026
   https://telegram.org/blog/communities-editor-invisible-messages

9. Telegram Business
   https://telegram.org/blog/telegram-business

---

29. Canon Maintenance

Telegram evolves quickly.

This document should therefore distinguish:

• canonical concepts, which should remain stable;
• Telegram implementations, which may change;
• limits and commercial terms, which should be periodically revalidated.

Recommended update triggers:

• major Bot API releases;
• new identity or authorization models;
• new community abstractions;
• changes to payment rules;
• significant agent/AI capabilities;
• material changes to API limits;
• changes affecting privacy or security architecture.

---

End of Telegram Capability Canon v0.1