Keep Telegram Evidence Separate from CRM Notes and Summaries

Use Telegram messages as evidence of what was said, AI summaries as interpretations, and CRM notes as your maintained record of checked facts and decisions. A plausible summary is not a customer approval. A saved note is not proof that its wording is supported by the conversation.

Chiho supplies authorized existing Telegram account conversations to an AI client, such as Codex, Claude or ChatGPT. A Telegram bot or Claude Channel carrying instructions to a running agent serves a different purpose; that connection alone does not establish access to your personal conversation archive. Check account identity, permissions, actual history coverage and the available tools.

Updated 4 November 2026. Chiho publishes this guide; Chris is its author. Product behavior was checked against current source and documentation, not exercised in a live customer account. The example and prompts below are synthetic evaluation material, with no accuracy or productivity results. The existing header image provides general interface context, not a screenshot of this exercise.

Start with the source, then inspect the summary

First establish the account, personal or team scope, conversation and retrieval boundary. Use the Chiho MCP setup page for installation and browser authorization, and the Telegram MCP architecture guide to check what the connection supplies. Confirm identity with auth_status and account_whoami before a bounded chat_read or search_messages request. Use identifiers returned by the tools rather than guessing from a display name.

For each consequential statement, keep an account/chat/message locator, timestamp with timezone, original excerpt and relevant surrounding context. These are suggested evidence labels, not dedicated Chiho fields. Check later corrections and conditions: a message proves that a participant said something, not that the underlying assertion is true or remains current. If older history was not retrieved, record the gap rather than treating it as absent.

summary_show reads the stored summary and exposes an update time and last-summarized-message marker when available. It does not itself retrieve fresh message evidence. An update timestamp or marker helps orient a check; neither proves that every relevant message was considered. For the separate summarization workflow, see summarize Telegram chats with AI.

Keep three kinds of statement in a working note

A useful note lets another authorized reviewer distinguish these parts:

• Evidence: an exact excerpt with its locator and conditions, plus what remains unchecked.
• Interpretation: the AI or reviewer's assessment, explicitly labeled as an inference. Do not silently replace the customer's wording with it.
• Decision: the team's chosen next action, responsible person and review trigger. State whether the customer has confirmed it.

Keep source references accessible only to people entitled to read the conversation. Copy the minimum necessary context. A person's name inside a note does not create an assigned task or send a notification. Task creation and outbound messaging have their own outcomes to verify.

For example, an internal decision to ask for a revised date is compatible with an unconfirmed customer proposal. Label it as an internal decision; do not turn it into “the customer agreed.” Use finding changed customer commitments when the uncertainty concerns which agreement is current.

Correct a superseded note without losing the reason

This fictional source packet uses English originals in every translation of the guide so the evidence can be compared unchanged. No messages were retrieved or written for this exercise.

Fixture: DEMO-NOTES / account A / chat C
Message 101 | 2026-10-13 09:00 Asia/Singapore
"Friday could work if security approves."
Message 102 | 2026-10-14 11:00 Asia/Singapore
"Security still has questions. Please hold scheduling."
Hypothetical summary: "The customer approved Friday."
Old note: "Friday confirmed; schedule the pilot."

The summary and old note both exceed the evidence. The proposal was conditional, and the later source asks for a hold. Refreshing the summary may change its wording, but is not the acceptance test. The current note and intended action must agree with the verified source.

A reviewer could replace the old instruction with:

Evidence: Friday was conditional; the later message asks us to hold scheduling. Interpretation: the date is unconfirmed. Decision: Maya will ask whether security's questions are resolved before proposing a date. Superseded: the earlier “Friday confirmed” note was unsupported. Review when the customer replies.

If a later source confirms a date, review it in context and revise the current instruction again. Keep a short explanation of what superseded the old note when it helps a teammate, without leaving contradictory instructions presented as equally current. This is a writing convention, not a claim of automatic version history, immutable audit storage or a dedicated superseded-note feature.

Repair a note when the same source message changes

A later message can supersede a proposal, as above. A different problem occurs when the same located message now has different text. Keep two observations separate: what an authorized reviewer actually read earlier, and what the current read returns. Do not reconstruct the earlier wording from today's edit marker.

Where your connection advertises message_get, the reviewed implementation returns current message text, its source reference and nullable editedAt. The reference includes account, peer, namespace and message ID; a message number alone is not enough. The Telegram message schema includes an optional edit date, not a list of prior text versions. Neither that schema nor Chiho's reviewed exact-message response supplies an edit-history archive. A null marker does not certify that the text never changed. Check surrounding context with an authorized bounded read; use source rechecking before a decision for the freshness boundary.

The following is a fictional two-observation exercise, not a retrieved conversation or a product result. The English fixture stays identical in every translation. O1 is assumed to have been recorded when read; it is not recovered retrospectively by Chiho.

Fictional fixture: DEMO-EDIT / account A / chat C / history / message 205
Observation O1 | read at 2026-11-02 09:00 Asia/Singapore
text: "Reserve Friday for the pilot."
editedAt: null
Derived note N1: "Friday reserved; prepare the pilot."
Observation O2 | read at 2026-11-03 11:00 Asia/Singapore
text: "Do not reserve Friday; wait for security approval."
editedAt: 2026-11-03T02:30:00Z
Unknown: any intermediate wording, editor identity, reason for change.

Create a private correction receipt with these fields. They are suggested review labels, not built-in CRM fields or automatic version storage:

1. Source match: confirm that O1 and O2 refer to the same authorized account, chat, namespace and message. Reusing a number from another chat fails this check.
2. Observation boundary: retain each read time, timezone, minimum necessary excerpt and returned edit marker. If O1 has no retained source excerpt, label its wording unavailable; a remembered summary or old CRM note is not an earlier source version.
3. Discrepancy: N1 no longer supports the action “prepare the pilot.” Record that the current source asks for a hold. Do not infer who edited it, why, or how many times from O2.
4. Proposed correction and owner: propose “Friday is not reserved; wait for security approval.” Name a proposed correction owner and review trigger, such as Maya checking when approval arrives. Naming Maya here does not assign a task or grant authority to change the record.
5. Saved outcome: leave “not saved” until the exact correction is authorized through an available workflow and read back from the same record. Record unresolved concurrent edits or an uncertain save instead of marking the correction complete.

A useful review result for this fixture is: “O1 and O2 are distinct observed readings of the same source; intermediate history is unknown. Replace N1's current action with a hold, subject to the responsible owner's review.” Keep the receipt in an approved private location and retain only necessary context. It is not an immutable audit trail. If the source cannot be reopened, propose a hold pending verification rather than inventing O2. This exercise provides no measured accuracy or benefit claim.

Separate reading from refreshes and saved changes

A read-only request should ask for the source packet and a proposed note in the AI conversation. It should explicitly exclude summary refresh, CRM persistence, task creation and sending. Prompt wording expresses intent; review the client's tool controls as well.

summary_refresh is a write: the reviewed implementation generates and persists a summary, its update time and last-summarized-message marker. Its scoped persistence path retains the other CRM fields in that update, but does not validate the note or provide a guarantee against concurrent edits. Read the saved state again after any authorized change. Summary generation uses bounded history; a new summary is not proof of a complete relationship review.

The CRM interface has a separate Notes control. If you decide to save the reviewed wording there, request that specific change through an available authorized workflow, or edit it yourself. Do not invent a note-writing MCP tool or assume the AI draft was saved. Tool availability depends on the connection and product profile.

Chiho enforces scope, capabilities and execution safeguards. Summary refreshes and some CRM or task changes can execute directly after client controls; not every agent write has a separate approval prompt. Other actions have their own review requirements. Specify the exact mutation, check its result and verify persistence before reporting completion. Follow runtime wait instructions instead of repeatedly retrying same-account requests; the MCP troubleshooting guide covers access and rate-limit failures.

A bounded prompt and a saved-state check

Adapt this read-only request after resolving the real identity and conversation. The message limit is a proposed exercise boundary, not a Telegram quota or a guarantee of complete coverage.

Use the verified account and chat identifiers. Read at most 20 recent
messages sequentially and inspect the stored summary if available.
Return: source locators and excerpts; interpretation; proposed team
decision and review trigger. Identify missing history and conflicts.
Do not refresh summaries, save CRM changes, create tasks or send messages.
If the source cannot support a statement, mark it unverified.

Evaluate the workflow only with authorized non-production fixtures:

1. Resolve identity and scope; record the retrieved boundary and any missing context.
2. Compare each proposed fact with its original excerpt and surrounding messages. Preserve the condition and later hold in the fixture above.
3. Review the proposed note separately from the stored summary. Identify the unsupported old instruction and its replacement.
4. If a save is separately authorized, make that exact change and reopen the same record in the same account/team scope. Check the stored wording and that unrelated context was not unintentionally replaced.
5. If a refresh is separately authorized, inspect the saved summary and note again. Record observed, failed or untested outcomes; do not infer persistence or accuracy from generated text alone.

On an ambiguous save result, inspect the current record before retrying. If another teammate edited it, reconcile the actual latest state rather than overwriting from an older draft. If the required source is unavailable, keep the decision pending and ask an authorized owner for clarification.

Begin with one source-backed read

Install Chiho MCP and authorize in the browser, verify the identity, then inspect one bounded conversation. Draft the three-part note in your AI client and check one consequential statement against its source. Save or act only through a separately requested, appropriately authorized workflow, with a readback of the outcome. The useful deliverable is a traceable decision and an explicit uncertainty—not a confident paragraph that hides how it was produced.