Dual- and Triple-Loop Machine Architecture

PULSE update (OS-010, 2026-04): With the introduction of OS-010 PULSE, the loop-interlock pattern documented here is now formalized as a manifest standard. Graphonomous, PRISM, AgenTroMatic, and every other portfolio loop declare their phases in <loop>.pulse.json files (see /PULSE/manifests/), validated against pulse-loop-manifest.v0.1.json. The "dual loop" is a special case of arbitrarily nestable PULSE loops — the same machine grouping works at any depth, and PRISM's interact phase reads the inner system's PULSE manifest to discover the retrieve boundary at runtime rather than hard-coding the integration. See "Triple loop and beyond" below.

The Problem

Graphonomous exposes 29 MCP tools. PRISM specifies 47. When both run in the same session (the benchmarking use case), the client sees 76 tools. Research shows:

• Tool selection accuracy degrades past ~30 tools (Opus 4: 49% correct at that scale)

• Each tool definition consumes 500–2,000 tokens of context before conversation starts

• 76 tools can burn 40–80K tokens just on schema overhead

The Insight: Machine Around the Loop, Not the Category

Instead of grouping tools by what they touch (graph write, graph read, belief, etc.), group them by which phase of the closed loop the agent is in when it calls them.

Both Graphonomous and PRISM are closed-loop systems. Their loops are structurally parallel and interlock when PRISM evaluates Graphonomous:

Graphonomous (memory loop)          PRISM (evaluation loop)
──────────────────────────          ───────────────────────
retrieve  "What do I know?"         compose    "What should I test?"
route     "What should I do?"       interact   "Run the test"
act       "Do it"                   observe    "Judge the result"
learn     "Did it work?"            reflect    "What should change?"
consolidate "Clean up"              diagnose   "What's actionable?"

Graphonomous: 29 tools → 5 machines

retrieve — "What do I know?"

The agent calls this when it needs context before reasoning or acting.

route — "What should I do?"

The agent calls this to decide whether to act, learn, deliberate, or escalate.

act — "Do it"

The agent calls this to mutate the knowledge graph.

learn — "Did it work?"

The agent calls this after acting, to close the feedback loop.

consolidate — "Clean up"

The agent calls this to maintain graph quality, typically at session boundaries.

Total: 5 tools exposed to the model.

PRISM: 47 tools → 5 machines + 1 admin

compose — "What should I test?"

interact — "Run the test"

observe — "Judge the result"

reflect — "What should change?"

diagnose — "What's actionable?"

config — Admin/setup (outside the loop)

Total: 6 tools exposed to the model (5 loop + 1 admin).

Combined Impact

Context savings: ~80% reduction in tool schema tokens. Selection accuracy: from ~49% (76 tools) to ~95% (11 tools).

The Interlocking Loops

When PRISM benchmarks Graphonomous, the loops nest:

PRISM compose ──→ PRISM interact ──→ PRISM observe ──→ PRISM reflect ──→ PRISM diagnose
                       │
                       ▼
              ┌─── Graphonomous ───┐
              │  retrieve → route  │
              │  → act → learn     │
              │  → consolidate     │
              └────────────────────┘

PRISM's interact phase drives the system-under-test through its own closed loop. PRISM's observe phase judges how well that inner loop performed. PRISM's reflect phase evolves scenarios based on where the inner loop failed.

This is the knockout feature: two self-improving loops, one inside the other. The outer loop (PRISM) improves the benchmark. The inner loop (Graphonomous) improves the memory. Each makes the other sharper.

Implementation Pattern

Both systems use the same Elixir pattern: a single MCP component module per machine with an action field that dispatches internally.

defmodule Graphonomous.MCP.Retrieve do
  use Anubis.Server.Component, type: :tool

  schema do
    field(:action, :string,
      required: true,
      description: "context | episodic | procedural | coverage | trace_evidence | frontier"
    )
    # Union of all action-specific fields, each documented with which action uses it
    field(:query, :string, description: "Search query (context, episodic, procedural, frontier)")
    field(:limit, :number, description: "Max results (context, episodic, procedural)")
    # ... etc
  end

  def execute(%{action: "context"} = params, frame), do: do_context(params, frame)
  def execute(%{action: "episodic"} = params, frame), do: do_episodic(params, frame)
  # ...
end

Each machine module delegates to the existing Graphonomous.* functions — the internal API doesn't change, only the MCP surface.

Migration Strategy

1. Phase 1: Add machine modules alongside existing tools. Both surfaces work.

Register machines in server.ex with a v2_ prefix for testing.

2. Phase 2: Update skill prompts to reference machine verbs instead of

individual tools. Run PRISM benchmarks comparing v1 vs v2 tool selection accuracy.

3. Phase 3: Deprecate individual tools. Remove from server.ex, keep modules

for reference.

4. Phase 4: Remove deprecated modules. Clean cut.

Backward Compatibility

Existing clients calling retrieve_context directly will break at Phase 3. Mitigation: the adapter layer in Prism.MCP.Adapter can translate legacy tool names to machine + action pairs during the transition.

Triple loop and beyond — PULSE generalization

The Graphonomous ↔ PRISM dual loop is the canonical example, but the [&] ecosystem actually runs at least three nested loops today:

PRISM (outer)        compose → interact → observe → reflect → diagnose
  │
  └─ Graphonomous    retrieve → route → act → learn → consolidate
       │
       └─ Deliberation    survey → triage → dispatch → act → learn

OS-010 PULSE encodes this nesting in each manifest's nesting block:

• prism.benchmark declares inner_loops: [graphonomous.continual_learning]

• graphonomous.continual_learning declares inner_loops: [graphonomous.deliberate] and parent_loop: prism.benchmark

• graphonomous.deliberate declares parent_loop: graphonomous.continual_learning

PULSE supports unbounded nesting depth. OS-008 (Agent Harness, draft) is expected to add a fourth outer layer that wraps PRISM itself — when it ships, the only change required is a new manifest with inner_loops: [prism.benchmark]. No code changes to existing machines.

Why this matters for the machine architecture

The 5/6/11-tool count documented above is a floor, not a ceiling. Adding a third loop adds at most 5 more machines (one per phase kind), and because PULSE manifests declare the inner-loop boundary explicitly, the outer machines do not need to learn about inner machines individually. PRISM's interact machine, for example, drives any PULSE-conforming inner loop through its declared retrieve phase — it does not need a Graphonomous-specific code path.

The savings compound with depth, and PULSE's manifest standard is what makes the composition algebraic instead of ad-hoc.

Three-protocol stack at runtime

┌──────────────────────────────────────────────────────────┐
│  PRISM    — measures loops over time      (diagnostic)   │ OS-009
├──────────────────────────────────────────────────────────┤
│  PULSE    — declares loops + circulation   (temporal)    │ OS-010
├──────────────────────────────────────────────────────────┤
│  [&]      — composes capabilities          (structural)  │ AmpersandBoxDesign
└──────────────────────────────────────────────────────────┘

A loop is PULSE-conforming if its manifest validates against pulse-loop-manifest.v0.1.json and its runtime passes all 12 conformance tests. A system is PRISM-evaluable automatically once it is PULSE-conforming — PRISM's compose phase reads the manifest, injects scenarios at the declared retrieve boundary, and observes outcomes via the declared learn phase. No bespoke per-system integration required.

See /PULSE/manifests/ for the canonical reference manifests and opensentience.org/docs/spec/OS-010-PULSE-SPECIFICATION.md for the full PULSE protocol spec.