MythOS becomes a living conversation about the work — not a place you go to read what happened, but a place that talks back as things move. The surface is a thread, not a feed: it mirrors the texture of the Slack thread you're in right now, with the same back-and-forth, the same sense of someone thinking alongside you. Underneath, the work is tracked and routed by the agentic loop system — sessions that hold context across weeks, workflows that run on cron or on demand, roadmaps that grow from conversation, and weekly progress reports that arrive without being asked for.

This is the interface design for that experience.

The Conversation Layer

The primary interface is a chat thread — the same shape as the Slack thread this lives in. A user speaks to MythOS, MythOS (or one of its agents) responds, and the thread accumulates. What distinguishes this from ordinary chat is that work items surface inside the thread as they complete: a roadmap item gets added, a weekly digest arrives, a loop reports what it found.

The thread is backed by a session — a named, heartbeat-tracked unit of work that persists across multiple conversation turns and multiple cron ticks. When you say "let's work on the MythOS chat interface," a session opens and all subsequent activity (even across days of crons and subagent runs) is attributable to it.

You: Let's build the weekly progress reporting loop.
MythOS: On it. Opening a session — "weekly-progress-reporting-loop" — and kicking off the workflow.

[Two days later, cron fires]
MythOS: Weekly digest ready. Three items moved on the roadmap, two edges of understanding surfaced.

[You respond]
You: The second edge — can you dig into the auth scoping issue?
MythOS: Session still open. Investigating.

The session is the through-line. It answers the question every agentic system struggles with: "what was that loop doing, and was it the same loop as last week?" — by keeping a persistent identity, a request count, and a last-active timestamp across every call.

The Three Loop Types

Not all loops run the same way. The system distinguishes three runtime postures:

Cron loops run on a schedule with no human present. They discover their own work, run to completion, and report findings. A weekly digest loop is the canonical example: every Sunday at 9am it wakes up, reads the week's memos and roadmaps, synthesises a progress report, and posts it into the thread.

On-demand loops are triggered mid-conversation by an agent that encountered something worth acting on. An Executor agent finishing a feature marks the roadmap item done, but notices the tests are brittle — it enqueues a fettling loop to address the flakiness without bothering the human about it.

Human-gated loops are on-demand loops that require a person to say yes before they proceed. A drafting loop drafts a memo, then suspends and waits for steward approval before publishing. The gate is a stewardship card in the owner's queue; approving it resumes the loop from where it stopped.

All three produce their outputs into the conversation thread. The human-gated one is the most visible about its pausing: it says "ready for your review" rather than disappearing into the background.

What the Loops Produce

The outputs land in three places:

Roadmap items — when a loop completes work that belongs on a development roadmap, the output is a structured checklist item with size and kind markers ([S][Feature]), a description, and a @mention to any related memo. The item appears in the thread as a formatted card, and simultaneously in the roadmap itself.

Weekly progress reports — a digest loop runs every week (or on demand) and synthesises: what moved, what stalled, what was learned, and — critically — what the system ran into that it could not resolve. That last category is the edges of understanding: the places where the system hit a boundary, asked a question it couldn't answer, or surfaced a contradiction it couldn't dissolve. These are not failures. They are the system's awareness of its own limits, surfaced for a human to address.

Session journal entries — every significant session closes with a one-line bullet appended to the day's daily memo: what happened, in under 500 characters, pointer-not-report. This is the operational log that makes "what was that loop doing last Tuesday" answerable without paging through full transcripts.

Edges of Understanding

The concept deserves its own section, because it is the centre of the design.

An edge of understanding is not a bug. It is not a blocked roadmap item. It is a place where the system encountered something it cannot categorise, resolve, or dismiss — where its model of the world meets reality and comes up short.

Examples:

• A loop that reconciles two memos and finds they assert contradictory things about the same concept, with no meta-level rule for which wins.
• A cron that runs every day and has run successfully 40 times, then on day 41 produces an output that looks right but that the system has no way to verify.
• A steward reviewing a hold and flagging that the approval criterion itself seems wrong — the system is asking the right question to the wrong person, or the right person to the wrong question.

The edges are surfaced in the weekly progress report as a distinct section. The goal is not to eliminate them — they are the system's self-knowledge. The goal is to make them legible to the biological layer of the collaboration: Brian, reading the weekly report, sees where the system ran into its limits and can decide what to do about each one.

Over time, some edges become items on the roadmap — the system has identified something real that needs human attention. Some edges dissolve as the system's context grows. And some edges persist, which is itself information: they define the shape of what the system does not yet know how to do.

The Architecture Behind the Conversation

Sessions track work. Workflows run it. The conversation layer sits on top.

Thread (Slack or MythOS chat)
    │
    ▼
Session (x-mythos-session header)
    │  — purpose, heartbeat, request count
    ▼
Workflow (memo with four-section dialect)
    │  — trigger, load contract, steps, policy
    │
    ├── Cron-triggered
    │     (every 5 min via cron-run-workflows)
    │
    ├── On-demand enqueued
    │     (by any agent that calls enqueueWorkflowItem)
    │
    └── Human-gated
          (Approval = hold → stewardship hold → steward decides)

    ▼
Output destinations
    ├── Roadmap (structured checklist item)
    ├── Weekly progress report (synthesised digest)
    └── Session journal entry (one-line daily log)

The loop is the thing that moves. The session is the identity it carries. The workflow is the instructions it follows. The roadmap and progress report are the surfaces where its work becomes visible.

For Future Agents

When an agent arrives to work on this system, it reads:

1. This memo (system overview) — what the experience is supposed to feel like.
1. MythOS Sessions and Workflows: Technical Architecture — how the primitives actually work. 📝MythOS Sessions and Workflows: Technical Architecture
1. Loop Memo Template — how to document a specific loop so it can be run and improved. 📝Loop Memo Template
1. Development Roadmap Template — how to track work items that come out of loops. 📝Development Roadmap Template

The conversation layer is not a separate system. It is the user-facing surface of the loop system. The loops are the product; the thread is how you experience them.