Telegram Channels Need Project Pins

APC is the portable context layer. APX is the daily runtime that makes that context usable. Telegram fits that split well: APC defines what a project is, and APX decides how a message from a phone lands in the right project at runtime.

That is the real value of project pinning. A Telegram bot by itself is just a transport. It can receive text, but it does not know what repo, agent set, MCP config, or memory bucket should answer. Once a channel is pinned to a project, APX can resolve all of that without making the user repeat the project name on every message.

Why pinning matters

APX supports many Telegram channels in one daemon. Each channel can carry its own bot token, chat ID, optional project pin, and optional routed agent. That means a single APX instance can handle multiple workflows without mixing their history.

The important part is that the channel is not the same thing as the project. The channel is the entry point. The project is the context boundary. When project is set on a channel, APX scopes inbound messages to that project automatically. The system prompt resolves that project’s agents, MCPs, and memory, and project-scoped tool calls default to that project.

That removes a common failure mode: the user talks in a chat, but the runtime has to guess which project they meant. Guessing is bad. Repeating project names is bad too. Pinning makes the choice explicit once.

A small practical example

Imagine two Telegram channels:

• support-line pinned to customer-portal
• build-line pinned to apx-core

Both can live in the same APX daemon. Both can receive messages from the same person. But their context stays separate.

If someone sends a bug report to support-line, APX uses customer-portal agents, memory, and MCPs. If the same person sends a tooling question to build-line, APX uses apx-core instead. No cross-talk. No manual switching. No lost context.

The docs also allow a dedicated agent through route_to_agent when a channel should always go to one specific persona instead of the super-agent. That is useful when the channel is not meant to be a general assistant. It is a narrow workflow with one owner and one job.

The right mental model

Think of Telegram as the input surface, not the project itself.

• APC stores the portable contract: project rules, agents, memory, and config.
• APX reads that contract and applies it at runtime.
• Telegram channels point into APX.
• Project pins tell APX which project owns that channel.

That is why the feature matters more than it looks. Without pinning, Telegram becomes another generic inbox. With pinning, it becomes a real project surface: the message enters the right context, the right tools are visible, and the right memory stays attached.

Where this is useful

Project pins help most when one APX daemon serves more than one active project, or when the same human uses Telegram as a control plane for several workflows. They also help when the agent should behave differently depending on the project, because the project boundary is already encoded in the channel.

If you want the simplest setup, start with one channel, one project pin, and no extra routing. Add route_to_agent only when you need a dedicated persona. That keeps the boundary clean and makes debugging easier.

Bottom line

Telegram channels need project pins because context should not depend on memory or guesswork.

APC keeps the project definition portable. APX applies that definition when the message arrives. The pin is the bridge between the phone chat and the project boundary.