d7db9c667d
## RFC 0048 Expert Pool Implementation - Added tiered expert pools (Core/Adjacent/Wildcard) to dialogue handlers - Implemented weighted random sampling for panel selection - Added blue_dialogue_sample_panel MCP tool for manual round control - Updated alignment-play skill with pool design instructions ## New RFCs - 0044: RFC matching and auto-status (draft) - 0045: MCP tool enforcement (draft) - 0046: Judge-defined expert panels (superseded) - 0047: Expert pool sampling architecture (superseded) - 0048: Alignment expert pools (implemented) - 0050: Graduated panel rotation (draft) ## Dialogues Recorded - 2026-02-01T2026Z: Test expert pool feature - 2026-02-01T2105Z: SQLite vs flat files - 2026-02-01T2214Z: Guard command architecture ## Other Changes - Added TODO.md for tracking work - Updated expert-pools.md knowledge doc - Removed deprecated alignment-expert agent - Added spikes for SQLite assets and SDLC workflow gaps Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
102 lines
3.3 KiB
Markdown
102 lines
3.3 KiB
Markdown
# 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.
|