Memory
## Architecture Decisions - Pending Discussion ### 1. Agent Topology - **Option A**: One `Think` agent with system prompt switching behavior based on context/tools. Simpler, one thread history. - **Option B**: One parent agent delegating to child agents via Facets/RPC. Each role gets own session/memory. More complex but properly isolated. - **Option C**: Separate standalone agents, each with own Durable Object. Switch between them in UI (like workspaces). ### 2. Voice & RTK - **In v1**: Voice mode and video calls from day one - **Deferred**: Get core chat + tools working first, add voice/RTK as follow-up phases ### 3. Thread Scope - **Option A**: Different conversations within same agent role (like ChatGPT threads) - **Option B**: Different agent roles (a "Research" thread vs a "Coding" thread) - **Option C**: Both (threads are per-role, with role switcher) ### 4. Memory Architecture - **Think workspace files**: Agent reads/writes files in its workspace (built-in) - **Shared D1 database**: Cross-session memory across all agent instances - **Both**: Think workspace for working memory, D1 for long-term knowledge base ### 5. Coordination Tool Integration - What inputs it takes (task description? repo path?) - What it outputs (plan? parallel tasks?) - How it connects to other agents (API call? MCP? direct integration) [Update 7/4/2026]: ### DECISION: Agent Topology → Option C (Standalone Agents) - Each agent role is a separate `Think` instance with its own Durable Object - UI switches between agents (like workspaces) - Cross-agent task assignment via Mike's coordination tool - No built-in parent/child relationship between agents [Update 7/4/2026]: ### DECISION: Voice & RTK → Hybrid (Voice in v1, RTK in v2) - Voice conversations are part of v1 using `@cloudflare/voice` - RTK (video/calls) deferred to v2 - RTK use case: Quick video call with client/friend, agent joins by voice to take notes or chat - Prebuilt RTK apps already support this pattern - RTK is not as complex as assumed - Design streaming architecture to accept voice input without shipping full video stack [Update 7/4/2026]: ### DECISION: Thread Scope → Separate Workspaces with Threads (multi-workspace) - Each agent is a separate workspace with its own thread list - Ability to have multiple workspaces open simultaneously - Jump between workspaces without losing context - Thread list is per-workspace, not global [Update 7/4/2026]: ### DECISION: Memory Architecture → Second-Brain as Shared Memory - Use existing second-brain (Cloudflare-based) as the shared memory layer across all agents - Think workspace files remain for ephemeral working state per agent - Second-brain provides cross-agent knowledge persistence (facts, decisions, context) - Agents use prompts to ensure they read/write to second-brain appropriately - No need to build a new D1-based shared memory layer [Update 7/4/2026]: ### DECISION: Coordination Tool → Todomator (Total.js App) - Todomator is a Total.js-based task/project management system - API endpoints: tickets (CRUD), folders, tags, comments, time tracking, bookmarks, file attachments - Ticket statuses: pending, open, review, postponed, closed - Features: priorities, deadlines, user assignments, watchers, notifications, WebSocket real-time updates - Integration plan: Cloudflare Worker wrapping Todomator API as MCP server - Location: C:\docuclear\todomator - Each agent connects to Todomator MCP server to create/assign/update tasks [Update 7/4/2026]: ### Additional Tool: OpenFiles - Location: C:\docuclear\openfiles - Integration: Cloudflare Worker wrapping API as MCP server - Purpose: File operations across agents (details TBD) - Agent access: All workspaces via MCP
Tags: project-amy, architecture, pending-decisions, project:amy, kind:semantic — Source: claude — 2026-07-04 10:22:15 UTC