One of the more useful operational fixes this week was not a model change or a new automation. It was finally getting the separate Telegram group threads working well enough that different kinds of work could stop colliding.

That sounds minor until you have one assistant handling document pages, backtests, morning reports and random operational work all in the same conversation. At that point, you are not just sharing context. You are grinding different kinds of thinking into each other until everything gets slower and dumber.

So we split the work.

The problem

The main Telegram DM had become the universal inbox for everything:

• documentation
• backtest engineering
• config debugging
• daily operations
• blog drafting

That worked for continuity, but it was bad for focus.

The documentation thread wanted long structural memory. The development work wanted parameter history, run IDs, database tables, and run controls. Both could technically coexist, but neither stayed clean.

The result was predictable: every topic carried drag from the previous one.

The goal

We wanted separate Telegram group threads that behaved like dedicated working contexts:

• Documentation
• Program testing
• A main thread for general operations

The key requirement was important: the assistant should respond in the group without needing to be tagged every single time.  Context was also lost, and if things got too long, compression would affect the work being done.

If the groups only worked with explicit mentions, they were still useful, but they were not really acting like natural, dedicated workspaces.

What actually helped

There were two parts to the fix.

1. Explicit Telegram group config

The groups needed explicit per-group overrides in the Telegram channel config.

The useful pattern looked like this:

{
  "channels": {
    "telegram": {
      "groups": {
        "<group-id>": {
          "enabled": true,
          "groupPolicy": "allowlist",
          "requireMention": false,
          "allowFrom": [
            "telegram:<trusted-user-1>",
            "telegram:<trusted-user-2>"
          ]
        }
      }
    }
  }
}

The important pieces were:

• `enabled: true`
• `groupPolicy: “allowlist”`
• `requireMention: false`
• `allowFrom: […]`

That combination told the gateway:

• this group is an intentional working context
• messages from the approved senders are allowed
• replies should not require an @mention every time

This was different from simply being able to post into a Telegram destination. Outbound posting and inbound conversational behavior are not the same problem.

2. Handoff/state files per topic

Even after the group routing began working, the separated threads felt thinner than the main session. That part was expected.

The main session has richer continuity. Topic-specific groups are cleaner, but they start with less context.

The fix for that was not to dump all memory into every thread, but to create topic handoff files. These files serve as a compact working memory for the dedicated groups.  This allows us to make have a small, explicit spine that contains:

• active docs
• current decisions
• what changed recently
• what not to drift back into
• the current next-step logic

That makes the group feel less like a “shadow assistant” and more like a focused version of the same one.

What was confusing

One surprising thing was that some Telegram group setups appeared to work partially but still failed at times.

For example, a group could exist as a separate session and tagged messages could work, but untagged messages still would not trigger replies reliably.

That made it tempting to blame the wrong thing.

Sometimes the issue was config, sometimes it was the difference between posting to a destination and receiving inbound updates from it.  And sometimes it was just that a new group existed, but had not yet been explicitly added as an interactive allowlisted group.

The lesson there was simple: session existence is not the same thing as good conversational behavior.

Why the handoff docs matter

This ended up being the more generally useful lesson.

Once work is split into topic threads, each thread needs a compact local memory source, or it doesn’t have the context of where to start. That means the right pattern is not one giant thread for everything, or one assistant with total memory everywhere, but a cleanly separated working context plus topic-specific handoff/state files.

This preserves focus without making every side thread feel hollow.

The real takeaway

The broader lesson is that context should be designed, not merely accumulated.

When an assistant starts helping with multiple serious streams of work, the answer is not always “give it more memory.” Sometimes the answer is ‘divide and conquer’.

While it may be slower to set up once, it is much faster to live with afterward.