This is the implementation-critical layer. Each contract specifies a capability that any Anokye System implementation must provide. Contracts define WHAT — invariants, acceptance criteria, and test boundaries — never HOW.
Each contract follows a consistent structure:
- Story: Why this subsystem exists and what problem it solves
- Capability Contract: Formal specification using MUST/SHOULD/MAY
- Acceptance Criteria: Verifiable test boundaries
- Composability: Which maturity level requires this contract
Contract 1: The Work Ledger (Adwoma)
Story
In the Akan tradition, Adwoma — work — is what sustains the community. Without a record of what work exists, what has been done, and what remains, the town has no memory and no coordination. The Work Ledger is that memory. It is the single source of truth for all tasks in an Oman. If it’s not in the Adwoma, it doesn’t exist.
Every AI agent system that works at scale has discovered this independently. GasTown uses Beads (JSON records in Git). StrongDM uses cxdb (an immutable DAG). The pattern is universal because the problem is universal: agents crash, lie, and forget. The Work Ledger doesn’t.
Capability Contract
MUST:
- Store task records with a unique identifier, description, state, owner (agent or human), and timestamps
- Support state lifecycle transitions:
pending → active → blocked → completed (and failed as a terminal state)
- Support hierarchical task decomposition: parent-child relationships (e.g., Epic → Feature → Task)
- Support dependency tracking: directed acyclic graph (DAG) of task dependencies
- Maintain immutable history: all state transitions are append-only with timestamps and actor attribution
- Be queryable: agents and humans can filter tasks by state, owner, dependency status, and hierarchy
- Support “ready work” queries: return tasks that are
pending with no unmet dependencies
- Attribute all writes: every state change includes the identity of the agent or human that caused it
SHOULD:
- Support bulk operations (create multiple tasks, update multiple states)
- Support cross-reference between tasks and artifacts (commits, PRs, documents)
- Support labels or tags for categorization
- Provide change notification (emit events when task state changes)
MAY:
- Support full-text search across task descriptions
- Support time-based queries (tasks created/modified since timestamp)
- Support custom fields for domain-specific metadata
Acceptance Criteria
- An agent can create a task tree (Epic → Feature → Task) with explicit parent-child relationships
- An agent can query for “ready tasks” (pending, no unmet dependencies) and receive a correct set
- A second agent can read the complete history of any task and reconstruct what happened
- Concurrent writes by two agents to different tasks do not corrupt state
- A task that is
completed cannot transition back to active (forward-only state machine)
- All task records survive agent runtime failure (restarting the system loses no data)
Composability
Required from Level 1 (Plugin). This is the first contract any implementation must satisfy.
Contract 2: The Event Bus (Ananse Communication)
Story
A town without roads is a collection of isolated houses. The Event Bus is the road system of Anokye Krom — the fabric through which all agents communicate. Agents don’t call each other directly. They publish events. Interested agents subscribe to event streams. This decoupling is what makes the system resilient: if one agent crashes, the others continue. If a new agent joins, it subscribes to the events it cares about.
The immutable event log serves double duty: it is both the communication channel and the town’s collective memory. Any agent can replay events to reconstruct context. Any human can read the log to understand what happened.
Capability Contract
MUST:
- Support typed events with a defined schema:
{event_type, source_agent, timestamp, payload, priority}
- Deliver published events to all active subscribers of that event type
- Maintain ordering: events are delivered in the order they were published, per subscriber
- Persist events: the event log is durable and survives agent runtime failure
- Support at-least-once delivery: no event is silently dropped
- Attribute all events: every event includes the identity of the agent that published it
SHOULD:
- Support priority levels (e.g.,
critical, high, normal, low)
- Support event filtering: subscribers can filter by event type, source agent, or payload fields
- Support dead-letter handling: events that cannot be delivered are logged for investigation
- Support replay: an agent can request historical events from a time range
MAY:
- Support event compression or batching for high-throughput scenarios
- Support cross-Oman event routing for inter-domain coordination
- Support event schemas with validation
Acceptance Criteria
- Agent A publishes a
task.completed event; Agent B (subscribed) receives it within a reasonable time bound
- Events persist across agent runtime restarts
- The event log can be queried for all events of a given type within a time range
- Publishing an event when no agents are subscribed still persists the event in the log
- Events are never modified after publication (append-only)
Composability
Required from Level 2 (Rhythm). Not needed for basic plugin operation, but required once the system maintains its own cadence.
Contract 3: The Agent Runtime (Ananse Execution)
Story
Ananse the spider weaves the web on which the town’s agents walk. The Agent Runtime is the execution environment — the ground beneath the agents’ feet. Whether it’s a CI/CD job, a container, a local process, or a serverless function, the runtime provides a consistent contract: give me a task, I’ll execute it, and I’ll tell you what happened.
The runtime must isolate agents from each other (one failure doesn’t cascade) and from the system’s state (agents can’t corrupt shared state except through the Work Ledger’s API).
Capability Contract
MUST:
- Execute agent tasks atomically: a task either completes or fails, never half-completes without indication
- Capture and persist agent output (stdout, stderr, structured results)
- Enforce timeouts: no agent runs forever
- Report structured results: success/failure, output artifacts, error details
- Isolate agent execution: one agent’s failure does not crash another agent or the runtime itself
- Support secrets management: agents can access credentials without those credentials appearing in logs or output
SHOULD:
- Support resource limits (memory, CPU, token spending)
- Support concurrent execution of multiple agents
- Provide agent health monitoring (is the agent alive? is it making progress?)
- Support checkpointing: long-running agents can save progress and resume after failure
MAY:
- Support agent-to-agent communication during execution (via the Event Bus)
- Support GPU or specialized compute for ML/media tasks
- Support local and remote execution from the same interface
Acceptance Criteria
- An agent task executes and produces structured output regardless of the underlying execution platform
- An agent that exceeds its timeout is terminated and the failure is recorded
- Two agents executing simultaneously do not interfere with each other
- An agent crash produces a failure record (not silence)
- Secrets used during execution do not appear in any log or output
Composability
Required from Level 1 (Plugin). You need somewhere for agents to run.
Contract 4: The Governance Engine (Ohemaa)
Story
The Ohemaa — the Queen Mother — is the most important innovation of the Anokye System. Every AI agent framework has execution. Most have task tracking. Almost none have governance as a first-class, living agent.
The Ohemaa is not a configuration file. She is a persistent daemon with her own identity, her own OODA loop, and the authority to halt any agent at any time. When an agent tries to merge untested code, the Ohemaa blocks it. When API spending exceeds budget, the Ohemaa throttles. When an agent proposes an action that violates security policy, the Ohemaa rejects it and alerts the Omanhene.
This is what separates the 5% of AI initiatives that succeed from the 95% that fail: governance that is built in from the start, not bolted on after disaster.
Capability Contract
MUST:
- Validate agent actions against governance policies before execution (pre-action gate)
- Maintain a tamper-proof, append-only audit log of all agent actions and governance decisions
- Support JIT (Just-In-Time) access controls: agents request permissions; the Governance Engine grants or denies based on policy
- Store policies as inspectable, versioned data (not hardcoded logic)
- Provide an escalation path to the Omanhene when the engine cannot decide
- Support policy categories: quality gates, security policies, cost budgets, required reviews, escalation rules
SHOULD:
- Operate its own async OODA loop: observe agent activity → orient against policies → decide whether intervention is needed → act (halt, escalate, warn, approve)
- Maintain a persistent identity across sessions (the Ohemaa “knows” governance history)
- Interact directly with other agents (not just block/allow, but ask for explanation, request modification)
- Support policy priorities and conflict resolution (when two policies conflict, which wins?)
MAY:
- Learn from governance decisions over time (suggest new policies based on patterns)
- Support governance delegation (the Ohemaa delegates some decisions to Ahene coordinators)
- Support multi-Oman governance (a meta-Ohemaa governing multiple domains)
Acceptance Criteria
- An agent attempts an unauthorized action → the action is rejected, an audit entry is created, and the Omanhene is alerted
- A policy is changed → all subsequent agent actions are evaluated against the new policy
- An agent can query its current permissions (JIT access control)
- The full audit trail can be inspected by the Omanhene at any time
- Governance overhead does not bottleneck normal agent execution (validation latency is bounded)
- The Ohemaa can halt a running agent mid-execution if a policy violation is detected
Composability
Required from Level 1 (Plugin) at basic level (policy validation + audit log). Enhanced at Level 4 (Autonomy) with async OODA loop and persistent identity.
Contract 5: The Observation Pipeline (Scouts)
Story
You can’t orient on what you can’t see. The Scouts are the town’s eyes and ears — they monitor the environment and feed observations to the Orient layer. No current exemplar (GasTown, StrongDM, Anthropic) has a systematic observation layer for the full product lifecycle. This is the major gap the Anokye System fills.
Capability Contract
MUST:
- Ingest signals from configurable sources (the system doesn’t prescribe which sources, but provides the mechanism to add them)
- Normalize signals into typed observations:
{observation_type, source, timestamp, payload, confidence}
- Route observations to the Orientation Engine via the Event Bus
- Support multiple signal types: system telemetry, user feedback, market signals, research findings, internal agent metrics
SHOULD:
- Support configurable observation cadences (continuous, periodic, event-triggered)
- Deduplicate observations (the same signal from multiple sources produces one observation)
- Support observation prioritization (critical observations routed immediately)
MAY:
- Support observation aggregation (roll up many micro-observations into a summary)
- Support external observation sources via plugin/adapter pattern
Acceptance Criteria
- A new signal source is configured → observations flow to the Orientation Engine within the configured cadence
- Each observation includes source attribution, timestamp, and type
- Observations persist in the event log and can be replayed
- The pipeline continues operating when one signal source is unavailable
Composability
Required from Level 3 (Orchestra). Not needed until the system has multiple coordinating agents.
Contract 6: The Orientation Engine (Oracles)
Story
The Orient phase is what Boyd called the “schwerpunkt” — the center of gravity of the OODA loop. Raw observations are noise. Oriented insights are signal. The Oracles synthesize observations from Scouts into actionable understanding: pattern detection, root cause analysis, opportunity identification, and strategic recommendations.
This is the highest-leverage phase to automate — not because humans shouldn’t do it, but because AI can process vastly more signals and surface patterns humans would miss.
Capability Contract
MUST:
- Consume observations from the Observation Pipeline
- Produce typed insights:
{insight_type, supporting_observations, confidence, recommended_action, timestamp}
- Maintain and update a strategic model of the Oman’s current state
- Surface insights to the Omanhene (via the Okyeame) and to the Okyerema (for automated action)
SHOULD:
- Cross-reference signals across timescales (a micro-observation informing a macro-orientation)
- Generate prioritized recommendations with supporting evidence
- Detect anomalies and emerging patterns
- Incorporate long-lead research findings
MAY:
- Maintain multiple competing hypotheses about system state
- Support “what-if” scenario analysis
- Learn from the Omanhene’s decisions to improve future recommendations
Acceptance Criteria
- Multiple observations from different sources → synthesized insight with confidence score and supporting evidence
- Insights are actionable: they include a recommended action or decision request
- The Omanhene can inspect the supporting observations for any insight
- Insights persist in the event log
Composability
Required from Level 4 (Autonomy). The system can function without automated orientation at lower levels (the human does the orienting).
Contract 7: The Rhythm Engine (Okyerema)
Story
The talking drummer keeps the town in cadence. Without rhythm, agents work in bursts and stalls — sprinting when prompted, idling when not. The Okyerema ensures continuous, sustainable progress by scheduling health patrols, dispatching work to available agents, tracking cadence metrics, and detecting stalls before they cascade.
Capability Contract
MUST:
- Execute scheduled health patrols (Sankofa) on a configurable cadence
- Dispatch work to available Asafo agents based on dependency resolution (DAG-based “ready work” queries against the Work Ledger)
- Support checkpoint and resume-on-failure: if a workflow is interrupted, it resumes from the last verified checkpoint
- Detect stalled work (tasks that have been
active beyond a configured threshold) and escalate
- Maintain cadence metrics: cycle time, throughput, stall count, agent utilization
SHOULD:
- Support DAG-based workflow orchestration with multiple steps and verification gates
- Support fleet dispatch: parallel execution of independent tasks across multiple agents
- Adjust cadence dynamically based on system load and stall patterns
- Coordinate with the Ahene Council for domain-specific work routing
MAY:
- Support cross-Oman rhythm coordination (inter-domain cadence alignment)
- Predict workload and pre-allocate agent capacity
- Self-tune cadence based on historical performance
Acceptance Criteria
- A scheduled health patrol runs on cadence and produces a health report
- Stalled work is detected and escalated within the configured threshold
- A workflow interrupted by runtime failure resumes from the last checkpoint without data loss
- Ready work (pending, no dependencies) is dispatched to available agents without manual intervention
- Cadence metrics are queryable by the Okyeame and the Omanhene
Composability
Required from Level 2 (Rhythm). This is what makes the system self-sustaining.
Contract 8: The Personal Agent (Okyeame)
Story
The Okyeame is the equivalent of a browser. Everyone has their own — and each person has exactly one. Just as a browser is your window into the web, the Okyeame is your window into the Anokye System. But unlike a browser that shows you one site at a time, your Okyeame communicates with the Okyeremas of multiple Oman simultaneously — your software project, your family system, your research program.
The Okyeame fights the AI Vampire by filtering attention. Instead of drowning in agent threads and review requests, the human receives curated, prioritized information. The Okyeame surfaces what matters and lets the rest happen.
Capability Contract
MUST:
- Present system status in a human-friendly, structured format
- Translate human intent into structured work items (specs → tasks in the Work Ledger)
- Surface proactive alerts: don’t wait to be asked; notify when attention is needed
- Communicate with one or more Okyeremas across different Oman
- Maintain per-user context and preferences across sessions
SHOULD:
- Support multiple interaction modalities (text, voice, visual dashboards)
- Provide rich visualization of project state (dependency graphs, burndown, agent activity)
- Adapt communication style to the user’s preferences and working context
- Support Socratic dialog for specification refinement (help the user articulate requirements)
- Summarize cross-domain status in a unified view
MAY:
- Be embeddable in different environments (CLI, browser, IDE, mobile)
- Route queries to different AI models based on task type
- Maintain a personal knowledge graph that connects insights across domains
Acceptance Criteria
- The Omanhene asks for status → receives a structured, actionable summary across all their domains
- The Omanhene expresses intent in natural language → the Okyeame translates to work items in the Work Ledger
- A critical event occurs → the Okyeame proactively alerts the Omanhene without being asked
- The Okyeame maintains context: a follow-up question references the previous conversation correctly
- The Okyeame communicates with multiple Okyeremas and presents a unified view
Composability
Required from Level 1 (Plugin) at basic level (status display + intent translation). Enhanced at each subsequent level with richer interaction, cross-domain coordination, and proactive intelligence.
Contract Summary
| # | Contract | Subsystem | Required From |
|---|
| 1 | Work Ledger | Adwoma | Level 1 |
| 2 | Event Bus | Ananse Communication | Level 2 |
| 3 | Agent Runtime | Ananse Execution | Level 1 |
| 4 | Governance Engine | Ohemaa | Level 1 (basic) / Level 4 (full) |
| 5 | Observation Pipeline | Scouts | Level 3 |
| 6 | Orientation Engine | Oracles | Level 4 |
| 7 | Rhythm Engine | Okyerema | Level 2 |
| 8 | Personal Agent | Okyeame | Level 1 (basic) / enhanced at each level |