RFC: Dewey as the unified embedding and semantic memory layer (replacing direct Ollama dependency)

[jflowers]

Context

Issue #73 identified that Ollama server lifecycle management causes silent degradation across three tools:

• Dewey — embedding generation for semantic search
• Hivemind (Swarm) — embedding generation for semantic memory
• Swarm — embedding-based file similarity

All three independently call the same Ollama HTTP API at localhost:11434. If Ollama isn't running, all three fail independently with different error messages.

The Observation

Currently the architecture looks like this:

                    ┌─────────────┐
                    │   Ollama    │ ← user must start manually
                    │ :11434      │
                    └──────┬──────┘
                           │ HTTP API
              ┌────────────┼────────────┐
              │            │            │
        ┌─────┴─────┐ ┌───┴───┐ ┌──────┴──────┐
        │   Dewey   │ │ Swarm │ │  Hivemind   │
        │ (embedder)│ │(embed)│ │ (embedder)  │
        └───────────┘ └───────┘ └─────────────┘

Three tools, one dependency, zero coordination.

Proposed Architecture

What if Dewey became the single embedding and semantic memory service for the entire swarm?

                    ┌─────────────┐
                    │   Ollama    │
                    │ :11434      │
                    └──────┬──────┘
                           │ HTTP API (managed by Dewey)
                    ┌──────┴──────┐
                    │   Dewey    │ ← single embedding + memory service
                    │ (MCP svr)  │
                    └──────┬──────┘
                           │ MCP tools
              ┌────────────┼────────────┐
              │            │            │
        ┌─────┴─────┐ ┌───┴───┐ ┌──────┴──────┐
        │  Agents   │ │ Swarm │ │  /unleash   │
        │(semantic  │ │(task  │ │(retrospect  │
        │ search)   │ │decomp)│ │  learnings) │
        └───────────┘ └───────┘ └─────────────┘

Three changes:

1. Dewey owns the Ollama lifecycle

When dewey serve starts, it checks if Ollama is running. If not, and ollama is in PATH, Dewey auto-starts it as a managed subprocess. This eliminates the "installed but not serving" problem entirely. Only Dewey needs to know about Ollama — everyone else just calls Dewey.

2. Dewey provides semantic memory storage

Instead of Hivemind's hivemind_store/hivemind_find calling Ollama directly, Dewey gets new MCP tools:

• dewey_store_learning — store a learning with tags and metadata (source: learning, not disk/github/web)
• Existing dewey_semantic_search already finds them — learnings are just another document type in the index

Learnings persist in graph.db across sessions, are searchable alongside specs and code, and benefit from Dewey's existing embedding infrastructure.

3. Swarm's Hivemind becomes a thin proxy (or is deprecated)

Instead of Hivemind maintaining its own embedding pipeline and storage, it delegates to Dewey. Or, the /unleash retrospective step and Divisor "Prior Learnings" step call Dewey tools directly instead of Hivemind.

Benefits

Current	Proposed
3 tools call Ollama independently	1 tool (Dewey) manages Ollama
Silent degradation in 3 places	Single point of failure with clear diagnostics
Hivemind learnings in separate store	Learnings in Dewey's persistent index, searchable alongside specs
hivemind_store + hivemind_find + dewey_semantic_search + dewey_search (4 tools, overlapping)	dewey_store_learning + dewey_semantic_search (2 tools, unified)
User must run ollama serve manually	Dewey auto-starts Ollama if needed

Constitution Alignment

• I. Autonomous Collaboration: Dewey produces self-describing artifacts (indexed documents with provenance). Other tools consume via MCP tools. No runtime coupling beyond the MCP protocol.
• II. Composability First: Dewey remains independently installable. If Dewey isn't available, tools fall back to their current behavior (direct Ollama or no embeddings).
• III. Observable Quality: Single embedding service means single health check point. dewey doctor or uf doctor checks one thing instead of three.
• IV. Testability: Dewey's embedding API is already testable (embed_test.go). Adding learning storage follows the same patterns.

Open Questions

1. Ollama auto-start: Should Dewey start Ollama as a subprocess, or is this too invasive? Could conflict with user-managed Ollama instances with custom GPU/model configs.

2. Hivemind migration: Should Hivemind be deprecated in favor of Dewey, or should Hivemind become a thin proxy that calls Dewey under the hood? The Swarm plugin author may have opinions.

3. Learning schema: What metadata should dewey_store_learning accept? Tags, branch name, date, category (pattern/gotcha/review-insight/file-specific) — matching the current Hivemind pattern?

4. Backward compatibility: Existing Hivemind learnings stored via hivemind_store — should Dewey import them, or start fresh?

5. Scope: Is this a single Dewey spec, or does it need coordinated changes across Dewey + Swarm + unbound-force repos?

Related

• Issue Ollama server lifecycle: installed but not serving causes silent degradation across Hivemind, Dewey, and Swarm #73: Ollama server lifecycle causes silent degradation
• Spec 014: Dewey Architecture (FR-014 web crawl source, FR-011 pluggable content sources)
• Spec 020: Dewey Knowledge Retrieval (behavioral instructions for agents)
• Spec 019: Divisor Council Refinement (Prior Learnings step uses hivemind_find)

Invitation

This is an RFC — looking for feedback on the architectural direction before specifying. Key questions:

• Does consolidating embedding infrastructure in Dewey make sense?
• Should Dewey auto-start Ollama, or is there a better approach?
• What happens to Hivemind?
• Is the learning storage concept (documents with source_type: learning) the right abstraction?

[jflowers]

Refined Direction (2026-03-30)

After further discussion, here's the refined architectural direction:

Decisions Made

1. One spec covers everything: Dewey changes (Ollama lifecycle, learning storage) + unbound-force changes (agent migration) + Swarm fork -- all in one strategic Speckit spec.

2. Dewey per repo, not per machine: Each repo has its own dewey serve. First instance to start Ollama wins. Ollama is left running on exit (other consumers may need it). No complex multi-repo coordination layer.

3. Start fresh on learnings: No Hivemind data migration. New learnings go to Dewey from day one.

4. Hard fork Swarm: The Swarm plugin will be forked into the unbound-force organization. Anything UF needs is controlled by UF. The fork includes modifying Hivemind to route through Dewey (or deprecating it entirely).

5. Ollama lifecycle: When dewey serve starts, it checks :11434. If Ollama isn't running and ollama is in PATH, Dewey starts it as a managed subprocess. If a user-started Ollama is already running, Dewey uses it without touching it. On dewey serve exit, Ollama is left running.

The Needle-Moving Insight

The key value isn't just fixing Issue #73 (Ollama lifecycle). It's unified semantic memory:

• Today: Hivemind stores learnings in one place, Dewey indexes specs/code in another. Two searches needed, results don't cross-pollinate.
• Tomorrow: One dewey_semantic_search query returns specs + code + web docs + learnings, all ranked by relevance. A learning about scaffold.go appears alongside the scaffold spec and Go stdlib docs.

This makes every agent smarter with every session. The swarm accumulates project-specific wisdom that persists across sessions, repos, and team members.

Scope Summary

Component	Change
Dewey repo	Ollama lifecycle management in dewey serve, new dewey_store_learning MCP tool, learning storage in graph.db
unbound-force repo	/unleash retrospective to Dewey, Divisor Prior Learnings to Dewey, AGENTS.md update
Swarm fork	Fork into unbound-force/swarm, modify Hivemind to proxy through Dewey (or deprecate)
uf CLI	uf doctor checks Dewey health instead of raw Ollama, uf setup installs forked Swarm

Spec will be created as 021-dewey-unified-memory on the unbound-force meta repo.

[jflowers]

Implementation Tracking (2026-03-30)

Fork

Swarm plugin forked: unbound-force/swarm-tools (from joelhooks/swarm-tools)

Issues Filed

Phase	Repo	Issue	Title	Depends On
1	dewey	#24	Auto-start Ollama when dewey serve launches (FR-001–FR-006)	—
1	dewey	#25	Add dewey_store_learning MCP tool (FR-007–FR-011)	dewey#24
2	unbound-force	#76	Migrate /unleash and Divisor agents from Hivemind to Dewey (FR-012–FR-015)	dewey#24, dewey#25
2	unbound-force	#77	Update uf doctor and uf setup (FR-019–FR-021)	#76, swarm-tools#1
3	swarm-tools	#1	Deprecate Hivemind in favor of Dewey (FR-016–FR-018)	dewey#25
3	swarm-tools	#2	Verify all non-Hivemind tools work after fork (FR-017)	—

Execution Order

Phase 1 (Dewey repo — prerequisite)
  dewey#24: Ollama lifecycle ──────┐
  dewey#25: Learning storage ──────┤
                                    │
Phase 2 (Meta repo — main work)    │
  uf#76: Agent migration ◄─────────┘
  uf#77: Doctor/setup updates ◄──── uf#76 + swarm-tools#1
                                    │
Phase 3 (Swarm fork — final)       │
  swarm-tools#2: Verify fork ◄─────┘ (can run in parallel)
  swarm-tools#1: Deprecate Hivemind ◄── dewey#25

Spec Branch

Full spec artifacts on branch 021-dewey-unified-memory (spec.md, plan.md, tasks.md, data-model.md, research.md, quickstart.md). Spec review passed (5/5 Divisor personas APPROVE). Implementation deferred until Phase 1 lands.