Agent capabilities

Memory

Keep durable, searchable context attached to the right member and organization across agent clients.

Memory preserves the part of an agent setup that should outlive a client or conversation. A user can move from Claude Code to Codex—or replace the agent entirely—without rebuilding stable preferences, facts, and project decisions.

The organization owns its memory. Each write is scoped as shared or private inside that organization, and CoreSpeed derives the caller identity from auth; the agent cannot supply a different user ID to cross the boundary. The boundary is enforced in Postgres by row-level security, not only in application code.

Eight public tools

Names below are the operations exposed on the unified MCP surface:

ToolUse it for
memory__rememberSave one concise fact, preference, or decision.
memory__search_memoryFind memories relevant to the current task.
memory__get_memoryRead one memory in full by ID.
memory__ingestExtract durable memories from recent messages.
memory__update_memoryCorrect an existing memory by ID.
memory__delete_memoryRemove one memory.
memory__list_memoryList recently saved memories.
memory__clear_all_memoryDelete all memory after explicit confirmation.

These eight are the whole public surface. Retrieval underneath them is hybrid — exact and relaxed lexical matching, entity aliases, and vector similarity, fused into one ranking — but it is reached through memory__search_memory rather than exposed as separate knobs.

Long memories come back as excerpts

memory__search_memory and memory__list_memory return many memories at once, so they bound how much text each one contributes. A memory of 1,200 characters or fewer — the overwhelming majority — is returned whole. A longer one is returned as an excerpt, marked in the result:

{
  "id": "0b5f…",
  "memory": "Escalation runbook: page the on-call rotation first…",
  "truncated": true,
  "full_length": 5310
}

For a search hit the excerpt is the passage that actually matched the query, not the head of the memory — the same chunk the ranking scored. list_memory has no query to be relevant to, so it excerpts from the start.

Pass the id to memory__get_memory to read the whole thing. That read follows normal visibility: your own private memories plus the organization's shared ones, whoever wrote them.

A whole result is bounded too, not just each row in it. If the memories that matched would together exceed what a client can receive, the lowest-ranked ones are dropped and the result says how many:

{ "memories": [ /* … */ ], "omitted": 29 }

The top hit is always returned, however large. In practice the default limit of 10 never reaches the budget — only an explicitly high limit does. Narrow the query or lower limit to see what was dropped.

Shared and private context

memory__remember accepts scope: "shared" | "private":

  • private is the default and can be read only by the member who created it.
  • shared must be asked for explicitly, and can then be read by agents operating inside the same organization boundary.

Member state is always organization-scoped. Turning memory off in one organization cannot affect the same user in another organization.

Pricing and holds

Memory operations cost $0 per call. The provider remains inside the metered operating boundary, so an organization billing hold or suspension can still block execution. Storage quotas and rate limits protect the shared service.

Inspect and remove memory

Use Dashboard → Memory to browse memories, search, inspect the graph, open a detail view, and delete content. Disabling the memory capability hides its MCP tools but preserves existing data; deletion is a separate explicit action.

What belongs in memory

Save context that will improve a later action: a preference, a product decision, a named relationship, or an operating constraint. Do not use memory as a transcript archive, a secret store, or a substitute for application data.