> ## Documentation Index
> Fetch the complete documentation index at: https://docs.actx0.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Overview
> How Actx0 works: memory extraction, knowledge, prompts, and access keys.
## 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).
```text theme={null}
Workspace
├── Access keys, prompts, knowledge
└── Agents
└── Sessions
├── Messages ← the conversation
└── Memories ← extracted facts
```
***
## Messages vs memories
A message is a turn in the conversation. A memory is a short, durable fact taken from that conversation.
| User says | Stored memory |
| --------------------------------------------------------- | ------------------------------------------ |
| `"I prefer aisle seats"` | `User prefers aisle seats` |
| `"We're switching the billing email to finance@acme.com"` | `User's billing email is finance@acme.com` |
| `"Hi, can you help?"` | Nothing — greetings are skipped |
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.
Your app (or MCP client) POSTs the turn into a session. Actx0 saves it and indexes the text for search.
A model looks at the user text only — not the full transcript — and asks: is there anything worth remembering later?
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).
The new memory is searchable, the same way you search messages and knowledge.
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.
That whole path is asynchronous. The create-message call returns as soon as the turn is stored. Memories show up shortly after.
If you need to rebuild from scratch, regenerate memories from the session's user messages. That deletes current memories and runs extraction again.
***
## How you use it in an app
Two calls, around your model, with that key:
1. **After the user speaks** — create the message. Actx0 extracts memory.
2. **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.
| | Memories | Knowledge |
| ------- | --------------------------------- | --------------------------------------------- |
| Answers | What this person said or prefers | What your company wrote down |
| Scope | One agent session | The whole workspace |
| Source | Chat extraction or a direct write | Uploaded documents |
| Example | `User prefers dark mode` | Refund policy, onboarding guide, product spec |
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](/platform/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](/platform/prompt) 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](https://app.actx0.com/settings). You choose a name and permissions (messages, memories, knowledge, prompts, and so on). The secret is shown **once**; send it as `X-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
Create an access key and store your first memory
Sessions, messages, and how to scope a conversation
Upload documents and retrieve grounded chunks
Versioned templates with production labels
Memory tools for Cursor and other MCP clients
Full REST surface for every resource