Human-Agent Workflows

REALM Examples

Concrete human-agent workflows showing how REALM turns loose AI tools into a company operating system: direction from the Player, clear Character roles, explicit autonomy, and every result written back to the Codex.

Agents change the bottleneck

The hard part is no longer only doing the work. It is deciding who owns context, which actions need approval, and where the company remembers what happened.

Traditional frameworks assume human teams

Scrum, Kanban, and org charts coordinate human teams through events, calendars, and reporting lines. Agents coordinate through written context and boundaries the platform actually holds.

REALM makes the invisible visible

Every Character has a role, every Quest has a result, every handoff leaves a trace in the Codex, and every call is recorded by the person who answers for it. Accountability does not delegate.

Example 01

Supplier Onboarding Quest

A company of one evaluates a new supplier, checks margins, contacts the partner, prepares listings, and records the relationship as a Guild.

Scenario

The Player finds an interesting artisan brand at a market event. The opportunity is real, but onboarding it touches research, finance, outreach, product setup, content, and a record you can check later.

Outcome

The supplier is either rejected with evidence or onboarded with a Guild file, margin notes, approved outreach, product tasks, and launch content ready for review.

Why it matters

This example shows where the Player's judgment is actually spent. The crew does every step of the work, and some of it arrives without being asked for. What stays with the Player is the go or no-go, the outreach boundary, and the terms that enter the Codex as a Guild.

01Player

Creates the Quest in the Codex, defines the acceptance criteria, and marks outreach and spending as Tier 3 approval points.

Codex write
SAGAS/Active/Supplier-Onboarding-Quest.md
Boundary
Human decision
Player
02Hunter

Researches the brand, product range, pricing, reputation, availability, and visible demand signals, and files each one with where it was, who said it, and when. A finding is not a conclusion.

Codex write
INTELLIGENCE/Suppliers/Brand-Research.md
Boundary
Tier 1
Hunter
03Mage

Turns the Hunter report into margin estimates, catalog fit, risk notes, and a simple recommendation brief for the Player.

Codex write
WORLD/Finance/Outputs/Supplier-Margin-Assessment.md
Boundary
Tier 2
Mage
04Player

Reviews the recommendation and decides whether the Realm should pursue the supplier. If yes, approves the outreach boundary.

Codex write
DECISIONS/2026-04-12-onboard-artisan-supplier.md
Boundary
Human approval
Player
05Cleric

Prepares the outreach checklist, tracks reminders, keeps the negotiation state true, and brings the agreed terms to the Player, who writes the Guild file. Nobody writes a Guild file but the Player.

Codex write
SAGAS/Active/Supplier-Onboarding-Quest.md
Boundary
Tier 2, Tier 3 before sending
Cleric
06Bard

Drafts product descriptions, launch copy, and the story angle for the new supplier, then leaves it ready for Player review.

Codex write
WORLD/Marketing/Outputs/Supplier-Launch-Draft.md
Boundary
Tier 2, Tier 3 before publishing
Bard
07Warrior

Creates the product entries, inventory records, and pricing from the approved terms, then reports what changed and what needs the Player's eye first. The what was settled before this step began.

Codex write
QUEST-BOARD.md, WORLD/Commerce/Outputs/Listing-Batch.md
Boundary
Tier 1 to draft, Tier 3 to publish, summarized at volume
Warrior
08Cleric

Runs the Save Point: what got done, what was decided, and which Characters keep their hands while the Player is Offline. The board is the file in the Codex, so there is nothing to reconcile.

Codex write
SESSIONS/Save-Points/Supplier-Onboarding.md
Boundary
Tier 1
Cleric

What ends up in the Codex

  • Quest file with goal, scope, acceptance criteria, and Player approval points
  • Hunter intelligence report with cited sources and uncertainty labels
  • Mage recommendation brief with margin and risk assumptions
  • Guild file documenting the supplier relationship
  • Quest Board tasks for product setup, content, and follow-up
  • Save Point note recording what changed in the Realm

Example 02

Weekly Content Engine

A solo operator turns customer questions and market signals into a weekly article, newsletter, or social post without losing source traceability.

Scenario

The company needs consistent content, but the Player cannot spend every week starting from a blank page. The goal is one useful piece of content that supports the current Saga.

Outcome

One approved content asset is drafted, sourced, checked against the Saga, prepared for publication, and saved back into the Codex for future reuse.

Why it matters

This example shows what each handoff owes the next one. A finding carries its source, a brief carries its assumptions, a draft carries both, and none of them becomes a decision because the same Character produced them. One Character could hold all three Classes. It still must not blur them.

01Player

Sets the content direction for the week: audience, purpose, format, and what the piece must help the current Saga achieve.

Codex write
SAGAS/Active/Content-Quest.md
Boundary
Human decision
Player
02Hunter

Collects customer questions, competitor angles, community discussions, search prompts, and relevant source material.

Codex write
INTELLIGENCE/Audience-Questions.md
Boundary
Tier 1
Hunter
03Mage

Clusters the findings, identifies the strongest angle, checks whether the topic supports the Saga, and flags weak assumptions.

Codex write
WORLD/Marketing/Outputs/Content-Insight-Brief.md
Boundary
Tier 2
Mage
04Bard

Writes the draft in the brand voice, using the Mage brief and cited Hunter findings instead of inventing from memory.

Codex write
WORLD/Marketing/Outputs/Weekly-Content.md
Boundary
Tier 2
Bard
05Player

Reads the draft against the brief, checks that every claim about a real thing points back to a source, and approves or rejects public publishing. Output the Player cannot review is not output.

Codex write
DECISIONS/2026-04-19-approve-weekly-content.md
Boundary
Human approval
Player
06Warrior

Formats the approved asset, prepares platform-specific variants, schedules it, and checks the publishing checklist.

Codex write
QUEST-BOARD.md
Boundary
Tier 1, Tier 3 at publish
Warrior
07Cleric

Records what shipped, stores the final asset, adds follow-up reminders, and includes results in the next Scroll.

Codex write
SESSIONS/Save-Points/Content-Results.md
Boundary
Tier 1
Cleric

What ends up in the Codex

  • Content Quest tied to the active Saga
  • Audience question and source notes from the Hunter
  • Mage angle brief with assumptions and recommendation
  • Bard draft with source traceability
  • Player approval note before public publishing
  • Save Point and performance reminder for the next Session

Next Step

From example to implementation

Start with one Quest, one Character File, and one Codex folder. Then compare your setup with the live Niflheim Records implementation and the starter templates.