ZacharyZhang-NY
86aa6fdb29
Skills no longer come from the user's ~/.agents library - most users have none, and the CEO branch that compiled the entire catalogue into its prompt overflowed the model context (1.1MB) and failed every CEO run. - Bundle "built-in skills/" with the app (extraResources) and stage it at startup into <profile>/builtin-skills as one dir-per-skill copy - both bundle shapes (SKILL.md dirs and flat category .md files) normalize into the same importable layout - Import the staged catalogue per org at startup and inside onboarding, so the CEO's first run already carries it - Forced house style: resolveRuntimeSnapshot unions the humanizer skill into every agent's runtime (CEO included) as a resolution rule - no binding row to forget, delete, or bypass; revoke_skill refuses it - CEO staffs hires with skills: hire_agent accepts a skills array, grant_skill/revoke_skill adjust later, list_skills now shows descriptions from skill frontmatter - Kill the c_suite compile-all branch; everyone resolves bindings-only, capped at 200k chars with omissions named in the prompt - Remove the Skills settings page and its import/sync/test IPC surface; drop ~/.agents discovery and the AGENTCOMPANY_NEW_SKILLS_ROOT seam in favor of AGENTCOMPANY_NEW_BUILTIN_SKILLS_DIR - Tests: staging/import/forced-resolution/cap units, real-bundle CI check, e2e asserts the tab is gone and the catalogue self-imports
80 lines
3.7 KiB
Markdown
80 lines
3.7 KiB
Markdown
# MCP Memory Integration
|
|
|
|
> Give any agent persistent memory across sessions using the Model Context Protocol (MCP).
|
|
|
|
## What It Does
|
|
|
|
By default, agents in The Agency start every session from scratch. Context is passed manually via copy-paste between agents and sessions. An MCP memory server changes that:
|
|
|
|
- **Cross-session memory**: An agent remembers decisions, deliverables, and context from previous sessions
|
|
- **Handoff continuity**: When one agent hands off to another, the receiving agent can recall exactly what was done — no copy-paste required
|
|
- **Rollback on failure**: When a QA check fails or an architecture decision turns out wrong, roll back to a known-good state instead of starting over
|
|
|
|
## Setup
|
|
|
|
You need an MCP server that provides memory tools: `remember`, `recall`, `rollback`, and `search`. Add it to your MCP client config (Claude Code, Cursor, etc.):
|
|
|
|
```json
|
|
{
|
|
"mcpServers": {
|
|
"memory": {
|
|
"command": "your-mcp-memory-server",
|
|
"args": []
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
Any MCP server that exposes `remember`, `recall`, `rollback`, and `search` tools will work. Check the [MCP ecosystem](https://modelcontextprotocol.io) for available implementations.
|
|
|
|
## How to Add Memory to Any Agent
|
|
|
|
To enhance an existing agent with persistent memory, add a **Memory Integration** section to the agent's prompt. This section instructs the agent to use MCP memory tools at key moments.
|
|
|
|
### The Pattern
|
|
|
|
```markdown
|
|
## Memory Integration
|
|
|
|
When you start a session:
|
|
- Recall relevant context from previous sessions using your role and the current project as search terms
|
|
- Review any memories tagged with your agent name to pick up where you left off
|
|
|
|
When you make key decisions or complete deliverables:
|
|
- Remember the decision or deliverable with descriptive tags (your agent name, the project, the topic)
|
|
- Include enough context that a future session — or a different agent — can understand what was done and why
|
|
|
|
When handing off to another agent:
|
|
- Remember your deliverables tagged for the receiving agent
|
|
- Include the handoff metadata: what you completed, what's pending, and what the next agent needs to know
|
|
|
|
When something fails and you need to recover:
|
|
- Search for the last known-good state
|
|
- Use rollback to restore to that point rather than rebuilding from scratch
|
|
```
|
|
|
|
### What the Agent Does With This
|
|
|
|
The LLM will use MCP memory tools automatically when given these instructions:
|
|
|
|
- `remember` — store a decision, deliverable, or context snapshot with tags
|
|
- `recall` — search for relevant memories by keyword, tag, or semantic similarity
|
|
- `rollback` — revert to a previous state when something goes wrong
|
|
- `search` — find specific memories across sessions and agents
|
|
|
|
No code changes to the agent files. No API calls to write. The MCP tools handle everything.
|
|
|
|
## Example: Enhancing the Backend Architect
|
|
|
|
See [backend-architect-with-memory.md](backend-architect-with-memory.md) for a complete example — the standard Backend Architect agent with a Memory Integration section added.
|
|
|
|
## Example: Memory-Powered Workflow
|
|
|
|
See [../../examples/workflow-with-memory.md](../../examples/workflow-with-memory.md) for the Startup MVP workflow enhanced with persistent memory, showing how agents pass context through memory instead of copy-paste.
|
|
|
|
## Tips
|
|
|
|
- **Tag consistently**: Use the agent name and project name as tags on every memory. This makes recall reliable.
|
|
- **Let the LLM decide what's important**: The memory instructions are guidance, not rigid rules. The LLM will figure out when to remember and what to recall.
|
|
- **Rollback is the killer feature**: When a Reality Checker fails a deliverable, the original agent can roll back to its last checkpoint instead of trying to manually undo changes.
|