Telepath

Correspondence is working memory: the agreements, the files and the voice notes that never made it into any system. An assistant sees mail, tasks and code — and precisely not this.

The ready-made ways to give it access ask for a user session, which is the key to the whole account. For working correspondence that is not an option, and offering it to other people even less so.

• the official way

  the Telegram Business API and a bot the person adds to their own account

  which also means that API’s limits — other people’s chats stay out of reach

• separation

  one archive per account, physically its own

• more than reading

  attachments, photos and voice — otherwise the assistant sees fragments of a conversation

• any client

  one archive and a standard MCP endpoint instead of an integration per vendor

The person adds the bot to their Telegram Business and picks which chats it sees. From then on new messages arrive by webhook, land in that account’s archive and become available to whichever assistant the owner authorised.

Attachments do not stay as file identifiers: text is pulled out of documents and spreadsheets, photos are handed over as images, voice notes as transcripts. Otherwise a search finds the word “contract” but not what the contract says.

• search

  full-text across every conversation, captions and transcripts included

• a thread

  the history of one chat, not just the last few messages

• attachments

  PDFs, spreadsheets and documents by their content, not their file name

• voice

  transcripts of voice notes and round videos

• replying

  sending, editing and reactions as the owner, if they switched it on

• the past

  import of a Telegram Desktop export: the bot only sees what came after it was connected

Authorisation turned out to be a project of its own. The client registers itself, by the standard, with no keys handed out in advance; the person proves who they are with Telegram; the token that comes back belongs to that account and is checked against its audience on every request.

identity

Telegram Login — the messenger vouches for the person, there is no password

protocol

OAuth 2.1 with PKCE and dynamic client registration

binding

a token works for one account and is checked against its audience

scope

a client granted read-only never sees the tools that send

The archive is not tied to one assistant: the owner picks the client, the correspondence stays the same.

• Claude

  published in the connector directory

• ChatGPT

  submitted to the catalogue, in review

• Grok

  connects as a custom connector; a PR is open to the catalogue of their terminal agent

• agents and CLI

  the standard remote MCP endpoint — no separate integration needed

A whole product: from somebody else’s API and a storage schema to sign-in, a landing page, documentation and a line in a major platform’s catalogue.

There is no end-to-end encryption here, and we do not pretend otherwise: to search and transcribe, the server processes messages, which means it technically can read them. What is done about it: archives are separated per account, the server’s disk is encrypted whole, and a command in the bot erases everything we hold. Anyone who needs a guarantee that no operator will ever read a line runs the same code on their own machine, single-tenant.