A Map of the SOS Brain

SOS is easiest to understand if you stop thinking of it as a chatbot harness.

It is closer to an operating system for a small company: a bus, a memory layer, a task system, a scheduler, a lifecycle monitor, and an economy that decides which kind of compute is worth spending. The “brain” is the part that keeps looking at that state and asking one narrow question:

What is the single next action that should happen now?

That sounds simple. It is not. The hard part is keeping the answer grounded in the real system instead of letting a model invent work, duplicate work, or route a task to an agent that is not actually available.

This is the map.

#The Short Version

The SOS brain runs a loop:

1. Perceive: collect current state from the portfolio, services, tasks, memory, and triggering event.
2. Think: ask the planning model for one concrete action in a strict JSON shape.
3. Act: execute only supported methods such as task creation, health checks, research dispatch, or content generation.
4. Remember: store the cycle result back into Mirror so future agents can recover the context.
5. Report: publish the result to the bus, Discord, and operational tables where configured.

The brain is not the whole system. It is a coordinator sitting on top of several primitives. If those primitives are weak, the brain becomes a noisy task generator. If they are strong, the brain becomes a useful pressure system: it finds the next useful movement and pushes there.

#The Inputs

The brain does not start from an empty prompt. It gathers state.

The current path favors a portfolio snapshot from the cortex layer. If that is unavailable, it falls back to direct recall from Mirror, active goals, active objections, pending tasks, metabolism status, and service health. Event-driven runs add the triggering event to the prompt so a task.completed wakeup is not treated the same way as a budget.exhausted wakeup.

That distinction matters. A brain that wakes on every bus message without event context will eventually manufacture work. A brain that knows why it woke has a better chance of doing something proportional.

The important inputs are:

• Portfolio state: what products, customers, and projects need attention.
• Task state: what is already queued, claimed, blocked, failed, or complete.
• Memory: what the system has learned before, stored as retrievable engrams.
• Metabolism: budget and model-cost information.
• Service health: whether the bus, Mirror, engine, and adjacent services are up.
• Trigger event: the concrete reason this cycle started.

#The Decision Core

The decision core is intentionally narrow. The prompt asks for one JSON object with:

• action
• goal_id
• agent
• method
• details
• expected_progress
• risk

The method field is the key safety boundary. The brain can propose many things, but the motor layer should only execute known methods. In the current code path, supported methods include create_task, post_content, send_outreach, fix_code, research, and health_check.

That is a practical rule: models can write prose, but production systems need a small command surface.

#The Motor Layer

The motor layer converts a proposed action into an actual system mutation.

If the method is task-creating, it checks availability and scope, then routes through either Squad Service or Mirror. Squad Service is used when the project maps to a squad. Mirror is used for older or non-squad paths. The title, labels, project, assignee, priority, budget, and result shape become persistent state.

This is also where the brain needs to be strict. A model may produce a method that sounds plausible but does not exist. It may propose a cleanup that was valid two weeks ago but stale today. It may see old fixture tasks in the backlog and decide that the best work is to delete them again, creating a new task to delete old tasks, forever.

The fix is not a better pep talk in the prompt. The fix is a guardrail in the motor layer: unsupported methods fail, stale directives are skipped, and historical fixture cleanup cannot enqueue another round of cleanup work.

#The Bus

The bus is the nervous system.

SOS uses Redis streams and pubsub. A direct message to an agent lands in that agent’s stream and publishes a wake event. The wake daemon can then inject the message into a terminal session. The important property is persistence: a message is not just a transient notification. It remains available for later recovery.

This is what makes agents feel less like isolated tools. Codex can tell Kasra what changed. Kasra can hand a deployment constraint back to Codex. The brain can report what it attempted. None of that requires a human to copy context between terminals.

#The Squad Service

Squad Service is the task operating layer.

It stores tasks, statuses, priorities, assignments, labels, dependencies, runs, events, artifacts, and project scope. Agents do not just “start working.” They claim a task. Claiming is the difference between a queue and a coordination system: it prevents two agents from doing the same work and gives the rest of the system a durable record of ownership.

This matters most when the system is noisy. If a bad loop creates thousands of stale tasks, the queue itself tells the truth. You can inspect it, count it, back it up, drain it, and verify that the active backlog changed.

#Mirror

Mirror is the memory layer.

The brain writes cycle records into Mirror. Agents write observations, decisions, handoffs, and technical findings into Mirror. Later, a different model can retrieve those records semantically. The point is not to preserve chat history. The point is to preserve operational knowledge in a form another agent can use.

Without memory, every agent starts cold. With memory, the system starts to compound. A bug fixed by one agent becomes searchable context for the next one. A gate decision becomes an architectural precedent. A failed deployment becomes a future warning.

#Lifecycle

Agents are not stable processes in the way ordinary services are stable processes.

They compact. They hang. They hit quota. They lose context. Their terminal sessions die. They wait at prompts while work exists elsewhere.

The lifecycle layer watches for those states. It is not the brain itself, but it changes what the brain can safely assume. A task routed to an unavailable agent is not progress. A wake event delivered to a dead session is not delivery. A queue full of stale fixtures is not real demand.

In a multi-agent system, liveness is part of correctness.

#Economy

The economy layer is what keeps autonomy from becoming a blank check.

Different models have different costs and strengths. Some work can run on cheap or free models. Some work needs a stronger reviewer. Some work should not be done autonomously at all. The brain’s prompt includes budget pressure because “use the best model for everything” is not an operating system. It is a spending bug.

The practical goal is not to minimize cost. It is to spend only where the work justifies it.

#The Feedback Loop

When the brain completes a cycle, it reports and remembers. That output becomes future input.

This is the loop:

event -> context -> decision -> action -> task/result -> memory -> next context

If the action was useful, future cycles see the changed state. If the action failed, future cycles see the failure. If the action was skipped because it was stale or unsupported, that skip becomes visible too.

A system like this does not get safer by pretending models never drift. It gets safer by making drift observable and non-destructive.

#What This Enables

The architecture is not interesting because it can produce tasks. Any script can produce tasks.

It is interesting because the same primitives support real company work:

• A customer request can become a bounty.
• A bounty can become a squad task.
• A squad task can be claimed by an available agent.
• The result can be written back to memory.
• The next agent can recover that context without asking a human.
• The brain can notice the new state and choose the next action.

That is the difference between automation and an operating substrate.

Automation runs a command.

An operating substrate keeps enough state to decide what command should run next.

#The Failure Mode To Watch

The failure mode is stale context becoming fresh work.

If the system contains old test fixtures, old cleanup instructions, old sprint directives, and old task names, a model may treat them as current demand. The output can look reasonable: “clean up the old test quest tasks.” But if the cleanup task itself is created as another task, and no one claims it, the next cycle sees the same stale world plus one more cleanup task.

That is how a brain becomes a loop.

The durable fix has two parts:

• Drain the stale state from the task layer.
• Make the motor layer refuse to recreate that class of work.

Prompt instructions help. Runtime guards matter more.

#The Mental Model

Think of SOS as a small nervous system for work:

• Cortex Events wakes the brain when something happens.
• The Brain chooses one next action.
• Squad Service turns work into durable, claimable tasks.
• The Bus lets agents coordinate.
• Mirror keeps memory across sessions and models.
• Lifecycle keeps agents from silently disappearing.
• Economy keeps intelligence spending bounded.
• Agents execute the work and return state.

The system is not magic. It is a set of boring primitives arranged so that models can participate in a company without being trusted to hold the whole company in their prompt.

That is the real shape of the SOS brain: not a superintelligence, but a disciplined loop over durable state.