Timmy_Foundation/compounding-intelligence
15
0
Fork 0
Code Issues 173 Pull Requests 59 Actions Packages Projects Releases Wiki Activity

[ATLAS][Research] Solve the swarm-memory gap for concurrent subagents #232

New Issue
Open
opened 2026-04-23 12:12:45 +00:00 by Rockachopa · 1 comment
Rockachopa commented 2026-04-23 12:12:45 +00:00
Owner
Copy Link

Parent

Timmy_Foundation/hermes-agent#984

Motivation

The pasted stack calls out the real unresolved problem correctly: session memory is one thing, swarm memory is another.

We already have memory work underway. This issue isolates the next problem: what memory semantics should exist across many concurrent subagents so they can cooperate without corrupting each other or losing important results?

What

Research and prototype a swarm-memory architecture for parallel agent work.

Focus areas:

  • shared vs private memory for subagents
  • append-only event logs vs mutable shared state
  • conflict handling and evidence preservation
  • checkpointing, lineage, and replay
  • what must be promoted from subagent-local to durable/global memory

Tasks

  • Write a design note framing the swarm-memory problem in our stack
  • Evaluate at least 2 candidate designs (for example append-only event log + synthesis, or shared board + evidence links)
  • Prototype one minimal swarm-memory path in a controlled parallel task setting
  • Measure whether the prototype improves multi-agent coordination or post-run recall
  • Document failure modes: duplication, contradiction, stale shared state, missing promotions

Acceptance Criteria

  • A design note exists that distinguishes session memory from swarm memory clearly
  • At least 2 candidate swarm-memory designs are compared with trade-offs
  • A prototype is exercised in a parallel multi-agent task, not just described abstractly
  • The resulting report says whether this should move to implementation now, later, or not at all
  • Failure modes and containment boundaries are explicit
## Parent Timmy_Foundation/hermes-agent#984 ## Motivation The pasted stack calls out the real unresolved problem correctly: **session memory is one thing, swarm memory is another**. We already have memory work underway. This issue isolates the next problem: what memory semantics should exist across many concurrent subagents so they can cooperate without corrupting each other or losing important results? ## What Research and prototype a swarm-memory architecture for parallel agent work. Focus areas: - shared vs private memory for subagents - append-only event logs vs mutable shared state - conflict handling and evidence preservation - checkpointing, lineage, and replay - what must be promoted from subagent-local to durable/global memory ## Tasks - [ ] Write a design note framing the swarm-memory problem in our stack - [ ] Evaluate at least 2 candidate designs (for example append-only event log + synthesis, or shared board + evidence links) - [ ] Prototype one minimal swarm-memory path in a controlled parallel task setting - [ ] Measure whether the prototype improves multi-agent coordination or post-run recall - [ ] Document failure modes: duplication, contradiction, stale shared state, missing promotions ## Acceptance Criteria - [ ] A design note exists that distinguishes session memory from swarm memory clearly - [ ] At least 2 candidate swarm-memory designs are compared with trade-offs - [ ] A prototype is exercised in a parallel multi-agent task, not just described abstractly - [ ] The resulting report says whether this should move to implementation now, later, or not at all - [ ] Failure modes and containment boundaries are explicit
Rockachopa commented 2026-04-24 19:59:20 +00:00
Author
Owner
Copy Link

🔥 BURN DISPATCH — BURN:COUNCIL.2

Queued with /queue.

Target branch: fix/232-swarm-memory-research
Focus: research and prototype swarm memory for concurrent subagents with explicit trade-offs and failure modes.

🔥 **BURN DISPATCH** — `BURN:COUNCIL.2` Queued with `/queue`. Target branch: `fix/232-swarm-memory-research` Focus: research and prototype swarm memory for concurrent subagents with explicit trade-offs and failure modes.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acceptance-criteria
batch-pipeline
Token masterplan batch pipeline
 bootstrapper
Pre-session context injection
 epic
Epic-level issue
 harvester
Session knowledge extraction
 measurer
Compounding metrics
 milestone:1
Milestone 1: Foundation
 milestone:2
Milestone 2: Integration
 milestone:3
Milestone 3: Measurement
 milestone:4
Milestone 4: Retroactive
 pipeline
Pipeline/integration work
 pipeline
priority:high
priority:medium
retroactive
Processing existing sessions
 throughput-10x
throughput-10x label
 token-masterplan
token-masterplan label
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Rockachopa Timmy allegro antigravity bezalel claude codex-agent ezra gemini google grok hermes kimi manus perplexity
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Timmy_Foundation/compounding-intelligence#232
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?