Chapter 4

The Scenarios — How It Behaves

Press → or click to begin

This layer makes the abstract contracts concrete through stories. Each scenario describes how the Anokye System behaves in a specific situation — what agents do, what events flow, what the human experiences. These scenarios also serve as satisfaction tests: an implementation that can execute these scenarios correctly has satisfied the corresponding contracts.

A Day in the Life

Level 2: Rhythm

The system maintains its own cadence. The human checks in.

7:15 AM — The Morning Briefing

The Omanhene opens their Okyeame. Without being asked, it presents an overnight summary:

“Good morning. While you were away:

3 tasks completed by Asafo agents (2 bug fixes, 1 documentation update)

1 task is blocked: the payment integration depends on an API change that hasn’t shipped

Sankofa detected 2 stale issues (no activity in 5 days) — recommend triage

The Ohemaa flagged a cost alert: API token spending is at 78% of weekly budget

1 decision needs your input: the Adontenhene recommends extracting the auth module into a shared library

Would you like to triage the stale issues first, or address the architecture recommendation?”

The Omanhene reviews the architecture recommendation, asks the Okyeame two clarifying questions (answered from context), and approves it. The Okyeame translates the decision into a Feature issue in the Work Ledger and dispatches it to the Nifahene for decomposition into Tasks.

Time spent: 35 minutes.

11:00 AM — Deep Work: Specification Writing

The Omanhene spends 2.5 hours writing specifications for the next major feature. The Okyeame assists with Socratic dialog: “The spec says ‘users can export data.’ In what formats? What’s the maximum file size? Should this work offline?” Each question sharpens the spec. When complete, the Okyeame materializes the spec into a hierarchy of work items in the Adwoma.

2:30 PM — Escalation Handling

The Okyeame alerts the Omanhene: “The Benkumhene reports that test coverage dropped below the governance threshold after the last three merges. The Ohemaa has paused further merges. Here are the three PRs and their coverage gaps.”

The Omanhene reviews, approves a plan to retroactively add tests, and the Ohemaa releases the merge block.

Time spent: 40 minutes.

Evening — Off

The Okyerema continues the rhythm. Health patrols run. Asafo agents pick up ready tasks. The Witness verifies completed work. The Ohemaa monitors. The Omanhene sleeps.

Total human time: ~4 hours. Town uptime: 24 hours.

Level 4: Autonomy

The system runs itself. The human provides judgment on exception.

8:00 AM — Three Decisions

The Okyeame presents three items that require human judgment:

“The Oracle detected that our primary competitor launched a feature similar to our Q2 roadmap item. Options: (a) accelerate our timeline, (b) differentiate our approach, (c) deprioritize. The Oracle recommends (b) with supporting analysis.”
“Two Ahene disagree on the database migration strategy. The Adontenhene recommends a staged rollout; the Krontihene recommends a hard cutover during maintenance window. Here are the risk analyses.”
“A new open-source library could replace 400 lines of custom code. The Twafohene evaluated it and found it meets 95% of our requirements. The 5% gap is in error handling. Adopt?”

The Omanhene makes three decisions in 20 minutes. The Okyeame translates each into Work Ledger entries and the system continues.

The rest of the day: The town runs. Scouts observe. Oracles orient. The Okyerema dispatches. Asafo execute. The Witness verifies. The Ohemaa governs. The Omanhene re-engages only if another escalation arrives (none does today).

OODA Loop Scenarios

Scenario: Bug Discovery to Fix (Micro Loop)

Timeline: Minutes to hours

OBSERVE:  Scout detects error rate spike in production telemetry
          → Event: observation.telemetry {type: error_rate_spike, severity: high}

ORIENT:   Oracle correlates the spike with the most recent deployment
          → Event: insight.generated {type: root_cause, confidence: 0.87,
             finding: "regression introduced in PR #142, function X"}

DECIDE:   Okyerema generates a fix specification from the Oracle's analysis
          → Event: spec.created {type: bug_fix, references: [PR #142, insight_id]}

ACT:      Asafo agent picks up the fix spec, implements, opens PR
          → Witness verifies the fix resolves the error pattern
          → Ohemaa validates: tests pass, no governance violations
          → Smith merges and deploys
          → Event: work.merged, work.deployed

OBSERVE:  Scout confirms error rate returned to baseline
          → Loop closes

Human involvement at Level 2: Approval at merge gate. Human involvement at Level 4: None. The Okyeame logs the cycle for later review.

Scenario: Feature Development (Meso Loop)

Timeline: Days to weeks

OBSERVE:  Scout aggregates 47 customer feedback items over 2 weeks
          mentioning difficulty with the export workflow

ORIENT:   Oracle synthesizes feedback themes:
          - 73% mention "too many clicks"
          - 41% mention "can't export to CSV"
          - 28% mention "slow for large datasets"
          → Insight: export UX is a top-3 pain point, with three sub-themes

DECIDE:   Oracle presents options to Omanhene via Okyeame:
          (a) Streamline existing workflow (quick win)
          (b) Rebuild export with batch support and format options (comprehensive)
          (c) Both in phases
          → Omanhene chooses (c), writes spec for Phase 1

ACT:      Okyeame materializes spec into Work Ledger hierarchy:
          Feature: "Export Redesign Phase 1"
            ├── Task: "Add CSV export option"
            ├── Task: "Reduce export to 2 clicks"
            └── Task: "Add progress indicator for large exports"

          Nifahene coordinates implementation across Asafo agents
          Benkumhene coordinates testing
          Witness validates each task against the spec
          Krontihene manages the release

OBSERVE:  Post-release, Scout monitors export usage patterns
          → feedback improves; loop informs Phase 2 planning

Scenario: Strategic Pivot (Macro Loop)

Timeline: Weeks to months

OBSERVE:  Scout tracks competitor launches, market reports, and industry trends
          over 6 weeks

ORIENT:   Oracle synthesizes:
          - Two competitors have launched AI-powered features in our category
          - Market analysis shows 3x growth in AI-assisted workflows
          - Internal capability assessment: we have the data but not the infrastructure
          → Strategic insight with supporting evidence and confidence scores

DECIDE:   Oracle presents to Omanhene via Okyeame:
          "Recommend initiating an AI integration research program.
           Estimated scope: 3-month exploration phase.
           Risk: moderate (new capability area).
           Opportunity: high (market momentum + data advantage)."
          → Omanhene approves, scopes boundaries

ACT:      Twafohene leads the research program:
          - Asafo research agents investigate approaches
          - Prototype agents build proof-of-concepts
          - Benkumhene evaluates prototypes against scenarios
          - Results feed back into the Orient layer for the next macro cycle

Scenario: The Town Improves Itself (Meta Loop)

Timeline: Ongoing

OBSERVE:  Herald (Sankofa patrols) detects a pattern:
          - 60% of PRs require 2+ review rounds
          - The common pattern: agents missing edge cases in initial implementation

ORIENT:   Oracle analyzes the pattern:
          - Root cause: specs don't include edge case scenarios
          - Recommendation: add "edge cases" section to the spec template
          - Supporting data: PRs with explicit edge cases in spec had 85% first-round approval

DECIDE:   Oracle presents to Omanhene:
          "Recommend updating the spec template to require an edge cases section.
           Expected impact: reduce review rounds by ~40%."
          → Omanhene approves

ACT:      Okyerema updates the workflow template (Formula)
          → All future specs include the edge cases section
          → The town's process has improved itself

OBSERVE:  Over the next 4 weeks, review rounds decrease by 35%
          → Meta-loop validates the improvement

Edge Cases and Failure Modes

Agent Produces Hallucinated Output

What happens: An Asafo agent completes a task but the output doesn’t match the specification.

How the system responds:

The Witness rejects the output (verification gate fails)
The event work.rejected is published with the reason
The Okyerema retries with a different agent or different approach
If retries exhaust, the Okyerema escalates to the relevant Ohene (coordinator)
If the Ohene cannot resolve, escalation reaches the Omanhene

Invariant: Hallucinated output never reaches production. The verification gate catches it.

Governance Policy Conflict

What happens: Two governance policies contradict each other (e.g., “all PRs must be reviewed within 24 hours” vs. “no merges during code freeze”).

How the system responds:

The Ohemaa detects the conflict during pre-action validation
The Ohemaa applies policy priority rules (if defined)
If priority rules don’t resolve the conflict, the Ohemaa escalates to the Omanhene
The Omanhene resolves and the resolution is recorded as precedent

Invariant: Conflicting policies never result in silent failure. They always surface.

Agent Runtime Failure Mid-Task

What happens: The infrastructure running an agent crashes during task execution.

How the system responds:

The runtime reports failure (or the Herald detects agent silence after heartbeat timeout)
The event agent.failed is published
The Okyerema queries the Work Ledger for the task’s last checkpoint
A new agent is dispatched to resume from the checkpoint
If no checkpoint exists, the task restarts from the beginning

Invariant: No work is lost. Externalized state + checkpointing ensures recoverability.

Cost Budget Exceeded

What happens: Agent API spending exceeds the configured budget threshold.

How the system responds:

The Sanaahene (cost coordinator) detects the overage
Non-critical work is paused
The Okyeame alerts the Omanhene with a breakdown of spending by agent and task
The Omanhene adjusts budget or priorities
Work resumes within new constraints

Invariant: The system never runs up an unbounded bill. Cost governance is proactive.

Cross-Domain Conflict

What happens: Work in one Oman depends on work in another (e.g., a software deploy that needs to coordinate with a marketing launch).

How the system responds:

The Okyeame detects the cross-domain dependency (it communicates with both Okyeremas)
The Okyeame presents the conflict to the Omanhene with context from both domains
The Omanhene resolves the coordination
For automated cases, an inter-domain agent passes the resolution between Okyeremas

Invariant: Cross-domain dependencies are always explicit. No silent coupling.

Satisfaction Tests

For each contract, these probabilistic criteria define “good enough”:

Contract	Satisfaction Test	Target
Work Ledger	Of 100 task lifecycles, how many complete with full audit trail?	>99%
Event Bus	Of 1000 published events, how many are delivered to all subscribers?	>99.9%
Agent Runtime	Of 100 agent executions, how many produce structured results (success or failure)?	>99%
Governance Engine	Of 100 agent actions, how many are validated against policy before execution?	100%
Observation Pipeline	Of configured signal sources, what fraction produce observations within cadence?	>95%
Orientation Engine	Of 100 insights generated, how many include supporting evidence?	>90%
Rhythm Engine	Of scheduled health patrols, what fraction execute on time?	>98%
Personal Agent	Of Omanhene status requests, what fraction receive response within 10 seconds?	>95%

Meta-Satisfaction (System Level)

Metric	Description	Target at Level 2	Target at Level 4
Human time per day	Hours the Omanhene spends actively directing	<4 hours	<1 hour
Bug fix cycle time	Detection → deployed fix	<4 hours	<1 hour
Stale work detection	Time until stalled tasks are flagged	<24 hours	<4 hours
Governance compliance	Fraction of agent actions validated	100%	100%
System uptime	Fraction of time at least one agent is productive	>90%	>99%