How the platform works
Actx0 sits between your application and your model. You send conversation turns as they happen. Actx0 keeps the transcript, pulls out facts worth remembering, and hands back only the relevant ones before the next reply. You still run the model. Actx0 is the memory layer: store what matters, retrieve it in milliseconds, reuse it across turns without replaying the whole chat. Everything lives in a workspace (your team, billing, and keys). Inside it you create agents. Each agent runs sessions. A session holds messages (what was said) and memories (what should be recalled later).Messages vs memories
A message is a turn in the conversation. A memory is a short, durable fact taken from that conversation.
The transcript stays as messages so you can search or replay it. Memories are what you put in the next prompt: a few sentences, not the whole history.
You can also write a memory yourself when you already know the fact. Automatic extraction is for when you want Actx0 to read the chat and decide.
How a message becomes a memory
Extraction runs in the background after you create a user message. Assistant replies are stored and searchable; they do not trigger extraction.1
You send a user message
Your app (or MCP client) POSTs the turn into a session. Actx0 saves it and indexes the text for search.
2
Actx0 reads that one message
A model looks at the user text only — not the full transcript — and asks: is there anything worth remembering later?
3
It writes a short fact, or skips
Greetings, chit-chat, and generic instructions are dropped. Useful content becomes one third-person sentence, tagged
long_lived (stable identity, preferences, lasting facts) or short_lived (task state that fades with this conversation).4
The fact is indexed
The new memory is searchable, the same way you search messages and knowledge.
5
Existing memories are cleaned up
If the session already has memories, Actx0 consolidates them: exact duplicates go away, contradictions keep the newer fact, distinct facts stay separate. Nothing useful is silently discarded.
How you use it in an app
Two calls, around your model, with that key:- After the user speaks — create the message. Actx0 extracts memory.
- Before you generate a reply — fetch the prompt, search memories (and knowledge if the question is about your docs), then put the best hits in the prompt.
Scope search to the right session. Memories belong to one agent session — they do not leak across users, tickets, or agents unless you put them in the same session.
Why knowledge exists
Memory answers “what did this user tell us?” Knowledge answers “what is true in our docs?” Without a knowledge layer, teams paste FAQs and policies into every prompt, or they let the model guess. That wastes tokens and drifts from the real document. Actx0 knowledge is workspace RAG: upload a.txt or .md file once, Actx0 chunks and indexes it, and any agent in the workspace can search for matching passages.
Before a reply that should cite a policy, search knowledge with the user’s question and put the scored chunks next to the memories. Do not dump the whole file into the prompt.
Indexing is asynchronous. Search only returns documents that have finished (
indexed). See Knowledge for upload, labels, and search.
Why prompts are versioned
The system prompt is part of the product. If it lives only in your repo, a copy change means a deploy, and a bad edit has no rollback. Actx0 stores prompts as versioned templates in the workspace. You edit them in the dashboard or API. At runtime your app fetches by handle —latest for staging, production for live traffic, or a specific version like v3. Actx0 does not run the model; you substitute variables such as {{user_name}}, then send the text along with memories and knowledge hits.
Promote a version when it is ready. Only one version is production at a time. See Prompts for handles, types, and fetch-by-name.
Access keys
Dashboard login is for people. Agents and servers use a workspace access key. Create one in Settings → Access keys. You choose a name and permissions (messages, memories, knowledge, prompts, and so on). The secret is shown once; send it asX-Access-Key from the SDK, REST, or MCP. Keep it on the server — never in a browser or a committed config.
Use a different key per environment or integration, and grant only the permissions that integration needs. If a key leaks, delete it and issue a new one.
Next steps
Quickstart
Create an access key and store your first memory
Agents
Sessions, messages, and how to scope a conversation
Knowledge
Upload documents and retrieve grounded chunks
Prompts
Versioned templates with production labels
MCP
Memory tools for Cursor and other MCP clients
API Reference
Full REST surface for every resource