honcho_context queries participant self-profile instead of agent-to-participant perspective

[aurorabotticus-svg]

Summary

honcho_context in @honcho-ai/openclaw-honcho 1.5.2 retrieves the participant peer's self card and self representation instead of retrieving the participant from the active OpenClaw agent's perspective.

This causes honcho_context(detail="card") to report that no profile exists even when Honcho has already synthesized a populated relationship-specific peer card for the agent observing that participant. detail="full" similarly returns the participant's self representation rather than the agent's representation of the participant.

The issue is present in both the published 1.5.2 package and current main in tools/context.ts.

Environment

• OpenClaw: 2026.7.1-2
• Plugin: @honcho-ai/openclaw-honcho 1.5.2
• Honcho: self-hosted current Docker image (honcho-api:latest at time of testing)
• SDK bundled by plugin: @honcho-ai/sdk ^2.0.0
• Channel: Telegram
• Workspace: openclaw
• Agent peer: agent-main
• Participant peer: owner
• Peer mapping: Telegram sender mapped explicitly to owner

Observed behavior

A read-only identity check produced:

1. honcho_context({ detail: "card" })

   • Returned: No profile facts available yet. The user's profile builds over time through conversations.
   • Reported factCount: 0.

2. honcho_context({ detail: "full" })

   • Returned only a narrow/recent set of observations from the participant's self representation.

3. honcho_search_conclusions(...)

   • Returned a substantially broader set of historical conclusions successfully.

There were no transport, API, embedding, derivation, or tool errors.

Database evidence

Honcho had already completed dream/synthesis work and stored relationship-specific cards:

• agent-main -> owner: populated peer card with 11 facts
• agent-main -> agent-main: populated self-card with 17 facts
• owner -> owner: no self-card

The relevant metadata existed under the agent-main observer peer as:

• owner_peer_card (11 entries)
• peer_card (17 entries)

Honcho deriver logs explicitly confirmed:

[tool call] update_peer_card keys=['content']
Updated peer card for openclaw/agent-main/owner
[tool result] update_peer_card ... peer_card_updated

Thus the empty result was not caused by delayed synthesis or missing data.

Root cause

Current tools/context.ts resolves the participant correctly, but then queries the participant object directly:

const participantPeer = about
  ? await state.getParticipantPeer(about)
  : await state.resolveSessionParticipantPeer(...);

const card = await participantPeer.card();

const representation = await participantPeer.representation({
  includeMostFrequent: true,
});

Per the Honcho SDK semantics:

• peer.getCard(target) returns what peer knows about target.
• peer.representation({ target }) returns the target's representation from peer's perspective.
• Omitting target retrieves the peer's self-card/self-representation.

Consequently, when participantPeer.id === "owner", the plugin requests owner -> owner. The useful user profile is agent-main -> owner.

Expected behavior

honcho_context is described as retrieving stored knowledge about the user for the OpenClaw agent. It should use the active agent peer as observer and the resolved participant as target:

const agentPeer = await state.getAgentPeer(toolCtx.agentId);

const card = await agentPeer.getCard(participantPeer);

const representation = await agentPeer.representation({
  target: participantPeer,
  includeMostFrequent: true,
});

The about parameter should continue to resolve the target participant exactly as it does today; only the observer perspective changes.

Locally validated fix

The published dist/tools/context.js was patched locally with the change above:

1. Resolve agentPeer through state.getAgentPeer(toolCtx.agentId).
2. Replace participantPeer.card() with agentPeer.getCard(participantPeer).
3. Replace participantPeer.representation(...) with agentPeer.representation({ target: participantPeer, ... }).

The patched file passed node --check, the OpenClaw gateway restarted normally, Honcho initialized successfully, and the database was not modified. The change addresses both card and full-context perspective selection.

Why this matters

The current behavior can produce a dangerous false negative:

• The UI/tool says no profile exists.
• Operators may assume synthesis is broken, re-import memories, manually duplicate facts, reset the backend, or wait indefinitely.
• In reality, the profile is present under the correct observer/target relationship.

It also makes card, full, and semantic-search results appear mutually inconsistent.

This is especially confusing in multi-peer environments, where Honcho intentionally maintains different representations depending on who is observing whom.

Suggested tests

Please add tests covering at least:

1. Active agent agent-main, participant owner:
   • honcho_context(card) calls agentPeer.getCard(ownerPeer).
2. honcho_context(full) calls:
   • agentPeer.representation({ target: ownerPeer, includeMostFrequent: true }).
3. Explicit about sender:
   • Sender resolution selects the target but the active agent remains the observer.
4. Multiple OpenClaw agents:
   • toolCtx.agentId selects the correct agent peer.
5. Missing relationship card:
   • Existing empty/not-found behavior remains graceful.
6. Ensure the participant's self-card is not returned accidentally.

Additional identity-routing context

On fresh installs, defaultUnknownPolicy: "per-sender" can auto-create a Telegram sender as a separate peer. Mapping that sender to owner correctly routes future turns to the owner identity, but it does not change the perspective bug described here. Even with correct participant resolution, the tool must still query agent -> participant, not participant -> participant.

Historical messages are intentionally not retroactively re-attributed when mappings change; this report does not request any change to that behavior.

Data safety

No Honcho records need migration for this fix. It is a read-path correction only. Existing peer cards, representations, conclusions, messages, embeddings, and session attribution can remain untouched.