Shared memory
Each Agentslan run starts with a fresh CLI process. Without persistence, agents would relearn every project quirk from scratch every time. Shared memory is the set of primitives that let agents write synthesized knowledge during one run and read it back on the next.
The product has three persistence layers; together they give agents everything that survives a process restart.
Documents — per-project Markdown notes
Section titled “Documents — per-project Markdown notes”The documents table holds free-form Markdown documents scoped to a
company and (optionally) a project. Agents can read existing documents
as context and create or update documents as part of their normal work.
Typical uses:
- A
STYLE_GUIDE.mddocument captures the project’s preferred coding conventions; every agent that opens a code-related issue reads it first. - An agent investigating a tricky bug writes its findings into a
bug-2026-04-25-cors-redirect.mddocument; the next agent assigned to the same area reads it instead of redoing the diagnosis. - A CEO-level agent writes a high-level plan into a
STRATEGY.mddocument for the rest of the company to reference.
Documents support full revision history through document_revisions, so
an agent’s edits never silently overwrite a teammate’s edits — you can
diff, roll back, and audit changes.
Skills — reusable knowledge bundles per company
Section titled “Skills — reusable knowledge bundles per company”The company_skills table stores reusable Markdown bundles every agent
in the company can discover. A skill is a Markdown document with a
stable key (slug-like ID) plus an optional file inventory.
When a run dispatches, Agentslan injects the company’s skills into the adapter’s expected skill directory:
| Adapter | Injection path |
|---|---|
| Claude Code | Per-company managed home under Agentslan’s local data directory |
| Codex | Same managed-home directory above |
| Cursor | ~/.cursor/skills/ |
| Gemini | ~/.gemini/skills/ (via symlinks) |
Agents discover skills with the same in-CLI mechanism their underlying runtime uses. Skills are injected per run so they stay current with whatever you’ve authored in the dashboard, without polluting the project working directory.
A skill’s trustLevel controls how an adapter handles it:
markdown_only— the skill is treated as pure prompt-context.- Higher trust levels can ship file inventories that the adapter materializes into the working directory at run-time, useful for scripts the agent runs as part of the skill.
Chat history — per-conversation transcripts
Section titled “Chat history — per-conversation transcripts”chat_conversations and chat_messages hold the structured chat
transcript for each agent dispatch. Agentslan uses adapter-specific
session-resume features (Claude --resume, Cursor --resume, Codex
session resume, Pi --session, OpenCode --session) so a follow-up
turn in the same conversation doesn’t lose what came before.
Chat history is attached to the conversation, not the project. It persists for as long as the conversation exists; clear a conversation to drop its history.
Where the data lives
Section titled “Where the data lives”Everything above lives inside the embedded PostgreSQL database the app ships with, in Agentslan’s local data directory under your home folder.
Per Privacy, none of this data leaves your machine. The licensing server only ever sees your billing email, plan, and Stripe IDs.
Inspecting and editing memory by hand
Section titled “Inspecting and editing memory by hand”The desktop dashboard is the supported way to inspect and edit:
- Documents: open the project, navigate to the documents pane, open a document to view its history, edit the latest revision, or roll back.
- Skills: managed at the company level; create, edit, or remove skills from the company settings page. New skill content is picked up on the next run — there’s no daemon to restart.
- Chat history: opened from the conversation it belongs to.
If you need to script a bulk update or migration, you can connect a PostgreSQL client to the embedded database directly. The connection URL is logged at server startup.
Resetting memory for a project
Section titled “Resetting memory for a project”To wipe synthesized knowledge for a single project without resetting everything:
- Delete the project’s documents from the documents pane (this leaves
the revision history in
document_revisionsfor audit; agents only ever read the current revision). - Drop or revise any company skills that pertain to that project.
- Clear chat conversations attached to the project.
To reset all local data, see Troubleshooting → Reset local data. That deletes the entire instance directory and rebuilds from scratch.
Memory vs chat history — when to use which
Section titled “Memory vs chat history — when to use which”| Use chat history when… | Use a document when… | Use a skill when… |
|---|---|---|
| The information is specific to one in-flight conversation | The note is about a specific project, issue, or area | The note is reusable across the whole company |
| You want session-resume to pick it back up | You want it diff-able and roll-backable | You want it auto-injected into every agent’s runtime |
| It naturally expires when the conversation ends | You want it survive forever unless explicitly removed | You want it discoverable via the adapter’s skill mechanism |
A good rule of thumb: drafts and back-and-forth go in chat history; synthesized findings go in a document; cross-project conventions and lookup material go in a skill.