Skip to main content

resolve_agent_uuid

Function resolve_agent_uuid 

Source
pub(crate) fn resolve_agent_uuid(
    mstore: &Store,
    agent_id: &str,
) -> Result<String, String>
Expand description

Resolve agent_id — the agent SLUG, per the App-API convention (see memory_dir_for_agent’s own doc comment) — to the same stable, canonical identifier (AgentDefinition.id / db_agents.id) the WebSocket RPC surface (agent:memory:write_file et al., which receives this id directly from the caller and resolves it via agent_def_get) already keys db_agent_native_memory_versions by.

reagent P1: without this, a version written through this App-API/MCP surface (previously slug-keyed, verbatim) lived in a disjoint keyspace from one written through the WS RPC surface for the exact same logical agent whenever slug != id — a version written via the MemoryWrite MCP tool was invisible to a WS-RPC-based MemoryHistory/MemoryDiff/ MemoryRevert call and vice versa, silently defeating the point of having version history at all.

Mirrors memory_dir_for_agent’s own slug → instance → registry resolution order, but returns the id instead of a filesystem path:

  • Primary path (instance_get_by_slug): db_agents is the consolidated definition+instance table (Phase 3a) — its own query selects id, id AS def_id, i.e. the row’s id already IS the definition id in this model, not a separate instance-only identity.
  • Registry fallback (a live agent not yet persisted to db_agents): the registry record’s definition_id field is the one that matches agent_def_get’s namespace — its sibling instance_id is a different, launch-scoped identity, not what write_file keys by.