Lesson 3 introduced the four dispositions. This lesson walks the decision procedure end-to-end: the two questions you ask of every capability, why the same input can land on any of the four verdicts, and four worked examples — why the learning loop is a CLONE keystone, why the MCP client is a MERGE that's parked, why delegation is an IGNORE, and why neutts is an IGNORE for a different reason. This is the reusable framework for absorbing one system into another without bloating it. Source: docs/alembic-hermes-fusion-matrix.md.
For each capability of the source system, the matrix asks exactly two questions, each answered against verified map evidence (never from memory):
The disposition follows from the pair. It is, in effect, a 2×2:
Note the two IGNORE quadrants: a capability is dropped either because the target already does it better (delegation → the swarm) or because it's net-new but off-mission (neutts local TTS). Both are justified IGNOREs — the matrix requires a reason, never a shrug.
Q1: does Alembic have a closed self-improvement loop? The map answer: no — "learning loop/curator/background review = 0 hits." A genuine gap. Q2: is Hermes' version valuable? Yes — it is "the headline 'self-improving' mechanism and Alembic's biggest miss." Net-new + high value ⇒ CLONE. And not just any clone — the keystone, because it composes with what Alembic already has:
// docs/alembic-hermes-fusion-matrix.md §3 — the fusion, drawn from the matrix
Alembic today: SOURCE → distill (funnel) → Learnings + Signals → [no feedback]
Hermes adds: run → fork a memory/skill-only reviewer → write durable memory/skills
→ curator manages lifecycle → next run reads the refreshed snapshot
Fused: distill → Learnings ─┐
├─► memory/skills (frozen snapshot) → next run smarter
run → review fork ───┘ ▲ curator keeps it clean
It "composes with the validator gate rather than replacing it" — the reviewer's writes pass through Alembic's existing Validator Gate before they sediment (lesson 17), giving "learn only from validated wins." That is why it's the keystone: it turns a one-shot pipeline into a loop, using machinery Alembic already had. The CLONEs you studied in lessons 7–13 (memory, learning, curator, clarify, web) are exactly this quadrant.
Q1: does Alembic have MCP? Partially — it is an MCP server, read-only ("MCP=8 hits; harness handleMcpRequest"), but it has no client. Q2: net-new direction? Yes — consuming external MCP servers is a new capability. Partial equivalent + new direction ⇒ MERGE into @alembic/harness, not a separate package. But it is parked, not built: the implementation order lists it at #5 (Medium), after the five Easy CLONEs ship. MERGE is the verdict; the schedule defers it.
Q1: does Alembic delegate work to sub-agents? Emphatically yes — the swarm (lesson 19): "swarm=63 hits: 3-tier orchestrator, lead-worker, depth-bound, dependency-gated task-queue, PARL reward." Q2: is Hermes' delegate_tool.py (3188 LOC) better? No — Alembic "already does this natively and better." Equivalent exists and is superior ⇒ IGNORE. But the matrix still extracts one portable insight rather than discarding wholesale: keep async-delegation's "completion re-enters as a new turn, never mid-context" cache-safety rule. A good IGNORE harvests the one idea worth keeping.
This is the other kind of IGNORE. Q1: does Alembic have neural local TTS? No. Q2: is it net-new? Yes. So why not CLONE? Because it fails the mission test: "Python-only ML stack (neutts, espeak-ng). Hard to port, no mission value." Net-new is necessary but not sufficient — a capability also has to fit the target's mission and constraints. The same logic IGNOREs computer-use (binds a native runtime), the 23 messaging-platform adapters (Alembic is an internal engine, not a personal-assistant gateway), and the local faster-whisper path within an otherwise-ADAPTed media tool (lesson 13). Disposition is per-capability, and "net-new" never overrides "off-mission."
The whole point of the framework is to absorb a 30k-line agent into a focused TypeScript engine without importing its sprawl. CLONE only the net-new high-value pieces; MERGE what overlaps into one richer surface; IGNORE — with a reason — both what you already do better and what doesn't fit. The result is the @alembic/hermes package: five tight CLONE/ADAPT subsystems (memory, learning, clarify, web, media), with MERGEs landing in their existing homes and everything off-mission left behind. Four verdicts, one defensible decision per capability, zero "we copied it because it was there."
delegate_tool.py an IGNORE rather than a CLONE?faster-whisper path is IGNORED inside the otherwise-ported media tool.