This is the implementation guide. It describes how to go from a blank repository to a functioning Anokye Krom instance. The cardinal rule: governance first, features second. Phase 0 establishes the rules before Phase 1 builds anything.
Each phase specifies what must be true BEFORE the next phase begins. An implementing agent should satisfy all acceptance criteria for a phase before advancing.
Bootstrap Invariants
These must hold at every phase, from the moment the first file is committed:
- All agent actions are audited — Nothing happens without a record
- Governance can halt any agent — The Ohemaa has veto power from day one
- State is externalized — No agent holds exclusive state in memory
- Human can inspect full system state — The Omanhene can see everything, always
- System degrades gracefully — Removing any single agent doesn’t crash the town
Phase 0: Governance Foundation
Establish the rules before writing the first line of feature code.
What This Phase Produces
A repository with complete governance infrastructure and zero feature code.
Steps
0.1 Repository Initialization
Create the repository with these foundational files:
AGENTS.md — Agent behavior conventions. The three-tier boundary system:
- ✅ Always do (externalize state, audit actions, reference work ledger)
- ⚠️ Ask first (architectural changes, policy changes, secrets)
- 🚫 Never do (self-certify completion, bypass governance, modify audit logs)
CODEOWNERS — Who reviews what. The Omanhene owns governance files.README.md — Project description, setup instructions, contribution guide- Branch protection — No direct pushes to main; all changes via PR
- Issue templates — Epic, Feature, Task, Bug (with required fields: description, acceptance criteria, type)
- PR template — Checklist: issue reference, tests, docs, governance compliance
0.2 Governance Policy File
Create the initial governance policy document. This is the Ohemaa’s “constitution” — the policies that all agents must follow. At minimum:
- Quality gates: What checks must pass before work is accepted? (Even if “no tests yet,” state that explicitly)
- Security policies: What is forbidden? (Secrets in code, unapproved dependencies, etc.)
- Cost constraints: Are there budget limits for agent execution or API tokens?
- Escalation rules: When must a human be consulted?
- Audit requirements: What must be logged?
0.3 Audit Trail Foundation
Establish the audit trail format and persistence mechanism. Even before any agents run, the format must be defined:
- What fields does each audit entry contain? (timestamp, agent_id, action_type, target, result, policy_applied)
- Where are audit entries stored? (Append-only file, database table, event log)
- How are entries made tamper-proof? (Signed commits, immutable storage, etc.)
0.4 CI Pipeline Skeleton
Set up the continuous integration pipeline — even though there’s nothing to build yet. The pipeline:
- Validates governance files (AGENTS.md, CODEOWNERS, policy documents)
- Runs any linters available for the chosen language/platform
- Verifies branch protection rules are active
- Validates issue template structure
Phase 0 Acceptance Criteria
- The repository exists with all governance files committed
- Branch protection prevents direct pushes to main
- CODEOWNERS routes governance file changes to the Omanhene
- The governance policy document is committed and inspectable
- The audit trail format is defined and the persistence mechanism is operational
- The CI pipeline runs (even if it only validates governance files)
- No feature code exists in the repository
Phase 1: Substrate
Build the ground the town stands on.
Prerequisites
Phase 0 complete. All governance files in place.
What This Phase Produces
A functioning substrate where agents can be assigned work, execute it, and have their actions governed and logged.
Contracts Satisfied
- Work Ledger (Adwoma) — basic level
- Agent Runtime (Ananse Execution) — basic level
- Governance Engine (Ohemaa) — basic level (policy validation + audit)
Steps
1.1 Implement Work Ledger
Stand up the Work Ledger with minimum viable capabilities:
- Create tasks with unique ID, description, state, owner
- State transitions: pending → active → completed / failed
- Hierarchical decomposition (parent-child)
- Dependency tracking (task A depends on task B)
- “Ready work” query (pending tasks with no unmet dependencies)
- Immutable history of all state transitions
1.2 Implement Agent Runtime
Stand up the execution environment:
- Execute a single agent task and capture output
- Enforce timeout
- Report structured result (success/failure + output)
- Isolate from other processes
1.3 Implement Basic Governance
Stand up the minimum viable Ohemaa:
- Pre-action validation: before an agent executes, check against governance policies
- Audit logging: every action produces an audit entry
- JIT access: agents can query their current permissions
- Escalation: when governance can’t decide, alert the Omanhene
1.4 Wire Them Together
- Agent receives task from Work Ledger → Governance validates → Runtime executes → Result recorded in Work Ledger → Audit entry created
Phase 1 Acceptance Criteria
- A task can be created in the Work Ledger and queried back
- A task tree (parent → child) can be created with dependencies
- “Ready work” query returns correct tasks (pending, no unmet deps)
- An agent task executes in the runtime and produces structured output
- Governance blocks an unauthorized action and creates an audit entry
- The full audit trail is inspectable by the Omanhene
- All state survives runtime restart (nothing in agent memory only)
Phase 2: Core Agents
The first inhabitants arrive.
Prerequisites
Phase 1 complete. Substrate is operational.
What This Phase Produces
A working human-agent loop: the human expresses intent through the Okyeame, work flows to an agent, results are governed and tracked.
Contracts Satisfied
- Personal Agent (Okyeame) — basic level
Steps
2.1 Implement Basic Okyeame
Stand up the personal agent with minimum viable capabilities:
- Display system status from the Work Ledger (how many tasks? what state?)
- Translate human intent into Work Ledger entries (user says “I want X” → task created)
- Present results and status in human-friendly format
2.2 Implement Basic Asafo Dispatch
- A single implementation agent can pick up ready work from the Work Ledger
- Execute the task via the Agent Runtime
- Report results back to the Work Ledger
2.3 Close the Loop
- Okyeame → Work Ledger → Agent Runtime → Governance Engine → Work Ledger → Okyeame
- The human can express intent, see it become a task, watch it execute, and receive results — all through the Okyeame
Phase 2 Acceptance Criteria
- The Omanhene can ask the Okyeame for system status and receive a structured response
- The Omanhene can express intent and the Okyeame creates a task in the Work Ledger
- An Asafo agent picks up the task, executes it, and reports results
- The Governance Engine validates the agent’s actions
- Results flow back to the Okyeame and are presented to the Omanhene
- The complete workflow is recorded in the audit trail
Phase 3: Rhythm
The drummer starts beating.
Prerequisites
Phase 2 complete. Core agents are operational.
What This Phase Produces
A self-sustaining system that maintains its own cadence without constant human prompting.
Contracts Satisfied
- Event Bus (Ananse Communication)
- Rhythm Engine (Okyerema)
Steps
3.1 Implement Event Bus
Stand up the communication fabric:
- Typed events with defined schema
- Publish/subscribe mechanism
- Event persistence (the log)
- At-least-once delivery
3.2 Implement Rhythm Engine
Stand up the Okyerema:
- Scheduled Sankofa health patrols (detect stale work, orphaned tasks, governance drift)
- DAG-based work dispatch (query ready work → assign to available agents)
- Stall detection (tasks active too long → escalate)
- Cadence metrics (cycle time, throughput)
3.3 Wire Events to Agents
- Work Ledger changes → events published → Okyerema reacts → dispatches next work
- Health patrol results → events → Okyeame presents to Omanhene
- Governance decisions → events → audit log
Phase 3 Acceptance Criteria
- Health patrols run on schedule without human triggering
- Stalled work is detected and escalated automatically
- Ready work is dispatched to agents without human intervention
- Events flow between agents via the Event Bus
- A workflow interrupted by failure resumes from checkpoint
- The Omanhene can check in periodically rather than directing continuously
Phase 4: Orchestration
The town comes alive.
Prerequisites
Phase 3 complete. Rhythm is established.
What This Phase Produces
Full OODA loop operational with multiple agents coordinating across specializations.
Contracts Satisfied
- Observation Pipeline (Scouts)
- Orientation Engine (Oracles)
- Ahene Council (domain coordinators activated)
Steps
4.1 Implement Observation Pipeline
- Configure signal sources (telemetry, feedback, agent metrics)
- Normalize into typed observations
- Route to Orientation Engine via Event Bus
4.2 Implement Orientation Engine
- Consume observations
- Synthesize insights with confidence scores
- Surface to Okyeame and Okyerema
4.3 Activate Ahene Council
- Instantiate domain coordinators as needed (Nifahene for implementation, Benkumhene for testing, etc.)
- Wire coordinators into the Event Bus
- Enable multi-agent workflow coordination
4.4 Close the Full OODA Loop
- Observe → Orient → Decide → Act → Observe (continuous)
- Multiple loops at different timescales (micro, meso, macro, meta)
Phase 4 Acceptance Criteria
- Observations flow from signal sources through the pipeline to the Orientation Engine
- The Orientation Engine produces insights with supporting evidence
- Multiple Ahene coordinators manage different aspects of work
- The system identifies what needs to be done next without human prompting
- The Omanhene’s role is exception handling and strategic direction
Phase 5: Civilization
The town evolves.
Prerequisites
Phase 4 complete. Full OODA loop operational.
What This Phase Produces
A self-improving system that learns, predicts, and evolves.
Steps
- The system observes its own processes (Herald detects friction)
- The Oracle analyzes process patterns
- Process improvements are proposed and (with Omanhene approval) implemented
- The town rebuilds itself
5.2 Cross-Project Learning
- Patterns from one Oman inform another
- Successful workflows become shared templates
- Failed approaches become documented anti-patterns
5.3 Predictive Health
- Sankofa doesn’t just detect problems — it predicts them
- Pattern analysis over historical events enables proactive intervention
Phase 5 Acceptance Criteria
- The system proposes process improvements based on observed patterns
- Workflow templates from one domain can be applied to another
- Health patrols predict problems before they manifest
- New agents (human or AI) can onboard with minimal friction via Akwaaba
Implementation Notes for Agents
When implementing the Anokye System on a specific platform, consider these mapping patterns:
| Contract | GitHub/Actions | Temporal/Cloud | Local/Minimal |
|---|
| Work Ledger | GitHub Issues + GraphQL | Database + API | SQLite + file system |
| Event Bus | GitHub webhooks + Actions | Temporal signals | File watchers + polling |
| Agent Runtime | GitHub Actions jobs | Temporal workflows | Local processes / containers |
| Governance Engine | Branch protection + CODEOWNERS + policy checks | Policy service + audit DB | Pre-commit hooks + audit file |
| Observation Pipeline | GitHub webhooks + monitoring integrations | Event streams + connectors | Log parsing + file monitors |
| Orientation Engine | Analysis agent in Actions | Long-running analysis worker | Local analysis script |
| Rhythm Engine | Scheduled Actions workflows | Temporal schedules + cron | Cron jobs + daemon process |
| Personal Agent | CLI tool / Copilot extension | Chat interface / dashboard | Terminal REPL / simple CLI |
These mappings are illustrative, not prescriptive. The contracts define WHAT; you choose HOW based on your platform’s capabilities.