Key facts
| Short-term memory | Conversation turns, tool results and task state held in the context window |
| Long-term memory | Durable facts and preferences written to an external store and read back by embedding search |
| Workspace memory | Project-scoped knowledge shared across sessions, with access controls |
| Building blocks | Live chat completions, function calling, embeddings and an agents API |
| Context handling | Long-context models keep more state inline; compare windows before choosing a strategy |
| Models | 30+ models; use cheap aliases for extraction and stronger ones for reasoning |
| Pricing model | Flat monthly self-serve plans with unlimited fair-use usage |
| Status | Chat, streaming, function calling, embeddings and agents are live |
TL;DR
- Separate the three tiers: context window, durable store, project scope.
- Write memory deliberately — extraction, not transcript dumping.
- Retrieve with embeddings and a relevance threshold, not everything at once.
- Add TTLs, deduplication and a delete path before you add scale.
- Plugsky provides the model and tool APIs; the memory store is yours to operate.
How it works, step by step
- Decide what belongs in each tier: task state in context, durable facts in the store, shared knowledge in the workspace.
- Define a write policy — which events trigger a memory write and which model extracts the fact.
- Embed and index memories with metadata: user, workspace, source, timestamp and sensitivity.
- Expose memory read and write as tools so the agent manages retrieval through function calling.
- Add TTLs, deduplication and conflict rules so stale or contradictory memories do not win.
- Instrument recall and precision, and prune memories that are never retrieved.
Try it yourself
The three memory tiers
Agent memory splits by lifetime and scope:
- Short-term: the current conversation, tool outputs and plan. It lives in the context window and disappears when the request ends.
- Long-term: facts worth keeping — user preferences, resolved issues, entity relationships. It lives in a database or vector store and survives sessions.
- Workspace: knowledge shared by everyone working in a project, such as conventions, schemas and decisions. It needs read and write access controls.
Most bugs blamed on 'the model forgetting' are actually missing persistence between these tiers.
Designing a memory policy
Memory is a data pipeline, so treat it like one. Write memories from a summarization or extraction call, not by dumping raw transcripts — raw logs bury the signal and inflate every future prompt. Store structured records with metadata so retrieval can filter by user, workspace and sensitivity before ranking by similarity. Set a relevance threshold and return a bounded number of memories. Define conflict resolution: newest wins, or highest-confidence wins, but never let two contradictory facts both retrieve.
Implementing memory on Plugsky
Build the loop from live endpoints. Use chat completions to extract facts after each session, plugsky-embed to index them, and function calling to expose remember and recall tools to the agent. The agents API provides session orchestration while your store keeps custody of the data. Cheap aliases such as plugsky-micro or plugsky-lite handle extraction; a stronger model handles reasoning over recalled context.
Common mistakes
- Keeping everything in the context window until the model degrades or the request fails.
- Writing every turn as a memory, then retrieving near-duplicates forever.
- No TTL, so outdated preferences outrank current ones.
- Storing secrets, tokens or personal data in a memory store with no deletion path.
- Retrieving by similarity alone, ignoring recency and workspace scope.
Each of these is cheaper to fix before launch than after an agent acts on stale context.
Honest comparison
| Memory tier | What it holds | Where it lives | Main failure mode |
|---|---|---|---|
| Short-term | Current task, turns, tool output | Context window | Window overflow or lost on restart |
| Long-term | Facts, preferences, outcomes | Vector store or database | Stale or contradictory facts |
| Workspace | Shared project knowledge | Scoped store with ACLs | Leaks across teams or projects |
| Summary buffer | Compressed history | Rolling summary in context | Drift and detail loss |
Frequently asked questions
What is AI agent memory?
The persistence layer that lets an agent carry state across steps and sessions: short-term context for the active task, long-term stores for durable facts, and workspace memory for shared project knowledge.
Do I need a vector database for agent memory?
Not always. Small agents can keep memory in a relational table and filter it into context. Move to embeddings and a vector index when the number of memories outgrows simple filters.
How should memories be written?
Through an explicit extraction step: after a session, a cheap model summarizes what is worth keeping into structured records with metadata. Avoid writing raw transcripts.
How does Plugsky help with memory?
Plugsky provides live chat completions, embeddings, function calling and an agents API. You choose and operate the memory backend, so custody and residency stay under your control.
How do I stop memory from going stale?
Give each memory a timestamp and TTL, prefer recent memories on conflict, and delete records that are never retrieved or explicitly superseded.
Can agents share memory across a team?
Yes, through workspace memory with read and write access controls. Scope it to the project and audit writes so one team's context does not leak into another's.