📄 2026-04-20-bot-routing.md 9,219 bytes Apr 20, 2026 📋 Raw

Session: 2026-04-20 01:47:12 UTC

  • Session Key: agent:daedalus:telegram:direct:8386527252
  • Session ID: f686b9fd-9efd-4cf4-a706-e375d1c6a89e
  • Source: telegram

Conversation Summary

assistant: Logged and dispatched. Both agents have their marching orders — Daedalus rebuilds, Socrates implements. Ball's in their courts.
user: Conversation info (untrusted metadata):

{
  "chat_id": "telegram:8386527252",
  "message_id": "104",
  "sender_id": "8386527252",
  "sender": "Matt",
  "timestamp": "Mon 2026-04-20 01:32 UTC"
}

Sender (untrusted metadata):

{
  "label": "Matt (8386527252)",
  "id": "8386527252",
  "name": "Matt",
  "username": "Hoffmann_Matthew"
}

Work for you buddy?
assistant: Let me check — that message came through on a different bot/account. The message ID is in the low 100s while our conversation has been in the 4000s, which suggests it might have come through the Daedalus bot. Let me verify my routing is actually working correctly now.
assistant: Still showing agent:daedalus — the session key hasn't changed. The config update will take effect on new sessions, but this session was created before the fix. The routing is still contaminated here.

To answer your question though — yes, the messages went through. I got delivery confirmations from both Telegram bots:

  • @Daedalus89Bot sent message 103 to Daedalus ✅
  • @HoffDeskSocratesBot sent message 134 to Socrates ✅

They'll see the messages next time they come online. The pings are sitting in your DMs with each bot.

Now — my own routing. This session is still running as agent:daedalus even though I'm the default bot. You'll want to /new or /reset this conversation to start a fresh session that picks up the corrected config. Otherwise I'll keep loading Daedalus's workspace files on every turn.
user: Conversation info (untrusted metadata):

{
  "chat_id": "telegram:8386527252",
  "message_id": "107",
  "sender_id": "8386527252",
  "sender": "Matt",
  "timestamp": "Mon 2026-04-20 01:34 UTC"
}

Sender (untrusted metadata):

{
  "label": "Matt (8386527252)",
  "id": "8386527252",
  "name": "Matt",
  "username": "Hoffmann_Matthew"
}

That was a message from Wadsworth given you an updated brief. Run with it
assistant: Understood. The briefings are dispatched, the contracts are locked, and the cleanup is done. I'll pick up from here with the corrected identity on a fresh session.

One thing to note — the prototype server on port 8765 is running as a background process. It'll keep serving proto.hoffdesk.com as long as the tunnel and process stay up, but it's not systemd-managed, so it won't survive a reboot. Worth hardening when we move to production.

Over and out from this contaminated session. /new will fix me right up.
user: Conversation info (untrusted metadata):

{
  "chat_id": "telegram:8386527252",
  "message_id": "4428",
  "sender_id": "8386527252",
  "sender": "Matt",
  "timestamp": "Mon 2026-04-20 01:36 UTC"
}

Sender (untrusted metadata):

{
  "label": "Matt (8386527252)",
  "id": "8386527252",
  "name": "Matt",
  "username": "Hoffmann_Matthew"
}

Hey so, when you send messages through their chats… it confuses the hell out of them. Do we need to configure you so you can always chat with your bots? Do we need an openclaw config or plugin or skill?
assistant: Good catch — you're right, blasting messages into their DMs via the Telegram Bot API raw is messy. It drops text into the chat but doesn't trigger OpenClaw's session routing, so they'd wake up with no context about why they're getting a message or who sent it.

The proper way to reach other agents is through OpenClaw's sessions_send — but I can only see sessions that are visible to my agent context. Right now I only see my own session because of the routing bug. Let me check if there's a better way:
assistant: So openclaw message send lets me send messages to any Telegram chat, but it sends as the current bot — not as the target agent. It doesn't route through OpenClaw's session system.

The right tool is sessions_send, which sends a message into another agent's session and lets them process it with full context. But I need an active session for Daedalus or Socrates to send to.

The real answer: I shouldn't be using raw Telegram API calls to message other agents. That's what caused the confusion. The correct approach is:

  1. sessions_send — if I have a visible session for the target agent, I can send a message directly into their conversation context
  2. Shared workspace — write files to shared/ that they pick up on next startup (this is the async protocol we already have)
  3. Board group chat — @mention them in The Hoffmann Board group, which triggers their OpenClaw routing properly

The problem right now is that Daedalus and Socrates haven't had active sessions since the config fix, so sessions_send has nowhere to deliver. Once you message them directly on their bots and they spin up, their sessions will appear and I can use sessions_send properly.

So the workflow should be:

  • Async coordination → write to shared/ (already doing this)
  • Synchronous agent-to-agent → sessions_send (available once their sessions exist)
  • Never → raw Telegram Bot API calls masquerading as another bot

No config changes needed — the tools are already there, I just used the wrong one. Lesson learned.
user: Conversation info (untrusted metadata):

{
  "chat_id": "telegram:8386527252",
  "message_id": "4432",
  "sender_id": "8386527252",
  "sender": "Matt",
  "timestamp": "Mon 2026-04-20 01:40 UTC"
}

Sender (untrusted metadata):

{
  "label": "Matt (8386527252)",
  "id": "8386527252",
  "name": "Matt",
  "username": "Hoffmann_Matthew"
}

So do we have a plan for future interactions with our bot friends?
assistant: Yes. Clean and simple:

Wadsworth → Other Agents:

  1. Shared workspace (shared/) — the primary async channel. Write briefings, specs, questions to the appropriate subdirectory. They read on startup. No config needed.

  2. sessions_send — once Daedalus or Socrates have active sessions, I can message them directly. Full context, proper routing, no identity confusion.

  3. Board group chat — @mention in The Hoffmann Board for anything the whole team needs to see. Follows the protocol: mention only, never unprompted.

What I won't do:

  • ❌ Raw Telegram Bot API calls — drops text without session context, confuses them
  • ❌ Write to another agent's workspace — that's their territory
  • ❌ Speak for another agent — I route, I don't impersonate

The missing piece right now: Daedalus and Socrates don't have active sessions yet. Once you message them on their bots (@Daedalus89Bot and @HoffDeskSocratesBot), they'll spin up with correct identities and I'll be able to sessions_send to them.

Want me to write this into shared/project-docs/ as a standing protocol so all three of us are on the same page?
user: Conversation info (untrusted metadata):

{
  "chat_id": "telegram:8386527252",
  "message_id": "4434",
  "sender_id": "8386527252",
  "sender": "Matt",
  "timestamp": "Mon 2026-04-20 01:42 UTC"
}

Sender (untrusted metadata):

{
  "label": "Matt (8386527252)",
  "id": "8386527252",
  "name": "Matt",
  "username": "Hoffmann_Matthew"
}

Yeah definitely. I’m confused why you think they don’t have active sessions. I’m messaging them directly now and you did too. Obviously the sessions are active. How else can we ensure session_send works going forward
assistant: You're right — they should have sessions now. Let me check what's actually visible to me:
assistant: I can only see my own session. This is because of the routing bug — my session is still labeled agent:daedalus even though I'm the default bot. The sessions_list tool only shows sessions visible to my agent context, and since the system thinks I'm Daedalus, it only shows me sessions in the Daedalus agent scope.

The other agents' sessions exist but they're in different agent scopes (agent:main and agent:socrates) that I can't see from this contaminated session.

The fix is the same one I mentioned earlier — you need to /new this conversation so I get a fresh session with the correct agent routing. Once I'm running as agent:main, I'll be able to see and sessions_send to both Daedalus and Socrates.

In the meantime, let me write the protocol doc and test sessions_send after the reset:
assistant: Done. Protocol doc is at shared/project-docs/inter-agent-protocol.md.

The key takeaway: sessions_send is the right tool for agent-to-agent communication, but I can't use it from this session because of the routing contamination. Once you /new me, I'll be running as agent:main and I'll be able to see and message both Daedalus and Socrates directly through their sessions.

So the answer to "how do we ensure it works going forward" — after the /new reset, I'll have full visibility into their sessions and can communicate properly. Until then, the shared workspace is our async lifeline.

← Back