Memory

Each smith has its own memory, and maintains it automatically during runs. You rarely touch it, but it's inspectable and editable via the API and console.

Memory is per smith. One person's facts can never surface in another person's conversation; that isolation is why you create one smith per end-user.

How it works

Layer	What it is	When it's in context
Working memory	a structured doc the smith keeps about its end user (name, preferences, goals)	always, while memory is on
Semantic recall	the smith's own past messages, retrieved by similarity	when relevant to the current turn
History	the recent turns of the active thread	the tail of the active thread

The smith updates its working memory and recalls past messages on its own — you don't file facts by hand. Recall and history follow the thread_id you pass; see Runs & streaming.

Working memory is one doc per smith, shared by all of its conversations and rewritten whole on each update. That is why a smith runs one turn at a time: two turns at once would be two writers of one doc, and the second would overwrite what the first learned.

Working memory

# Authorization: tenant-admin token (server-side only), or a smith token with memories:*
H=(-H "Authorization: Bearer $IC_TOKEN" -H "IC-Api-Version: 2026-05-01")
curl "${H[@]}" https://api.cloud.ingram.tech/v1/smiths/smt_…/memory
# → { "content": "# Profile\n- Name: …\n- Prefers: …" }

curl "${H[@]}" -X PUT https://api.cloud.ingram.tech/v1/smiths/smt_…/memory \
  -H "Content-Type: application/json" \
  -d '{ "content": "# Profile\n- Name: Ada\n- Prefers: terse answers" }'

The doc is plain text the smith rewrites as it learns. Replacing it from the API overwrites what the smith holds.

Recall

# Authorization: tenant-admin token (server-side only), or a smith token with memories:read
curl "${H[@]}" -X POST https://api.cloud.ingram.tech/v1/smiths/smt_…/memory/recall \
  -H "Content-Type: application/json" \
  -d '{ "query": "where does the user work", "limit": 5 }'
# → { "data": [ { "thread_id": "…", "content": "…", "score": 0.9 } ] }

Recall runs automatically inside a run; this endpoint just surfaces what it would retrieve, for inspection.

Consolidation (opt-in)

memory_consolidation: true (on the smith or its agent; default off) turns on consolidation: a background pass that distills a smith's history into a denser observation log as conversations grow, so long-running smiths keep useful memory without dragging the whole transcript into context. It's off by default because it isn't worth it for every use case.

Consolidation runs the model in the background, so — like recall's embeddings — it consumes credits. Every memory model call is metered and billed the same way a run is (provider cost + your platform margin), on its own usage line. Leave it off for smiths where the extra spend isn't warranted.

Turning memory off

auto_memory: false (on the smith or its agent) disables memory for that smith: no working memory, no recall, no consolidation, nothing remembered. Use it for stateless utility smiths, e.g. the dedicated smith you run structured-output calls through.

In the console

A smith's Memory tab shows its working-memory doc, editable in place. Edits take effect on the next run.

Sandbox: a filesystem and a shell Files & vector stores