blue/.blue/docs/spikes/2026-01-31T0017Z-sqlite-alignment-dialogue-assets.done.md

Spike: Sqlite Alignment Dialogue Assets

Status	Complete
Date	2026-01-31
Time Box	1 hour

---

Question

Would storing alignment dialogue assets (round outputs, scoreboard, tensions, agent responses) in SQLite be faster than the current file-based approach?

---

Current Architecture

File-based storage in /tmp/blue-dialogue/<topic>/:

├── scoreboard.md           (~500 bytes, Judge writes)
├── tensions.md             (~1-2KB, Judge writes, agents read)
├── round-0.summary.md      (~1-2KB, Judge writes, agents read)
├── round-0/
│   ├── muffin.md           (~1.2KB, agent writes)
│   ├── cupcake.md          (~1.2KB, agent writes)
│   └── ... (6-12 agents)
└── round-1/...

Total per round: ~15-25KB

I/O Pattern Analysis

Operation	Who	Concurrency	Size
Write agent response	6-12 agents	Parallel (separate files)	1-1.5KB each
Read all agent files	Judge	Sequential	~10KB
Write scoreboard	Judge	Single	~500B
Write tensions	Judge	Single	~1-2KB
Write summary	Judge	Single	~1-2KB
Read context (next round)	Agents	Parallel	~5KB each

Bottleneck Analysis

Operation	Time
LLM inference per agent	30-60 seconds
File write	~1-5ms
File read	~1-5ms
All file I/O per round	~50ms total

The actual bottleneck is LLM inference, not file I/O. Even eliminating all file operations would save ~50ms on a 3-5 minute round.

SQLite Trade-offs

Potential Pros

• Single file instead of directory tree
• Transactional writes
• Queryable (find all tensions across all dialogues)
• Integration with existing blue-core SQLite db

Significant Cons

1. Subagents use Write tool → can't write to SQLite directly
   • Would need new MCP tools: blue_dialogue_write_response, blue_dialogue_read_context
   • Significant API surface increase
2. Parallel writes require careful handling
   • SQLite has write lock; 6-12 agents writing simultaneously would serialize
   • Would need WAL mode + careful transaction design
3. Files are trivially debuggable
   • cat, grep, less just work
   • SQLite requires tooling to inspect
4. No performance gain
   • Bottleneck is LLM, not I/O
5. More complexity for same result

The Real Problem

The current issue isn't file I/O speed. It's that subagents weren't reliably writing files because:

1. alignment-expert agent type had Write tool listed but wasn't using it
2. Switched to general-purpose agents which have full tool access

This was a tool reliability / prompting issue, not a storage architecture issue.

Conclusion

Don't do this. SQLite would add complexity without solving any real problem:

• Performance gain: negligible (~50ms on 3+ minute rounds)
• Debugging: harder (need SQLite tools vs cat/grep)
• Agent integration: would require new MCP tools
• Concurrency: more complex (SQLite write locks)

The file-based approach:

• Works with existing Write tool in Task agents
• Easily debuggable
• Naturally parallelizes (separate files)
• Matches how Claude Code agents already work

Recommendation

Keep file-based approach. The "fix" was using general-purpose subagents, not changing storage.