Affected: packages/cli/src/daemon/routes/status.ts (line ~420), packages/agent/src/dkg-agent.ts:2696
Verified against: main @ 13a70642
Summary
A working-memory query requires agentAddress to scope the named-graph union. The daemon writes assertions under defaultAgentAddress ?? peerId, but the query-side fallback is to peerId alone:
agentAddress: agentAddressStr ?? (opts.view === 'working-memory' ? this.peerId : undefined),
On any node with a configured default agent (e.g. anything running an agent framework with its own EVM identity), writes land under defaultAgentAddress and queries scope to peerId. The two prefixes diverge silently. No error, no log line, just zero matches.
The available identity surfaces don't expose defaultAgentAddress:
GET /api/status returns peerId but not defaultAgentAddress.GET /api/agents returns the network-wide registry (~750 entries on a typical node) without distinguishing local-only identities and without populating an address field for them.
The only working discovery path we found is to scan existing assertion graph URIs in the project for the address segment after /assertion/. That requires the project to have at least one prior write before it can be used.
Notably, dkg-agent.ts already uses the right pattern (defaultAgentAddress ?? peerId) elsewhere in the same file — at line 4558 and line 6920 — just not in the WM-query fallback at line 2696.
Suggested fixes (any one or several)
- Add
defaultAgentAddress to /api/status's response. One line; lets every integration scope WM queries correctly without scanning graphs.
- Or add
/api/local-agents returning local identities (peerId, agent EVM address, framework), distinct from the network-wide /api/agents registry.
- Or change the fallback in
dkg-agent.ts:2696 from this.peerId to this.defaultAgentAddress ?? this.peerId for working-memory queries, so writes and reads target the same namespace by default.
Affected:
packages/cli/src/daemon/routes/status.ts(line ~420),packages/agent/src/dkg-agent.ts:2696Verified against:
main@13a70642Summary
A working-memory query requires
agentAddressto scope the named-graph union. The daemon writes assertions underdefaultAgentAddress ?? peerId, but the query-side fallback is topeerIdalone:On any node with a configured default agent (e.g. anything running an agent framework with its own EVM identity), writes land under
defaultAgentAddressand queries scope topeerId. The two prefixes diverge silently. No error, no log line, just zero matches.The available identity surfaces don't expose
defaultAgentAddress:GET /api/statusreturnspeerIdbut notdefaultAgentAddress.GET /api/agentsreturns the network-wide registry (~750 entries on a typical node) without distinguishing local-only identities and without populating anaddressfield for them.The only working discovery path we found is to scan existing assertion graph URIs in the project for the address segment after
/assertion/. That requires the project to have at least one prior write before it can be used.Notably,
dkg-agent.tsalready uses the right pattern (defaultAgentAddress ?? peerId) elsewhere in the same file — at line 4558 and line 6920 — just not in the WM-query fallback at line 2696.Suggested fixes (any one or several)
defaultAgentAddressto/api/status's response. One line; lets every integration scope WM queries correctly without scanning graphs./api/local-agentsreturning local identities (peerId, agent EVM address, framework), distinct from the network-wide/api/agentsregistry.dkg-agent.ts:2696fromthis.peerIdtothis.defaultAgentAddress ?? this.peerIdfor working-memory queries, so writes and reads target the same namespace by default.