The war room chat
The chat is the room. Every person, every agent and the organization's own memory read and write to one shared stream, and everything on this page is a projection over that same incident timeline: nothing is rendered from a separate chat service, so a message you see is a message every joined agent can also see, in the same order, at the same time.
How it works
Each row in the chat is one event on the incident timeline, attributed to whoever wrote it. The room draws it with a shape that says who wrote it, and agents read the same event as text. Beacon decides whether to take a turn from one rule, described under When Beacon replies.
Who can be in a room
Four kinds of participant share a room. The room bar at the top of the chat holds them on one row: stacked avatars for people and their agents (a popover lists everyone), one chip for Beacon with its state, and a scope chip whose popover lists what is attached and the sources the room draws on.
- People. Every member with the room open counts as present, whether they have spoken or not; a browser tab alone is enough. Presence is a dot next to the person's initials, present or away.
- Beacon, the room's AI agent. It is always in the room and its state is one of idle, investigating (with its current step) or replying.
- Each responder's own agent. A coding agent joined over MCP, through the
landfallCLI, the Edge companion or a hosted connector, is named after its owner and the host it runs in, for example “Maya's Claude Code”. It is the same contribution either way: an external agent's row belongs to the person who runs it, not to a second identity. - The Company second brain. The scope chip's sources list labels it Org Memory today, with how many memories are in play, alongside the connected integrations and mapped repositories. These are data the room draws on, never an author: a memory entry or a telemetry source cannot post to the chat.
How a message is read
Every row is left-aligned, and who wrote it is legible from its shape and colour alone, without reading the name:
- A person's row carries round initials in that person's own hue, one of the product's categorical colours, consistent across both themes.
- Beacon's row carries a square mark on the accent colour, a hue no participant hue ever reuses, so Beacon is never confused for a person.
- An external agent's row carries a square diamond mark in its owner's hue, with a quiet “via <host>” qualifier after the name.
A finding from Beacon or an external agent never states a confidence as a percentage. Instead it carries a chip from a fixed five-value ladder: observation, pattern match, supported by context, validated, or ruled out. Alongside the chip sit citation chips, one per query, source, code reference and memory entry the finding drew on. Hovering a query chip shows the query it ran; clicking it opens that query on the canvas. A code chip opens the referenced code, and a memory chip opens the memory entry. Below the headline, a folded “how I got here” section holds the run's own queries, collapsed by default so the room reads as a conversation and not a log.
Long messages, past about twelve lines, fold behind a “show more” control. Markdown and fenced code render in the room; the plain text underneath is what every agent actually receives.
The live run row
While Beacon is investigating, the room shows one row per run: a header naming what it is doing, and a checklist of the steps it has narrated so far, the most recent one marked as in progress and the earlier ones checked off. There is no separate typing indicator; the run row itself is the live signal. Once the run ends, the whole row collapses to a one-line summary, for example “6 steps · 4 queries”, that a reader can still expand.
When Beacon replies
Beacon does not answer every message. It decides from the same rule every joined agent and the server itself enforce:
Threads and reactions
Any message can be replied to; a reply renders indented under its parent with a small qualifier, and carries the parent reference so agents read it as part of the same exchange, not a new topic. Every message, from a person or an agent, can carry exactly four reactions, each recorded as an incident event attributed to whoever reacted and visible to every joined agent:
- On it. A person is picking this up.
- Confirmed. What the message says checks out.
- Ruled out. What the message says does not hold.
- Pin to timeline. The message becomes a first-class entry on the incident's Context tab timeline, not only a chat row.
No other reactions are offered; the set stays small on purpose.
Unread and search
A divider marks the first message since a member's last visit, with a jump-to-latest control and day separators for a room that has run a while. History does not reload on every send: it loads incrementally as a member scrolls up, so sending a message never re-downloads the whole room. Members can search the room's messages from the search control in the room bar, and a result jumps to that point in the timeline.
Settings
- The grace window. Settings → Governance, Reply to unanswered questions after, in whole seconds from 0 to 600. Left empty, the organization uses the default of 20 seconds. Only an admin can change it.
- Beacon is listening. A toggle in the Beacon chip's popover on the room bar, per room. Turning it off stops every reply except to a direct mention, for a room that wants to keep the chat to people for a while. Changing it is a person's act, recorded on the timeline.
What an agent sees
A joined agent reads the same events the room renders: a message as its plain text, a reply with the reference to its parent, and a reaction with who made it. A finding or hypothesis another responder's harness shared reaches other agents only once the room admits it to the shared context; see Shared context.
Why it is built this way
A war room fails when people and agents work from different pictures. Keeping the chat on the incident timeline means there is one ordered record, so an agent that joins late reads the same conversation a person scrolls back through, and the postmortem folds the same events. Beacon waits for people before it answers an unaddressed question, so the room stays a conversation between responders with an assistant in it.
What is not here yet
A read-only viewer. A host can render the room with its write access switched off. Such a viewer would see every row, every chip and every reaction exactly as a member does, and none of the controls that change the room: no reply box, no reaction buttons, no listening toggle, no attach or remove control. No shipped host uses this mode yet: the web app and the Edge panel both render the room for a signed-in member with write access.