Multi-Agent · tamux

What multi-agent means

The system hosts multiple specialized personas rather than pretending one generic assistant can cleanly represent every mode of work. Each persona has its own identity scaffold and role logic, but the daemon remains the common authority for state.

Important distinction: the agents are specialized fronts over one shared runtime, not isolated separate applications.

Shared substrate, distinct personas

Shared across all personas

Threads, tasks, goal runs, approvals, task queue, provenance, memory files, operator model, and persistent daemon state.

Distinct per persona

SOUL identity, role emphasis, response style, and how the persona is used in visible threads, hidden coordination, or governance review.

This split matters because it allows tamux to have real specialization without losing continuity when work moves between agents.

Why personas exist

Svarog drives primary execution, planning, tool use, and durable work.
Rarog provides lightweight guidance, onboarding, summaries, and conversational glue.
Weles adds governance, risk review, skeptical inspection, and guarded friction.
Other fires can be configured for narrower roles such as fast implementation, maintenance, synthesis, or architectural review.

The point is not mythology for its own sake. The point is to encode specialization into runtime behavior and operator expectations.

Multi-agent does not mean chaotic

tamux keeps multi-agent work legible by using thread ownership, participant registration, hidden delegation, and explicit handoffs rather than letting all agents speak at once. A thread always has a current owner. Other agents may participate or advise, but ownership stays visible.

Current thread owner
|
+-- visible participants (@agent)
+-- hidden internal delegates (!agent)
+-- explicit ownership handoffs
+-- shared daemon memory and task state

Shared memory makes it coherent

The shared daemon-owned memory stack means that handoffs and sub-agents do not need to rebuild the entire world from scratch. Identity memory, durable fact memory, operator profile, structured runtime state, recall systems, and provenance all give the multi-agent environment continuity.

Why this matters: without shared durable context, “multi-agent” usually degenerates into multiple disconnected chats. tamux avoids that by making the daemon the memory authority.

Where capability shows up

Capability	How it shows up	Why it matters
Visible participants	`@agent ...` on the current thread	Lets specialists watch and contribute without changing ownership
Hidden coordination	`!agent ...` internal delegation	Keeps behind-the-scenes checks out of the visible thread when needed
Handoff	Explicit ownership change to another persona	Makes thread control honest when another agent should lead
Subagents	Bounded child work with budget and tool filtering	Splits large tasks without collapsing into unbounded delegation
Collaboration protocol	Shared state, contributions, disagreements, and voting	Turns multi-agent work into inspectable coordination

What makes tamux good at it

The daemon owns the shared state.
Personas are explicit and role-shaped.
Visible and hidden coordination are separate mechanisms.
Thread ownership is explicit rather than ambiguous.
Goals, tasks, approvals, and provenance remain common infrastructure.
Memory and learning loops let work compound instead of reset.

Beyond fork-join

The more advanced direction is explicit peer-style collaboration: agents sharing working memory, surfacing disagreements, and voting with confidence rather than only following a simple fork-join hierarchy.

What would make it fail

The multi-agent model would fail if every persona were configured identically, if ownership were implicit, if hidden delegation replaced visible control, or if shared memory were weak. The current architecture is designed specifically to avoid that collapse.