Memory

Memory stores are per-workspace named buckets of string items that AI agents can read and write at runtime via MCP tools. Memory persists across sessions — useful for capturing project conventions, recurring decisions, and team knowledge that should follow every agent run.

Why memory matters

Without memory, every session starts cold:

• Agents re-discover project conventions from scratch
• Recurring decisions ("we always use X for Y") have to be re-stated every prompt
• Lessons learned in one session are lost the moment it closes

Memory turns those repeated facts into persistent context that agents can pull on demand.

Stores

A memory store is a named bucket scoped to a workspace. Typical stores:

• conventions — coding standards the agent must follow
• decisions — architectural choices and their rationale
• gotchas — known traps in the codebase
• glossary — domain terms and their meaning

You can create as many stores as you like.

Operations

• Create Store — add a new named bucket
• Delete Store — remove a store (and all its items)

Items

A memory item is a single string content entry inside a store, with full audit metadata (who created it, when, last updated, etc.). Items are intentionally constrained to plain strings — no nested objects, no binary data — so that agents can reason about them as facts and so that stores stay searchable.

Operations

• Create Item — add an entry
• Update Item — edit content
• Delete Item — remove a single item
• Bulk Delete — remove many at once

MCP tools (agent-accessible)

Agents read and write memory via three MCP tools exposed by Polygent's built-in MCP server:

Tool	Purpose
get_memory_items	Read items from a store
add_memory_items	Batch-add new items
remove_memory_items	Batch-remove items

Any MCP-compatible agent (Polygent Code, Claude Code, Gemini CLI, OpenCode, Kilo CLI, Codex, Qwen Code) can call these tools without extra setup.

When agents should use memory

Train your agents (via system prompt or workspace prompt) to:

• Read relevant stores at the start of a task
• Add new items when they discover a project convention or decision worth keeping
• Update items when an existing rule changes

Filtering and search

The Memory page supports:

• Workspace filter
• Store filter
• Text search across item content
• Pagination for large stores

Permissions

Permission	Capability
memory.view	Read memory stores and items
memory.manage	Create / update / delete stores and items

Agents themselves do not need these permissions — they call MCP tools that operate on behalf of the workspace.

Examples

Stop re-explaining conventions Create a conventions store with items like "Use the shared Button component, never raw HTML buttons" and "All API errors must throw, never return error objects." Train your agents (via the workspace prompt) to read it at the start of every task — new sessions follow house style without being told each time.

Record a tricky decision once After a session settles on "we store timestamps as UTC and convert in the client," add that to a decisions store. The next agent that touches dates reads the decision instead of re-litigating it.

Warn agents about a known trap A gotchas store item — "the legacy sync() call blocks the event loop; use syncAsync()" — saves every future session from re-discovering the same footgun.

Tips for good memory hygiene

• Keep items atomic — one fact per item makes search and removal cleaner
• Prefer declarative statements: "Use TypeScript strict mode" beats "Don't use loose mode"
• Date time-sensitive items so they can be deprecated cleanly
• Periodically review stores to remove stale or contradictory items