Chapter 2

The Architecture — How It's Shaped

Press → or click to begin

This layer describes the structural patterns of the Anokye System — the shape of the town, not the materials it’s built from. Everything here is implementation-agnostic: these patterns hold whether you build on GitHub Actions, Temporal, Kubernetes, local processes, or anything else.

The OODA Product Loop

The Anokye System is animated by a continuous loop drawn from John Boyd’s Observe-Orient-Decide-Act framework, extended from tactical decision-making to the entire product lifecycle.

The Four Phases

Phase	Question It Answers	Agent Roles
Observe	What is happening?	Scouts ingest telemetry, user behavior, feedback, market signals, experiment results, agent activity
Orient	What does it mean?	Oracles synthesize observations into understanding: pattern detection, root cause analysis, opportunity identification
Decide	What should we do?	The Omanhene (human) and Chief/Okyerema generate specifications, prioritize work, design experiments
Act	Do it.	Asafo execute: write code, run experiments, deploy, document, communicate. Witnesses verify. Smiths integrate.

Multi-Timescale Operation

The loop runs simultaneously at four cadences:

Micro-loop (minutes–hours): Bug detected → diagnosed → fix spec → agent patches → deployed. The hot path.
Meso-loop (days–weeks): Usage patterns observed → design iteration → feature spec → built and shipped.
Macro-loop (weeks–months): Market shift → strategic reorientation → research program initiated.
Meta-loop (ongoing): The OODA loop itself is observed, oriented on, and improved. The town rebuilds its own processes.

The Critical Insight: Async Parallelism

Unlike Boyd’s sequential loop (designed for a single fighter pilot), the Anokye System runs many parallel loops simultaneously, at different timescales, feeding into each other. The Orient phase is where loops cross-pollinate: a micro-loop observation (a crash log) may inform a macro-loop orientation (our architecture doesn’t handle this class of failure).

The Gap This Fills

Every existing exemplar (GasTown, StrongDM, Anthropic’s tooling) covers only Decide/Act — the “build” phases. None closes the loop through systematic Observe/Orient. The Anokye System’s architecture is designed from the ground up to support the complete cycle.

The Agent Hierarchy

Agents in the Anokye System are organized in a supervision hierarchy — each agent has a supervisor responsible for monitoring its health, progress, and alignment. This mirrors both human organizational management and Erlang/OTP supervision trees.

The Hierarchy

Omanhene (Human)
  └─ Okyeame (Personal Agent — the human's interface)
       └─ Okyerema (Rhythm Engine — domain orchestrator)
            ├─ Ohemaa (Governance Daemon — monitors all, veto power)
            ├─ Ahene Council (Domain Coordinators)
            │    ├─ Nifahene (Implementation)
            │    ├─ Benkumhene (Quality/Testing)
            │    ├─ Kyidomhene (Security)
            │    ├─ Twafohene (Research/Exploration)
            │    ├─ Gyaasehene (Infrastructure)
            │    ├─ Sanaahene (Resource/Cost)
            │    └─ Krontihene (Release/Deployment)
            └─ Asafo Companies (Implementation Agents)
                 ├─ Code agents
                 ├─ Test agents
                 ├─ Documentation agents
                 └─ Research agents

Supervision Patterns

Pattern	Description
Watchdog	Periodic “are you alive and productive?” checks (the Sankofa patrols)
Recursive supervision	Supervisors are themselves supervised (the meta-loop)
Verification gate	Output must be externally verified before advancing (the Witness)
Escalation	Agent escalates to supervisor when stuck; supervisor escalates to Omanhene when unable to resolve
Restart on failure	Failed ephemeral agents are torn down and replaced; work resumes from checkpoint

Why Not Flat?

Flat agent topologies fail because:

No accountability for coordination
No mechanism to resolve conflicts between agents
No escalation path when agents are stuck
No one to monitor the monitors

The hierarchy provides these at the cost of token overhead — a cost that pays for itself in reliability.

Scaling the Hierarchy

Not every project needs every role. A small project may have only the Omanhene, an Okyeame, an Okyerema, and a few Asafo. A large project activates the full Ahene Council. The architecture scales by activating roles as complexity demands.

The Substrate

The substrate is the shared infrastructure on which the town operates. It is not a phase of the OODA loop but the medium through which all phases communicate and persist.

Four Substrate Layers

Communication Layer

Event Bus: Async, event-driven communication between all agents
Event Log: Immutable record of all events — the town’s collective memory
Notification Routing: Alert routing to appropriate agents or the Omanhene

State Layer

Work Ledger (Adwoma): The authoritative record of all tasks, states, and history
Context Store: Immutable record of agent conversations and tool outputs
Knowledge Base (Akwaaba): Accumulated domain knowledge, decisions, and rationale
Configuration Store: System settings, feature flags, governance policies

Execution Layer

Agent Runtime (Ananse): Where agents execute tasks
Version Control: Git or equivalent for all artifacts — code, specs, state
CI/CD Pipeline: Automated build, test, deploy
Simulation Environment: Digital twins, test harnesses, staging

Governance Layer

Workflow Engine: Enforces constrained workflows with verification gates
Permission System: Controls what agents can do (JIT access)
Audit Trail: Who did what, when, and why — append-only, tamper-proof

The Key Property: Everything Is Versioned

All substrate state must be:

Externalized — not in any agent’s memory
Immutable — append-only, with full history
Versioned — git-backed or equivalent
Inspectable — queryable by both humans and agents

The Reactive Architecture

The Anokye System is fundamentally async, reactive, and event-driven. Components communicate through events, not synchronous calls.

Why Async?

Synchronous	Asynchronous
Caller blocks waiting for response	Caller continues; response arrives as event
Bottleneck propagates through chain	Components decouple; failure isolates
Hard to parallelize	Natural parallelism
Poor fit for multiple timescales	Each loop runs at its own pace

Event Types

Event	Source	Consumer
`observation.telemetry`	Scout	Oracle
`observation.feedback`	Scout	Oracle
`insight.generated`	Oracle	Chief / Okyeame
`spec.created`	Chief / Omanhene	Artisan (Asafo)
`work.assigned`	Okyerema	Asafo
`work.completed`	Asafo	Witness
`work.verified`	Witness	Smith
`work.merged`	Smith	Herald / Okyeame
`agent.stalled`	Herald (Sankofa)	Okyerema
`agent.failed`	Runtime	Herald
`governance.violation`	Ohemaa	Omanhene
`governance.escalation`	Ohemaa	Okyeame
`meta.process_friction`	Herald	Oracle (meta-loop)

The Event Log as Memory

The immutable event log enables:

Debugging: Trace the causal chain of any outcome
Audit: Who did what, when, why
Replay: Reconstruct state at any point in time
Learning: Pattern detection over historical events

Multi-Domain Architecture

The Anokye System supports multiple independent domains, each a self-contained Oman.

Domain Independence

Each Oman has its own:

Omanhene — the human who governs it
Okyerema — the rhythm engine that maintains its cadence
Adwoma — the work ledger that tracks its tasks
Asafo — the agents that execute its work
Ohemaa — the governance daemon that enforces its policies

Cross-Domain Coordination

When domains need to interact:

Human-mediated: The Okyeame is the natural bridge. Since each person has one Okyeame that communicates with all their Okyeremas, it can relay requests and status between domains.
Automated: Dedicated inter-domain coordination agents pass work requests and messages between Okyeremas. These agents use the Event Bus and operate under governance constraints.

The clean boundary is preserved: each Okyerema owns its domain’s rhythm. Cross-domain coordination flows through explicit channels.

The Okyeame as Cross-Domain Unifier

This is a critical architectural point. The user doesn’t need separate interfaces for each domain. One Okyeame presents a unified view: “Your software project has 3 blocked tasks. Your family calendar has a scheduling conflict. Your research program has a new finding relevant to the software project.” Cross-domain insights emerge naturally.

The Maturity Model

The Anokye System is designed to grow incrementally. Not every implementation needs every capability. The maturity model describes five levels, each building on the previous.

Level 1: Plugin

The system is a tool. The human drives.

Okyeame provides conversational project management
Okyerema provides scripts for issue management and health checks
Asafo is a single agent provider (e.g., Copilot)
Adwoma is the work tracker (e.g., GitHub Issues)
Human directs every action

Contracts required: Work Ledger (basic), Agent Runtime (basic), Governance Engine (basic), Personal Agent (basic)

Level 2: Rhythm

The drummer beats steadily. The human checks in.

Okyerema runs scheduled health patrols and dispatches work
Asafo agents self-select work based on dependencies
The system maintains cadence without constant prompting
Human checks in periodically rather than directing continuously

Contracts required: + Event Bus, Rhythm Engine

Level 3: Orchestra

Multiple instruments play in coordination.

Multiple Asafo companies with specialized capabilities
Okyerema coordinates cross-agent workflows
Fleet dispatch for parallel execution
Checkpoint and resume-on-failure
Observation Pipeline begins feeding signals

Contracts required: + Observation Pipeline (basic)

Level 4: Autonomy

The system runs. The human supervises.

Continuous progress without human prompting
Okyeame escalates only when judgment is genuinely needed
Full OODA loop operational (Observe → Orient → Decide → Act)
Multi-provider agents work interchangeably
Ohemaa governance is fully autonomous

Contracts required: + Orientation Engine, all contracts enhanced

Level 5: Civilization

The system evolves itself.

The meta-loop: the system improves its own processes
Cross-project learning
Predictive health (Sankofa predicts before problems manifest)
Self-directed work identification
New agents onboard with minimal friction

Contracts required: All contracts at full capability, meta-loop operational

The Flow

    Omanhene (Human)
        │
        │ sets direction, resolves stalemates
        ▼
    Okyeame (Personal Agent)
        │
        │ translates intent, surfaces status, coordinates across domains
        ▼
    Okyerema (Rhythm Engine)  ◄────────►  Ohemaa (Governance Daemon)
        │                                   │
        │ dispatches work, maintains        │ monitors all agents
        │ cadence, runs health patrols      │ enforces policies
        │                                   │ can halt or redirect
        ├───────┬───────┬───────┐           │
        ▼       ▼       ▼       ▼           │
    Ahene Council (Coordinators)            │
    [Nifahene] [Benkumhene] [Twafohene]    │
        │       │       │                   │
        ▼       ▼       ▼                   │
    Asafo Companies (Agents)                │
    [Code] [Test] [Research] [Security]     │
        │       │       │                   │
        ▼       ▼       ▼                   │
    Adwoma (Work Ledger) ──────────────────►│
        │
        │ feeds status back to all agents
        ▼
    (cycle continues)

The key insight: the circular flow. Adwoma feeds information back to Okyeame, Okyerema, and Ohemaa — each operates its own OODA loop against the shared state. Even when individual agents fail or humans are unavailable, the rhythm continues.