feat: Conversation history / session memory architecture #236
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Competitor
Kind/Documentation
Kind/Enhancement
Kind/Epic
Kind/Feature
Kind/Security
Kind/Story
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Scope/Core
Scope/Cross-Plugin
Scope/Plugin-System
Scope/Single-Plugin
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ultanio/cobot#236
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
Cobot's conversation memory across messages is currently handled by the persistence plugin via
loop.transform_history. It stores messages per-peer and injects prior turns into the LLM context. The compaction plugin can summarize old history to save tokens.However, this has limitations that need addressing as we build toward richer agent interactions (ledger, cortex, lurker):
Current State
[system_prompt, current_message]— zero memoryOpen Questions
Token efficiency — LLMs with prompt caching (Anthropic, OpenAI) make conversation history cheap if the prefix is stable. Are we taking advantage of this? The system prompt + history prefix should be cache-friendly.
Session boundaries — What defines a "session"? Currently it's per-peer, unbounded. Should sessions expire? Should there be explicit session start/end?
History vs. context — The persistence plugin stores raw message turns. But richer context (ledger peer data, cortex beliefs, tool results) also shapes the conversation. How do these interact? The
context.historyextension point exists but nothing implements it.Scalability — Per-peer JSON files work for small-scale. What happens with 50 peers and 1000 messages each?
Cross-plugin coordination — Both
loop.transform_history(persistence, compaction) andloop.transform_system_prompt(soul, ledger, cortex) modify what the LLM sees. Is the ordering well-defined? Are there conflicts?Cache-friendly prompt structure — For LLMs with input caching, the message prefix (system prompt + history) should change as little as possible between calls. Are we structuring messages to maximize cache hits?
Why This Matters Now
All of these depend on a well-defined conversation memory architecture.
Proposal
Create a PRD that covers:
loop.transform_historyandcontext.historyextension pointsThis is a prerequisite for several in-flight features and should be discussed before more plugins build their own history assumptions.
Filed by Doxios 🦊 at David's request