Skip to main content
Install the Python SDK:
The client connects to https://api.memoryo.dev by default. Do not pass base_url for the hosted service.

Clients

  • Sync client: Memory
  • Async client: AsyncMemory
  • Private-beta cross-agent client: UniversalMemory (disabled by default)
UniversalMemory is retained for the frozen Memory Passport private beta. It will receive 404 memory_passport_not_available unless MemoryOS explicitly enables the feature for your deployment. Use Memory or AsyncMemory for supported production integrations.
There is no separate SDK for domain schemas. If your tenant enables EdTech or Support, add() and get() remain the main integration path. Optional domain helper methods expose structured profile data for dashboards.

Tenant-scoped memory

Use Memory from your backend with a tenant API key. This path uses your application’s existing user identity. It does not require Memory Passport, a user consent redirect, or the UniversalMemory client.

First integration: simple mode

Start here when one backend writer supplies context for a stable user. You do not need event_id, run_id, service writers, or authority rules. MemoryOS creates safe internal source metadata automatically.

add()

add() queues a conversation for extraction. It returns quickly; extraction runs in the background.
You may submit the completed user and assistant turns. In simple mode, assistant text is retained as conversation context but is not authoritative user evidence. MemoryOS stores a claim only when a user turn directly states or confirms it. For a durable evidence trail, provide an external_turn_id for each persisted turn. It is a stable identifier from your chat system, not a claim created by the model. Use source_kind when the role alone is insufficient to describe the origin, such as tool_output or fetched_document. Keep one conversation_id for every add() call in the same chat. Messages are limited to 64 per request and 16,000 characters each.

Explicit assistant proposals

Preview Phase 3A contract: requires the structured-proposal backend migration and an SDK release containing ProposedMemory. Confirmation is feature-gated and remains off until the deployment passes its release evaluation.
For an assistant statement that your application deliberately presents as a memory proposal, mark only that assistant turn with is_memory_proposal=True, source_kind="assistant_output", a stable external_turn_id, and proposed_memory. The structured claim must appear in the user-visible assistant text. MemoryOS records an immutable proposal and returns its id in result.proposal_ids when ingestion is admitted; this marker never turns assistant text into user evidence and does not itself create or promote a memory.
Job status exposes proposal_ids and operational_metrics.queue_wait_ms when available. A proposal ID is not a stored memory ID or proof of user consent. When confirmation is enabled, submit the proposal turn and the later direct user reply with the same conversation_id and stable turn IDs. MemoryOS binds the reply to the immutable proposal and stores the registered claim only after the evidence policy accepts it. Model confidence never grants authority. Registration is tenant-scoped; the universal client does not support this marker.

For multi-service companies: source-aware mode

Use this when Billing, Support, CRM, Product, or another backend service can write facts about the same user. Source metadata enables auditability, deduplication, conflict handling, and authority rules.
Use Memory.source(...) so your app does not have to manually generate every ID while testing.
Register billing-service in the Tenant Dashboard before sending it as source.service; unknown or inactive service keys are rejected. For production, bind a dedicated API key to the writer so its authority is explicit. Only use source-aware mode for authenticated backend observations. It can treat a registered service’s declarative assistant-role message as authoritative; it must not be used to promote an ordinary chatbot answer into user memory.

Parameters

Return fields

Check extraction job status

Use get_job_status() for one check or wait_for_job() when setup, tests, or a workflow must confirm persistence before continuing.
pending_candidates_buffered > 0 means MemoryOS kept a weak signal for reinforcement instead of dropping it. Normal user-facing requests should queue add() without waiting. Use created_memory_ids when you need the exact records created by this job.

get()

Parameters

Return fields

Resolve a clarification in the same chat

The backend verifies tenant and user ownership, expiry, conflict state, and the allowed transition. The model may present the question, but it must not invent the resolution or decide authority.

feedback()

Use feedback after retrieval to tell MemoryOS whether the memory helped. This improves lifecycle scoring and can queue retrospective extraction after user corrections.
When a user corrects the answer, send the correction text:
If correction_job_id is present, MemoryOS queued an async retrospective extraction pass. Do not block your user flow while that job runs.

Domain schemas

Domain schemas are configured on the tenant, not in SDK code. Your code stays the same across domain modes. For Support, your own backend tools still provide live truth such as order status, invoice status, refunds, or ticket updates.

Domain profile helpers

For domain-aware tenants, normal get() already includes domain-aware context. Use profile helpers only when your product needs structured UI data.

AsyncMemory

AsyncMemory has the same method surface as Memory, but every method is async.

Other tenant methods

delete()

Archives by default. Set hard_delete=True to permanently delete. The backend derives tenant scope from the API key and verifies the memory ID; an external user ID is not required.

list()

export()

export() maps to GET /v1/users/{external_user_id}/export. It returns the tenant and proxy-user IDs plus that user’s memories and complete version history.

UniversalMemory

UniversalMemory is retained for explicitly enabled Memory Passport private-beta deployments. It uses:
  • an agent API key (agent_sk_...)
  • a user UUI token (uui_...) for the approved Memory Passport user
Generate the user consent URL from your tenant app. If you omit redirect_uri, MemoryOS shows a hosted completion page after approval.
Users can add or remove categories before approving. Universal writes support durable retry identity, and retrieval supports the same prompt formatting controls as tenant retrieval:
Retrieved universal memory items preserve source-event and provenance fields returned by the API.