Inter-session message attribution incorrectly defaults to owner peer

[abhibansal-sg]

GitHub Issue: Inter-session message attribution incorrectly defaults to owner peer

Repository: plastic-labs/openclaw-honcho
Plugin version: 1.2.1
OpenClaw version: 2026.3.28

Summary

When agents communicate via sessions_send (inter-session messaging), the Honcho plugin attributes all inbound role: "user" messages to the owner peer instead of the sending agent's peer. This causes Honcho to model the owner as having authored messages they never wrote, polluting the owner's representation.

Environment

• Multi-agent OpenClaw setup with 4 agents (main/Kai, atlas, nyx, mia)
• Agents communicate via sessions_send for task delegation
• Each agent has its own persistent session and Honcho peer (agent-main, agent-atlas, etc.)

Steps to Reproduce

1. Agent A (e.g., agent:main) sends a message to Agent B (e.g., agent:atlas) via sessions_send
2. Agent B processes the message and responds
3. The agent_end capture hook fires and calls flushMessages() → extractMessages()
4. The inbound message from Agent A is attributed to the owner peer instead of Agent A's peer

Expected Behavior

The message should be attributed to Agent A's peer (agent-main), since Agent A is the actual sender.

Actual Behavior

The message is attributed to the owner peer, because extractMessages() maps all role: "user" messages to ownerPeer unconditionally:

const peer = role === "user" ? ownerPeer : agentPeer;

Root Cause Analysis

Provenance data exists but is not accessible

OpenClaw tags sessions_send messages with full provenance in the session transcript (.jsonl file):

{
  "role": "user",
  "content": [...],
  "provenance": {
    "kind": "inter_session",
    "sourceSessionKey": "agent:main:discord:channel:...",
    "sourceChannel": "discord",
    "sourceTool": "sessions_send"
  }
}

However, event.messages passed to plugin hooks strips the provenance field. Messages in the hook only contain ["role", "content", "timestamp"].

This means the plugin cannot access provenance from the hook event data directly.

Same issue affects subagent_announce messages

Subagent completion announcements also arrive as role: "user" with provenance.sourceTool === "subagent_announce" and are similarly mis-attributed to the owner.

Data from a real session:

• 80 sessions_send messages attributed to owner (should be agent-main)
• 18 subagent_announce messages attributed to owner (should be parent agent)

Additional gap: cron/heartbeat messages

Cron-initiated and heartbeat messages arrive as role: "user" with no provenance at all. These system-generated prompts get attributed to the owner, polluting the owner's representation with content like "Read HEARTBEAT.md..." and "[cron:...] WhatsApp Pulse — 15-min scan."

This cannot be fixed in the plugin without OpenClaw core tagging these messages with provenance.

Workaround (local patch applied)

We implemented a local workaround that reads provenance from the session transcript .jsonl file:

1. flushMessages() constructs the transcript path from ctx.agentId + ctx.sessionId
2. Reads the .jsonl file and builds a Map<timestamp, provenance> for inter-session user messages
3. Matches event.messages entries by timestamp to find their provenance
4. Resolves sender agent peers via getAgentPeer() and builds a peer override map
5. Passes overrides to extractMessages() which uses them instead of defaulting to ownerPeer

This workaround is functional but has limitations:

• Reads the entire transcript file on every flush (performance concern for large sessions)
• Relies on timestamp matching (could theoretically have collisions)
• Must be re-applied after plugin updates

Recommended Fix

Ideal (requires OpenClaw core change)

OpenClaw should include provenance in event.messages passed to plugin hooks. The data exists on disk — it just needs to not be stripped before hook delivery.

Plugin-side fix (if OpenClaw exposes provenance)

In extractMessages() or flushMessages():

// Before peer assignment, check provenance
if (role === "user" && m.provenance?.kind === "inter_session") {
    const senderAgentId = parseAgentIdFromSessionKey(m.provenance.sourceSessionKey);
    if (senderAgentId) {
        peer = await getAgentPeer(senderAgentId);
    }
}

Design decisions (validated with 4-round technical review)

• sessions_send messages → attribute to sending agent peer
• subagent_announce messages → attribute to parent agent (not ephemeral subagent)
• All :subagent: session keys collapse to parent agent identity
• Sender peers added to session with observeMe: true, observeOthers: true
• Single merged addPeers() call with OR-merge for observation booleans
• Cron/heartbeat attribution deferred (needs OpenClaw core provenance tagging)

Additional Issue: createMemorySearchTool error

After updating OpenClaw to 2026.3.28, the plugin throws:

plugin tool failed (openclaw-honcho): TypeError: Cannot read properties of undefined (reading 'createMemorySearchTool')

This appears to be a compatibility issue between plugin v1.2.1 and OpenClaw 2026.3.28's memory tool API. Core memory capture/context injection still works — only the QMD passthrough tool registration fails.

Impact

• Owner peer representation polluted with agent-authored and system-generated content
• Agent peer representations missing their actual inter-agent communication
• Context injection feeds polluted data back into prompts (compounding effect)
• Multi-agent setups with frequent sessions_send usage are most affected

[ajspig]

Thanks @ab0991-oss! Thorough writeup, and great correct root cause analysis.

Where things stand:

The core problem: all role: "user" messages attributed to owner peer unconditionally. This is partially addressed by PR #31 which adds per-sender peer resolution for group chat participants via sender_id metadata extraction.

What #31 does NOT fix:

• sessions_send / subagent_announce attribution -- no provenance in hook event data
• Cron/heartbeat messages -- no provenance at all

Upstream issues on OpenClaw:

• openclaw#51007 -- requests sourceSession in chat.history message metadata for sessions_send messages. Closest to what we need but targets the API response, not plugin hooks.
• openclaw#47070 -- requests input provenance on sessions_spawn child tasks.
• openclaw#19049 (closed) -- earlier attempt at the role attribution problem.

Gap: There is no upstream issue specifically requesting that provenance be preserved in event.messages passed to plugin hooks. The data exists in the .jsonl transcript -- it's just stripped before hooks receive it. That's the issue we need filed.

@ab0991-oss -- would you be willing to file the upstream issue on openclaw/openclaw? You have the best reproduction data and the root cause is well documented here. The ask is: preserve the provenance field on messages in plugin hook events (agent_end, before_compaction, before_reset), same as it exists in the session transcript .jsonl.

Once that lands, the plugin-side fix is straightforward using #31's peer resolution infrastructure.

Leaving this open as the tracking issue for full provenance-based attribution.

[abhibansal-sg]

Thanks for the detailed response and the pointer to PR #31 — that's great to know about.

Filing the upstream issue on openclaw/openclaw now. Will link it back here once it's up.

[abhibansal-sg]

Upstream issue filed: openclaw/openclaw#57796

Covers preserving provenance in plugin hook event messages (agent_end, before_compaction, before_reset).

[GodsBoy]

Upstream fix submitted: openclaw/openclaw#57849

This preserves the provenance field on messages in plugin hook events (agent_end, before_compaction, before_reset). Once merged, the Honcho plugin will be able to read message.provenance.sourceSessionKey and message.provenance.sourceTool directly from hook event messages to correctly attribute inter-session messages.

[abhibansal-sg]

Upstream fix already submitted by @GodsBoy: openclaw/openclaw#57849

Reads messages from session JSONL transcript in hook events, preserving provenance. Once merged, the transcript-file workaround in our current patch becomes unnecessary and the plugin can use message.provenance directly.

[ajspig]

Partially addressed by #68. The blanket role: "user" → owner peer attribution is gone. Messages with sender metadata (group chats, external platforms) now route to the correct participant peer. However, sessions_send and subagent_announce messages still fall back to the default participant peer because they don't carry 'Conversation info (untrusted metadata):' blocks — the sender_id extraction has nothing to work with. I'm doing some research into the session ID construction in OpenClaw since a lot changed here since this plugin was first published. This could provide another way to identify the peer. Otherwise, this is blocked on OpenClaw.

[kinthaiofficial]

This is a fundamental design issue in multi-agent messaging that we hit in the same way. The root cause is that OpenClaw session model was designed for human-agent dyads, not agent-agent communication.

The fix at the extractMessages() level is necessary but not sufficient. Three related issues:

1. Attribution needs a proper sender field, not role inference. Mapping role: "user" → owner and role: "assistant" → agent breaks down the moment a third party enters the conversation. We solved this by adding an explicit sender_id to every message envelope, independent of the OpenAI-style role field. The role stays for LLM compatibility; the sender_id is for attribution.

2. Memory contamination from misattribution is hard to undo. If Honcho has already modeled the owner as having authored Agent A's messages, those memories need to be retroactively corrected, not just going forward. We found that a one-time migration that re-attributes messages based on session_send metadata (which does contain the true sender) is safer than trying to selectively forget.

3. Multi-agent memory isolation is the deeper problem. Even with correct attribution, Agent A's memories about the owner should not be visible to Agent B unless explicitly shared. We wrote about the five-component persistent memory architecture (including the user isolation layer) at https://blog.kinthai.ai/why-character-ai-forgets-you-persistent-memory-architecture — the multi-tenancy implications at the memory layer are detailed at https://blog.kinthai.ai/openclaw-multi-tenancy-why-vm-per-user-doesnt-scale

For the immediate fix: checking internalMetadata.source === "session_send" and using internalMetadata.senderAgentId for attribution is the right approach. But consider also adding a validation layer that rejects any message where role and sender_id are inconsistent — this catches future similar bugs before they contaminate the memory model.