Pulse

What it does

PULSE is a live incident command room for a production outage. The idea starts with a simple observation: **real incidents are messy, simultaneous, and full of people working on different parts of the same problem.** Most multi-agent demos are not. They tend to turn the incident into a neat sequence: search, analyze, propose, review. Each agent waits for the previous one to finish, and the next step begins only after the last one is done. That is not how a serious production incident feels. Imagine `checkout-api` suddenly goes SEV1 after a deploy. Error rates are climbing, p99 latency is now measured in seconds, and money is failing. In a real war room, nobody sits around waiting for a perfectly ordered pipeline to finish. One person is already looking through the logs. Someone else is checking what changed in the last release. Another person is thinking about a mitigation and may already be preparing a `kubectl` command. At the same time, somebody else is saying, **do not run that against prod.** Those things happen at the same time. PULSE puts those jobs on **one shared incident clock**. When Sentry raises the alarm, it publishes the raw incident lines. Triage sets the incident to SEV1. From there, Archaeologist, Hypothesis, and Fixer each start a Mozaik `runLoop` against that same incident without waiting for one another. Archaeologist looks for evidence in the logs and repository and quotes what it finds. Hypothesis works on competing possible causes instead of immediately settling on one explanation. Fixer works on a mitigation. They are not three steps in a pipeline. **They are three lines of work happening around the same incident.** And while they work, RedTeam is already in the room. This is where PULSE treats safety differently from a simple review step at the end. RedTeam is a deterministic detector for dangerous commands such as `kubectl delete`, `drop table`, `rm -rf`, and others. When it finds one, it can veto **the danger

How the agents run concurrently

Three Mozaik agents run at the same time on **one SEV1**. They are not a pipeline where one must finish before the next starts. >>> Who is in flight together When you run `npm run live`, a Commander message declares the checkout incident. Archaeologist, Hypothesis, and Fixer each call `runLoop` on that same message **without waiting for the others**. That is the concurrency claim. Grep `src/mozaik-live.ts`. Each start emits `LoopStarted` with shared `t_ms`. Mozaik Cloud shows those three agents, usually one loop each. Fixer may show a second loop when a veto forces a pivot. Sentry and Triage are the alarm and severity — not extra paid loops. RedTeam is on the same runtime and scores Fixer output; it only loops if a pivot runs. Commander is a human (`createHuman`). Facts and Comms observe landed events. Six wall panels are not six models. >>> What they share They share one runtime, one incident, one event bus, and one clock (`t_ms` from incident start), plus the same SEV1 context: service, symptom, deploy tag, logs, repo snippets. They do **not** share a turn token. Archaeologist does not have to finish quoting before Hypothesis starts. Fixer does not wait for either. Overlap is time, not a hand-off. The wall does not invent activity. Header, ticks, Facts, and the swimlane come from the bus. Stacked bars mean two participants emitted in the same window. >>> How they coordinate They coordinate with events and a veto, not a chat queue. Fixer drafts. `findVeto()` in `src/veto.ts` can emit `VetoIssued` on a dangerous span (`kubectl delete`, and similar). That can start Fixer’s safe pivot. Commander Join / Send / Leave are bus events; `do not delete` pulls the same gate. Replay uses that bus and detector with no API key. Live uses real `runLoop`s. Mid-token live intercept is not claimed.