Create a memory entry
One keyed value inside a memory layer. The agent reads it by key, on demand, with get_memory.
get_memory with the key and gets the content back.
The key is the interface
key is the only required field on the spec, and it works like a file path. It is what the agent passes to get_memory, and what the memory cascade resolves against: the first layer holding the key wins.
Keys are unique within a layer. A second entry with the same key is a 409.
policies/us/refunds in a general layer and again in a customer-specific one, and the cascade picks the specific one.
cadenya/ prefix are all accepted. Pick a convention and hold yourself to it. The API does not.Content or upload, never neither
An entry needs a body, andspec.type names where it comes from: content for inline text, or uploadId to point at an uploaded file for anything large. The matching field rides along with the type.
description is optional and independent of both. It tells the agent what the entry holds before it decides to read it, which is what makes search_memory worth calling.
content comes back at the top level
Read an entry and content sits beside spec, not inside it. spec holds key and description; the body is its own field.
get_memory sees the new value:
Updated: 45 days., the same string a retrieve returns.
The layer types you can create
spec.type is required on the parent layer, and MEMORY_LAYER_TYPE_UNSPECIFIED is rejected.
metadata.name is required too, so a body carrying only a spec is a 400 whatever the type says.
That leaves SKILLS for knowledge you author, and EPISODIC for the layer an agent writes to itself with store_memory. Cadenya creates and manages the episodic layer when an agent has enableEpisodicMemory set, so you rarely create one by hand.
Reaching the agent
An entry is inert until its layer is assigned to a variation.position orders the cascade.
get_memory and search_memory in its tool list. The read arrives as a toolCalled event with arguments: { "memoryKey": "policies/us/refunds" }, not as a memoryRead event.
Related
Create a memory layer
Memory layers
Create an upload
uploadId comes from, for entries too big to inline.Create a variation
position that orders them.Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
"workspace_01HXKD2E5NQM3T9AYWCF133E3Q"
Memory layer ID. Accepts canonical memlyr_… form or external_id: form.
"memlyr_01HXKD2E5NQM3T9AYWCFFFBMJH"
Body
CreateResourceMetadata contains the user-provided fields for creating a workspace-scoped resource. Read-only fields (id, account_id, workspace_id, profile_id, created_at) are excluded since they are set by the server.
MemoryEntryCreateSpec is the input shape for CreateMemoryEntry. It accepts either inline content or a reference to a completed Upload; exactly one of the two must be set.
- Option 1
- Option 2
Response
OK
MemoryEntryDetail is the full representation of an entry, including the resolved content body. Returned by GetMemoryEntry, CreateMemoryEntry, and UpdateMemoryEntry.
Standard metadata for persistent, named resources (e.g., agents, tools, prompts)
MemoryEntrySpec is the metadata portion of an entry — the fields that identify and describe it, without the body. It appears on both the summary (MemoryEntry) and detail (MemoryEntryDetail) views.
The resolved body of the entry. For entries created or updated via an upload_id, this is the ingested content, not the original upload handle. May be empty; an entry with only a key and description is valid (e.g., a stub skill being drafted, or an entry where the frontmatter alone is the payload).