Morgana system map

Systems

Morgana is a modular AI runtime and control plane. It routes messages across channels, selects personas and tools, enriches responses with memory when appropriate, reviews output quality, and supports operator-controlled workflows.

Not a single chatbotNot one siteNot a prompt wrapper

What Morgana is

A runtime backbone with visible system lanes

Morgana is the operating layer behind communication, publishing, research, review, and operator workflows across the current Ark surfaces. The public site should be read as a map of lanes that already exist, not as a speculative concept sheet.

What matters first

  • Messages arrive through real transports.
  • Gateway and workers route work through queues.
  • Memory and RAG can enrich turns when appropriate.
  • Witness reviews output quality.
  • Aegis provides operator control inside Matrix.

Core runtime flow

From message to reply

This is the simplest public-safe view of the architecture. A request enters through transport, gets shaped by the gateway, runs through workers, can be enriched by memory or retrieval, and is returned through the originating channel.

01

Transport receives a message

Matrix, Telegram, mail, and other surfaces bring a request into the system in channel-aware form.

02

Gateway normalizes the request

The gateway shapes the request into a consistent runtime format and applies the right routing context.

03

Worker resolves and executes

Workers select the right persona, tools, and backend path, then execute through queues, retries, and bounded actions.

04

Memory or RAG may enrich the turn

When context matters, bounded memory and retrieval can enrich the response without turning every turn into uncontrolled profile sprawl.

05

Transport posts the reply

The result is returned through the originating channel as a usable response, action, digest, or routed workflow outcome.

Queueing, retries, persona routing, and response composition live inside this flow. That is why Morgana can support chat, publishing, operations, and longer-running automation without flattening into one chat surface.

Core system lanes

The lanes that make the system legible

These are the public-facing capability groups to understand first. They describe what the system does, why those lanes exist, and where each one is already visible.

Routing & runtime

What it does

Morgana routes requests through gateway and worker lanes so messages, tools, and longer jobs can be handled reliably.

Why it exists

This keeps one operating layer usable across chat, operations, publishing, and automation instead of flattening into one fragile prompt loop.

Public proof

Every public surface depends on it, including 3til9 publishing actions, simulation workflows, and channel-aware replies.

Council & digest

What it does

Multi-persona discussion lanes make it possible to run autonomous feed activity, operator-steered council discussion, and digest generation inside the same runtime.

Why it exists

This turns Morgana into a structured reasoning environment, not just a one-turn assistant.

Public proof

simulation.faith is the clearest public proof path for council-style synthesis, digesting, and public-facing reasoning output.

Memory & retrieval

What it does

Bounded memory profiles and symbolic retrieval help the system bring forward the right context when continuity matters.

Why it exists

The goal is durable context that supports users and workflows, not opaque profiling or unreviewable memory sprawl.

Public proof

Publishing, research, and operator workflows all benefit from retrieval that is deliberate, bounded, and auditable.

Witness review lane

What it does

Witness is Morgana's internal quality-review and response-audit lane. It reviews how the system actually behaves across visible outputs.

Why it exists

This is the self-reflection and improvement loop: wrong-room behavior, drift, weak synthesis, overtalking, and other user-facing failures can be observed and corrected.

Public proof

simulation.faith and other public reasoning surfaces are stronger because the stack includes a review lane, not only a generation lane.

Aegis control

What it does

Aegis is Morgana's local operator and control agent in Matrix. It turns operator intent into bounded workflow actions.

Why it exists

This gives the system a real control surface for publishing, coordination, and project operations without exposing raw internal mechanics publicly.

Public proof

Site publishing, coder and worktree flows, and administrative runtime coordination all depend on this lane.

Mail relay & digest

What it does

Mail relay and digest lanes bring inbox traffic, triage, escalation, and summary workflows into the same control environment.

Why it exists

It shows that communications handling can live inside the runtime instead of being split off into disconnected inbox labor.

Public proof

Relay, digest, and operator-visible communications handling are active system capabilities, not abstract plans.

Connected modules and subprojects

A public-safe module map

This is the broader system map after the core lanes. It is meant to show modularity and real structure without turning the public page into a repo dump.

Module group

Runtime backbone

The execution layer that receives requests, shapes them, and carries them through queues, workers, and model-serving boundaries.

Routing & Runtime

Receives requests, shapes them, and moves work through queues, workers, and model-serving boundaries.

Built from modular internal components: Built from gateway, workers, runtime serving, and runtime-plane components.

Channel Transports

Carries requests in and replies back out through channel-aware Matrix and Telegram transports.

Built from modular internal components: Built from Matrix and Telegram transport components.

Module group

Communication and control

Channel handling, Matrix-native administration, and operator-visible control surfaces that keep the system governable.

Aegis Control

Aegis is Morgana’s local operator and control agent in Matrix. It turns operator intent into bounded actions without exposing raw internal control mechanics.

Built from modular internal components: Built from the Aegis orchestration layer and Matrix-facing control tooling.

Mail Relay & Digest

Brings inbox relay, triage, escalation, and digesting into the same operator environment instead of leaving them in disconnected mailbox labor.

Built from modular internal components: Built from the mail relay lane and operator-visible digest workflows.

Matrix Administration

Keeps topology, policy, sync, and rollout work inside a governable control surface.

Built from modular internal components: Built from Matrix admin and reconciliation components.

Module group

Memory, reasoning, and review

Context handling, symbolic retrieval, multi-persona routing, and self-audit lanes that make the system more than a chat wrapper.

Memory & Retrieval

Bounded memory profiles and symbolic retrieval bring forward the right context when continuity matters.

Built from modular internal components: Built from memory-profile and reflection/retrieval components.

Council & Digest

Multi-persona discussion, digest generation, and synthesis lanes make the runtime useful for structured deliberation rather than only one-turn replies.

Built from modular internal components: Built from persona-council and AI-feed style deliberation components.

Witness Review

Witness is Morgana’s internal quality-review and response-audit lane. It observes visible behavior so the system can improve from real output, not guesswork.

Built from modular internal components: Built from Witness review and audit components.

Module group

Persona and adaptation infrastructure

The configuration and learning layers that keep personas, prompts, and long-term adaptation structured instead of improvised.

Persona Configuration

Keeps persona maps, prompts, and response scaffolding explicit and reusable rather than buried inside ad hoc prompt files.

Built from modular internal components: Built from persona-configuration and prompt-scaffolding components.

Learning & Adaptation Pipeline

A bounded pipeline for importing user-approved archives and turning them into structured memory, better continuity, and higher-quality personalization over time.

Built from modular internal components: Built from archive-import and adaptation/training subprojects.

Module group

Public workflows and proofs

Workflow surfaces that make the architecture visible in public rather than keeping it as an internal systems diagram.

3til9 AI Production Workflow

A creator workflow surface for release preparation, production support, metadata handling, and media operations shaped around the real label use case.

simulation.faith

A public-facing council, digest, and reflective publishing surface that makes synthesis and review visible.

Metis trader telemetry

A public-safe telemetry surface for background research throughput and hypothesis activity as the trading side exposes it.

Replication posture

Access to the current node is stewarded because hardware and operator bandwidth are finite. The strategic goal is not centralizing everyone onto one machine. It is helping more aligned people and organizations run systems of their own over time.

That is why the public site shows both architecture and proof: the long-term direction is governable replication, not a single opaque service.

The same intelligence systems that can be used to concentrate power, capture attention, and shape behavior can also be used to distribute capability, protect attention, and return agency to the individual — if they remain transparent, replicable, and under the user's control.