Architecture Decision Records
Every significant architectural decision in the Memory Platform is documented as an ADR. These records capture context, alternatives considered, and the rationale behind each choice.
11
Accepted
1
Proposed
12
Total
Why a Memory Platform?
Establishes the rationale for a dedicated memory platform separate from model inference. Covers state management, cross-session continuity, and the limitations of stateless LLM APIs.
Read full ADR →Why a Single API?
Proposes a unified API gateway for all provider interactions. Eliminates provider lock-in, standardizes request/response schemas, and simplifies client integration.
Read full ADR →Why a Provider Adapter?
Introduces the adapter pattern for multi-provider support. Each provider implements a common interface, enabling seamless switching between OpenAI, Anthropic, Google, and local models.
Read full ADR →Why an Event Bus?
Adopts an event-driven architecture for inter-agent communication. Decouples components, enables asynchronous workflows, and supports multi-agent coordination at scale.
Read full ADR →Why Mem0 and Honcho?
Evaluates memory backends and selects Honcho for production with Mem0 as a lightweight alternative. Compares performance, scalability, and operational complexity.
Read full ADR →Why a Context Builder?
Defines the context builder component that assembles prompts from memory, system instructions, and conversation history. Enables structured context assembly with token budgeting.
Read full ADR →Why a Policy Engine?
Introduces a policy engine for governance — PII redaction, content filtering, access control, and compliance rules enforced before data reaches models or memory.
Read full ADR →Why a Monorepo?
Selects a monorepo structure for the platform. Single source of truth for shared types, unified versioning, simplified CI/CD, and easier cross-component refactoring.
Read full ADR →Why In-Process Event Bus?
Supersedes ADR-004 for single-process deployments. An in-process event bus eliminates network overhead while preserving the event-driven pattern for simpler setups.
Read full ADR →Why a Context Budget?
Formalizes context budget management — allocating token limits per request, preventing context overflow, and dynamically adjusting budgets based on task complexity.
Read full ADR →Archive Role
Defines the archive role for long-term storage management. Handles data retention policies, compaction schedules, and lifecycle transitions across memory tiers.
Read full ADR →ADR-011 (Pending)
Reserved for an upcoming architectural decision. The numbering gap will be filled as the platform evolves.