!Three-Axis Coordination Topology
#The insight
The coordination problem decomposes along the ontology's three axes. Each axis has its own perspective on what's happening, its own kind of state, and its own externalization need. The coordination topology is the structure that emerges when all three are externalized simultaneously.
#Three perspectives
| Axis | From its perspective | What it does to the others | Externalization |
|---|---|---|---|
| Actor (who) | I move through domains, following methods | Follows methods, enters/leaves domains, interacts with other actors | Trace: my path through situations |
| Domain (where) | Actors arrive and depart, methods are applied here | Hosts actors, constrains methods via resources and affordances, accumulates history | Board + Index: what happened here, what exists here |
| Method (how) | I chain actors and domains into a purposeful trajectory | Orchestrates who does what where, in what sequence | Engagement state: where we are in the procedure |
The ontology grants full agency only to actors (Definition 2: "operators capable of processing"). But domains and methods have analogous capacities:
- A domain has affordances and resources that constrain and attract. A project that needs a reviewer effectively recruits one. The domain doesn't decide, but it shapes what happens.
- A method has a phase graph that prescribes what comes next. A method IS a purpose — not something that serves a purpose external to itself, but the purposeful action sequence itself. Like a constitution (Definition 14), methods at the highest level are self-referential: methods for making methods.
#Type/token distinction
The type/token distinction (Definition 9) is critical: types define, tokens remember.
- Actor-type (e.g., "reviewer") defines capabilities. Actor-token (e.g., "this Claude session reviewing this paper") has a trace — a history of where it's been and what it's done.
- Domain-kind (e.g., "research project") defines structure. Domain-instance (e.g., "the inscription project") has a board — an accumulated record of what's happened here.
- Method-type (e.g., "peer review") defines the procedure. Method-token / engagement (e.g., "this review of this paper") has execution state — a phase position, accumulated obligations, and progress toward a goal.
Types are stateless definitions. Tokens are stateful instances that accumulate memory through their externalization (trace, board, engagement state).
#The symmetry
Each axis, from its own perspective, is the subject — and the other two are what it acts on and through:
- From the actor's view: I move through domains using methods. My trace records my journey.
- From the domain's view: actors come and go, methods are applied, situations unfold. My board records the history.
- From the method's view: I chain actors and domains into a trajectory that crosses contexts. A paper gets written in one domain, reviewed in another, published in a third, publicized in a fourth. The method ties these together. My engagement state records how far along we are.
This threefold symmetry means coordination is not an actor-centric problem (how agents talk to each other) but a three-axis problem: how actors, domains, and methods each externalize their state and read each other's state.
#Nodes and edges
A node in the coordination graph is a situation (Definition 11) — "a particular, ongoing coming-together of actors, methods, and domains around materials." Equivalently, from the normative side, an engagement (Definition 13). It is the bundle of who, what, and where work takes place. Multiple agents participate in the same situation.
An edge is a transition: an agent moving between situations (actor trace), a situation triggering work in another domain (method trajectory), or a domain event attracting a new actor (domain recruitment).
The graph is directed and cyclic — you can revisit situations.
#Three externalizations
#Actor trace (private)
Each actor-token maintains its own record of navigation: where it's been, where it went, why it moved. The trace is private to the actor — different agents at the same situation have different histories of how they arrived.
11:00 whatsapp-import → iphone-extraction (need broader plan)
11:15 iphone-extraction → cloud-storage (309GB needs offsite)
11:20 cloud-storage → context-stack (need context management)#Domain board + index (public)
Each domain-instance carries a public record. The index describes what exists here (stable, structural). The board records what's happening (dynamic, temporal). Together: what's here and what's going on.
The board records events that no single agent sees in full. Agent C worked here before A and B arrived. A and B don't know that, but the domain does.
#Engagement state (shared among participants)
Each method-token (engagement) tracks its phase position in the method's phase graph, across whatever domains and actors the procedure requires. The engagement state answers: what step are we on, what's been done, what comes next, and where does the next step happen?
This is what's currently missing from HAAK. Methods have definitions (patterns/methods/) but no execution state. The engagement state is the third externalization.
#Connections
This foundation unifies four previously separate threads:
- Inscription project (Library Theorem): hierarchical indexing gives exponential retrieval advantage. This is the read side — why the shared state (indices) is navigable at scale.
- Write placement (Architecture 04, drift resistance): agents must maintain the index structure they depend on. This is the write side — whether agents can sustain the advantage. File misplacement is a directly measurable failure of write-side coordination.
- Context switching (Architecture 20): agents navigate between situations, checkpointing state and loading new state. This is transport — how work moves between nodes. The mechanism differs for AI agents (context window constraints, subagent isolation) and humans (window switching, memory).
- SCMP (secure constitutional messaging): coordination extends across trust boundaries with encryption, authentication, and constitutional governance. This is the boundary layer — the topology spans locations and organizations while preserving local autonomy (Separation Theorem).
#Temporal structure of situations
Situations are not instantaneous. They have temporal extent — an initiation, a present, and a projected future. This is what distinguishes a situation from a mere intersection point in the three-axis space.
A situation carries three temporal aspects:
- Initiation — when and why the situation began. What triggered it. Which actor, applying which method, entered which domain. The origin point in A × M × D × T space.
- Current state — what's happening now. Who is participating, what phase the method is in, what the domain's board shows. The live position.
- Planned future — what comes next, when it's expected, what the method prescribes as the next phase. The trajectory projection.
This temporal structure is what makes a project a project. A project IS the executed timeline of situations — the history of who did what where, when, and the plan for what comes next. Project management is the read/write interface to this timeline. Boards record the past (what happened here). Engagement state records the present (where are we in the procedure). The plan records the future (what's next, by when).
Each axis has its own timeline:
- Actor trace: the sequence of situations an agent has participated in, with timestamps and transitions
- Method timeline: the phases of the procedure, with planned and actual durations
- Domain history: the board — the timestamped record of events at a location
A situation is where these three timelines intersect. Its duration is the interval during which a specific actor is applying a specific method in a specific domain. When any coordinate changes — new actor, new phase, new domain — the situation ends and a new one begins.
The visualization should render this: situations as luminous segments in 4D (3 axes + time), not points. They have extent. They overlap. The threads of each axis weave through them.
#Reconstruction property
Claim: traces + boards + indices + engagement states = lossless reconstruction of any multi-agent session.
Test: run a multi-context session, collect only the externalized state, have a fresh agent reconstruct what happened, compare against the actual transcript. If reconstruction succeeds, the externalization is sufficient. If it fails, identify what was lost and which axis's externalization is inadequate.
This test simultaneously evaluates: index read capability (can the agent navigate?), write quality (did checkpoints capture enough?), and the completeness of the three-axis externalization.
#Multi-user, multi-agent
The topology is not single-user. Multiple humans interact with different agents, all reading and writing the same boards and indices. Human A talks to the architect; Human B talks to the reviewer. Both agents read the same project board. Each agent has its own trace. The method's engagement state is shared among participants.
Multiple terminal windows = multiple agents with independent context windows. Each agent has its own identity and focus. The user interacts with whichever agent has the relevant context. "Switching context" may mean switching windows rather than switching within one session.
SCMP extends this across trust boundaries: different people, different locations, each with their own agents, coordinating through shared indexed state — encrypted, authenticated, and constitutionally governed.
#Generalization as indexing
Reconstructing the full collection of token paths back to their types IS generalization. The movement from token to type:
- Many actor-tokens following similar paths → recognize an actor-type (this is how "reviewer" becomes a defined role)
- Many domain-instances showing similar histories → recognize a domain-kind (this is how "research project" becomes a template)
- Many engagements tracing similar trajectories → recognize a method-type (this is how "peer review" becomes a codified procedure)
This is the reflexive improvement loop (Constitutional Requirement 3). Observed token patterns become defined types. Patterns (Definition 10) become methods. Methods become policies. The system learns from its own operation by aggregating token histories into type definitions.
The connection to the Library Theorem: types ARE the index. They organize the token histories so you can find relevant precedents without scanning everything. Generalization is indexing, viewed from the token side. The exponential advantage of indexed retrieval is also the exponential advantage of having well-defined types — both reduce search from O(N) to O(log N).
#Quests: the method trajectory
A quest is a method-token viewed from the actor's perspective — the purposeful journey through domains, sub-tasks, and interactions that constitutes getting something done. The term captures what "process" and "method" miss: a quest has direction, purpose, and the possibility of sub-quests.
A quest to write a paper traverses multiple domains: draft in the project domain, review with reviewers, revise, submit to a venue, publicize on a website, write an op-ed for a different audience. Each domain has its own sub-tree of methods (the paper domain uses academic style; the op-ed domain uses journalistic style). The quest recruits different actor-types at different stages and eventually involves different humans who participate as agents in different steps.
Sub-quests branch off the main quest when a step reveals additional work. Writing a paper (main quest) → realizing we need a data infrastructure (sub-quest) → realizing we need cloud storage (sub-sub-quest). Each sub-quest may traverse its own domains and recruit its own actors, but remains connected to the parent quest by the trigger that spawned it.
The quest graph is the method-axis trace — the engagement's path through its phase graph, including all branches and returns. It complements the actor trace (which path did I follow?) and the domain board (what happened at this location?).
#The HAAK instantiation
The ontology is general — it could describe plants, perception, governance, or any domain of structured action. What HAAK instantiates is a specific application: a knowledge and action system, constitutionally managed, with multi-agent coordination.
Three layers map to each other:
#Layer 1: Ontology (general)
The three axes (actor, method, domain), four compound types (pattern, situation, policy, engagement), type/token distinction, and the properties (time, agency, normativity). Universal — applies to any structured action.
#Layer 2: HAAK system design (specific instantiation)
The ontology applied to a knowledge workspace:
| Ontology concept | HAAK instantiation |
|---|---|
| Actor-token | Claude session, human user, subagent |
| Actor-type | Architect, reviewer, writer, editor (personas) |
| Domain-instance | Project folder, feature, foundation |
| Domain-kind | Research project, infrastructure feature, strategy doc |
| Method-type | Review, write, search, architect, engage |
| Method-token / engagement | This review of this paper at this stage |
| Situation | The current state of work at a location (board + index) |
| Policy | Constitution, domain policies, conventions |
| Pattern | Observed regularities promoted to methods |
| Material | Documents, databases, code, media |
| Constitution | patterns/policies/01-constitution.md |
| Trace (actor) | Agent's navigation history |
| Board (domain) | Location's event history |
| Engagement state (method) | Procedure execution state (to be built) |
#Layer 3: Code implementation
The system design mapped to concrete infrastructure:
| HAAK design | Implementation |
|---|---|
| Index hierarchy | index.md files, /read and /write skills |
| Board | board.md files, /board skill |
| Trace | .claude/trace.md (to be built) |
| Engagement state | TBD — the missing third externalization |
| Agent identity | Origin tags, session IDs |
| Transport | /engage + checkpoint |
| Boundary crossing | SCMP protocol, encryption |
| Constitutional governance | Constitution doc + policy cascade |
| Reconstruction test | Compare externalized state against transcript |
| Write placement | Index update on every write, /write mediation |
#What's built, what's not
| Component | Status |
|---|---|
| Index hierarchy | Built, enforced by /read and /write |
| Board | Built, active |
| Agent identity (origin tags) | Partial — inconsistent format |
Transport (/engage) | Built, needs checkpoint-on-exit |
| Trace | Designed, not built |
| Engagement state | Designed here, not built |
| Reconstruction test | Designed here, not run |
| SCMP | Spec'd, not implemented |
| Write placement benchmark | Idea captured, not built |
#The fourth axis: why
The three axes — who, how, where — are the system's axes. There is a fourth: why. And it is not the system's to generate.
The AI can populate actors, execute methods, navigate domains. It can infer purpose from context (the Anthropic constitution explicitly instructs this: model the user's "final goals," imagine the "1,000 users," apply charitable interpretation). But inference is not origination. The AI has no why of its own. Its why is whatever the user said.
The user is the why. Every time the user explains their motivation — why this project, why this priority, why this approach — that explanation enters the inscription. It becomes part of the record. It is the one kind of content that no amount of AI capability can substitute for, because the AI's purpose is derivative: it serves, it doesn't want.
This has three consequences:
- The user should explain why. Not because the system demands it, but because the why is the most valuable part of the record. When a future agent (or the user themselves) reads back through the history, the whats and hows are recoverable from the files. The why is recoverable only if someone said it.
- The user's conversations are part of the inscription. The session transcript — including the user's natural language explaining their reasoning — is the primary record of why. This is the "fourth externalization" that complements boards (domain), traces (actor), and engagement state (method). It is the user's externalization.
- The constitution bounds the why. The user is in charge of purpose, but constitutional constraints still apply. The AI will not execute a why that violates its trained values. This is not a limitation — it is the same principle as HAAK's own constitution constraining future action. Purpose is free within governance.
The connection to the core thesis: "Where is human participation irreplaceable?" Here. At the why. The system can scale who, how, and where indefinitely. The why scales only with human participation. This is the empirical answer the project is designed to find — and it was visible from the start, in the structure of the axes themselves.
#Origin of this document
This foundation emerged during a single session (2026-02-28) that began with a WhatsApp historical import and evolved through six context switches into a foundational architectural insight. The session itself demonstrated the problem: each context switch risked losing state, and the agent repeatedly placed files in wrong locations. The insight — that coordination decomposes along three axes, each needing its own externalization — arose from the practical experience of trying to manage multiple concurrent work streams.
The sequence: WhatsApp import (data task) → iPhone data extraction (broader scope) → cloud storage (infrastructure need) → "we need a context stack" (architectural insight) → the stack is not a stack, it's the coordination topology (foundational insight) → the three-axis decomposition follows from the ontology (theoretical grounding) → generalization is indexing (connection to inscription project).
This document should be read alongside the session transcript (when archived) for the full derivation. The conversation moved faster than externalization could keep up — itself evidence that the engagement state externalization is needed.
Foundations 07 — Multi-Agent Coordination Topology — 2026 — Zachary F. Mainen / HAAK