Course / Lesson 21  ·  PT-BR
Lesson 21 · Engine & method · 8 of 8

The fusion framework: CLONE / ADAPT / MERGE / IGNORE

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.

The two questions — and the 2×2 they produce

For each capability of the source system, the matrix asks exactly two questions, each answered against verified map evidence (never from memory):

  1. Does the target already have an equivalent? (answered against the Alembic map, evidence cited)
  2. Is the source's version superior or net-new? (answered against the Hermes map)

The disposition follows from the pair. It is, in effect, a 2×2:

does the target already have it? NO (gap) YES (some equivalent) source net-new / better source weaker / n/a CLONE net-new, high value — port the design closely memory · learning loop · curator · web · clarify MERGE / ADAPT partial equivalent — combine into one surface MCP client · browser · skills authoring · media IGNORE (out of scope) net-new but off-mission: neutts, computer-use, 23 messaging adapters, ACP editor IGNORE (already better) target does it as well/better: delegate (swarm) · terminals (factory) · image-gen

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.

Worked example 1 — learning loop: CLONE (the keystone)

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.

Worked example 2 — MCP client: MERGE (and parked)

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.

Worked example 3 — delegation: IGNORE (already better)

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.

Worked example 4 — neutts local TTS: IGNORE (off-mission)

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 discipline that prevents bloat

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."

1. A source capability is net-new (the target lacks it) and high-value. Which disposition?
Correct: c. Net-new (Q1 = no equivalent) + valuable (Q2 = worth having) ⇒ CLONE. The learning loop, memory, curator, web, and clarify all landed here — that's the lessons 7–13 set.
2. Why is Hermes' delegate_tool.py an IGNORE rather than a CLONE?
Correct: b. Q1 = Alembic has it (the swarm, 63 hits); Q2 = Hermes' is not better. Equivalent + not-superior ⇒ IGNORE — the "already better" quadrant. A disciplined IGNORE still harvests the one idea worth keeping.
3. neutts (neural local TTS) is net-new to Alembic. Why is it still IGNORE?
Correct: d. The framework's second IGNORE quadrant: a capability the target lacks but that is off-mission or technically misfit. "Net-new" never overrides "doesn't fit" — the same reason the local faster-whisper path is IGNORED inside the otherwise-ported media tool.

Common confusions

"IGNORE means the capability was bad." No — two very different things get IGNOREd: things the target already does better (delegation), and things that are genuinely good but off-mission (neutts, 23 messaging adapters). The verdict is about fit, not quality, and it always carries a stated reason.
"MERGE means build it now." Not necessarily. MERGE is the disposition (combine into an existing surface); the schedule is separate. The MCP client is a MERGE but parked at #5, behind the five Easy CLONEs. Deciding what something is doesn't commit you to doing it next.
You've completed the Engine & method track. Lessons 14–21 covered the engine the fusion plugs into (narrow waist, funnel, four invariants, gate pipeline, council/verifier, swarm) and the discipline behind it (reverse-engineering method, fusion framework). Together with the narrative (1–6) and the subsystem deep dives (7–13), you can now reason about Alembic × Hermes from contract to capability. Re-read Lesson 3 and the four verdicts should now read like obvious consequences of two questions. Next, the Labs & advanced track (22–30) puts it to work: two hands-on labs, deep advanced topics, and a capstone.