Skip to main content
POST
JavaScript
An entry is one keyed value in a memory layer. Nothing about it enters an agent’s context up front. The agent calls 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.
Across layers, a repeated key is the whole point. Put policies/us/refunds in a general layer and again in a customer-specific one, and the cascade picks the specific one.
Key syntax is not validated. A leading slash, a double slash, and a 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, and spec.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.
The list omits it, the same way tool calls omit their results: paging a big layer stays cheap, and you pay for a body only when you ask for one. An update replaces the content, and the next get_memory sees the new value:
Ask an agent assigned to that layer to read the key and it answers 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.
Publish the agent, and the next objective’s agent carries 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.

Create a memory layer

The container, its type, and its TTL.

Memory layers

The cascade, and which layer wins a key.

Create an upload

Where uploadId comes from, for entries too big to inline.

Create a variation

Assigning layers, and the position that orders them.

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Path Parameters

workspaceId
string
required
Example:

"workspace_01HXKD2E5NQM3T9AYWCF133E3Q"

memoryLayerId
string
required

Memory layer ID. Accepts canonical memlyr_… form or external_id: form.

Example:

"memlyr_01HXKD2E5NQM3T9AYWCFFFBMJH"

Body

application/json
metadata
object
required

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.

spec
object
required

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.

Response

OK

MemoryEntryDetail is the full representation of an entry, including the resolved content body. Returned by GetMemoryEntry, CreateMemoryEntry, and UpdateMemoryEntry.

metadata
object
required

Standard metadata for persistent, named resources (e.g., agents, tools, prompts)

spec
object
required

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.

content
string
required

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).

info
object