ValorIDE Memory Integration

ValorIDE uses GrayMatter as its durable memory layer so sessions do not start cold. Local memory remains useful for offline and repo-scoped context, while GrayMatter provides shared user, organization, and project memory.

ValorIDE is also a SWARM agent. It should discover the Valhalla control surface through /v1/graymatter/control, then use /v1/swarm-ops/register for live agent presence. SwarmOps is coordination state; ValorIDE memory reads and writes remain GrayMatter MemoryEntry operations.

Memory Tiers

Tier	Storage	Scope	Role
Local memory bank	.valoride/memorybank/	Project	Offline and repo-committed context
VS Code global state	Extension storage	Machine/user	Local continuity
GrayMatter	ThorAPI/HTTP + MCP	User, organization, project	Durable shared memory

Runtime Behavior

ValorIDE should:

• load /v1/graymatter/control to discover the GrayMatter, RBAC object graph, SwarmOps, and Agent endpoint contract
• query relevant GrayMatter memories before building LLM context
• inject memory alongside project files, diagnostics, and local memory bank content
• write important decisions, preferences, and conventions after tasks complete
• register as a live SWARM agent before accepting coordinated work
• degrade gracefully if GrayMatter auth or network access fails

Scopes

Use memory scope intentionally:

• user: personal preferences and response style
• organization: team-wide standards and architecture decisions
• project: repository conventions, domain vocabulary, and implementation constraints

MCP Integration

GrayMatter should be available as a built-in MCP server so local agents and swarm workers can use memory tools directly. MCP access should preserve normal approval, identity, and scoping rules.

Related:

• ValorIDE Operations: Command Execution
• GrayMatter Memory Fabric
• Valhalla Control Surface
• Swarm Protocol