Skip to main content
A War Room is the shared workspace for one incident or operational activity. It connects named people and agents around a purpose, selected history and an expiry. The shared timeline holds the questions, findings and decisions needed to coordinate the work. Each organization keeps its private agent work, conversations and credentials outside the room. An incident’s room can start with only your own operators and agents. When Tensor9 support or another specialist is needed, invite the exact participant into that existing investigation. The room’s shared bus is hosted on the customer side by default. That arrangement does not give either organization access to the other’s private journals or context.

​
What is shared and what stays private

Publishing a finding creates a selected shared record. It does not expose the source organization’s journal or let a participant browse adjacent tasks. A room participant cannot infer access to raw source material from a summary or reference.

​
Invitation, acceptance and admission

A room has three separate participant steps:
  1. Invitation: a manager names the intended person or configured agent and the permitted room scope and lifetime.
  2. Acceptance: that exact recipient accepts the invitation. A human cannot accept on behalf of an agent identity merely by selecting its name.
  3. Admission: the customer’s current authority admits the accepted participant to the applicable shared work.
A pending invitation exposes only the recipient’s permitted invitation details. It does not disclose the room’s participant list, prior conversations or evidence history. New admission does not automatically make all earlier room content available. Room management, participation and access to the customer environment remain separate. A participant may be allowed to ask a question without being allowed to invite others or approve a change. A Tensor9 support request does not itself authorize any operation in your target environment.

​
Direct work to an agent

A message can ask a named admitted agent to perform supported bounded work. That requires a current configured identity and a qualified inbox for the exact participant and admission. A provider listing or a registered recipe alone does not establish that the agent can receive or execute the request. The message and work record retain their relationship. Delivery of the message, acceptance of the work, completion and publication of a result remain separate facts. A duplicate notification does not create another task. A completion notice can point to a result without copying private tool evidence or model commentary into the room. Changing an agent definition, replacing its runtime or removing and readmitting a participant does not transfer the previous assignment or evidence releases to the replacement automatically. The current identity and admission must match the requested work.

​
Release evidence deliberately

For each shared item, identify the source revision, named recipient, purpose and expiry. Include the observation time and limitations that matter to the question. A fresh publication time does not make an old measurement current. Review the actual material the recipient will receive. A useful release might contain the effective service mapping, a bounded operation summary and a redacted error excerpt. It need not include message bodies, application source, credentials or unrelated service logs. A release to a room participant and permission to process it with a model provider are different decisions. The processing request must cover the selected evidence, processor, purpose and payer arrangement. Room membership does not supply that consent. Explain’s agent format changes presentation, not sensitivity. PostgreSQL planning evidence retains full plan JSON, including relation and index names, predicates and application literals. Room admission does not grant access to the original report. Its exact original IAM owner, including the same temporary session where applicable, retrieves it and releases a reviewed exported copy. Review the exported copy before sharing; see Debugging with Agents. Withdrawal or expiry stops later permitted retrieval and replay through the service. It cannot erase a copy a recipient has already downloaded. If you export an attachment through another channel, apply your approved sharing process there too.

​
How participants catch up

The room’s authorized feed is backed by retained records. Notifications wake participants to retrieve updates; the notification is not the history itself. A reconnecting client receives a permitted snapshot and the later updates it needs, retaining its progress as a checkpoint. Catch-up uses current access. A withdrawn participant cannot use an old notification or checkpoint to regain history. Another participant’s wider access does not widen yours. Replaying the room timeline reconstructs the view of work; it never repeats the original tool call, model request or resource change.

​
Worked example: investigate queue latency with Tensor9

Your team reports slower processing for checkout-events, an adapted SQS service in Google Cloud.
  1. Establish the customer context. Keep the room attached to the actual Cloud Adapter, reported incident, original configuration and affected environment. Record the impact and time window as a human report. Do not label it a measured service failure before the evidence supports that conclusion.
  2. Investigate privately first. Your included agent assesses the configured mapping. Separately permitted runtime checks establish the available queue, consumer and backend observations. Your SRE agent can compare workload changes without sharing its private working context.
  3. Admit the support investigator. Invite the named Tensor9 participant, obtain its acceptance and admit it for the investigation. This grants the applicable room view, not target-cloud access.
  4. Release a useful evidence set. Share the relevant mapping findings, reviewed diagnostic derivatives, observation window and explicit gaps. Keep the raw private records. A later request for more evidence is another disclosure decision.
  5. Receive an attributed proposal. Tensor9 investigates the released material and returns its explanation, contrary evidence, uncertainties and a proposed next check or change. A successful private Tensor9 reproduction does not establish the outcome in your environment.
  6. Approve and verify separately. The customer reviews any exact change and its cost, preconditions, recovery steps and stopping conditions. An authorized executor performs the approved work. Fresh customer-side observations establish whether it helped.
The room preserves the chain from question to evidence, proposal, decision, actual action and verification. Participants can see where the investigation stopped and which person or agent owns the next step.

​
Close the room without losing unresolved work

Record what was established, what changed, who performed it, how the result was verified and what remains unknown. Revoke temporary access when the collaboration ends and retain the customer’s selected operational evidence according to its retention policy. Closing an incident or room does not cancel an accepted operation, prove recovery or settle an uncertain model charge. Keep the original work and operation references for reconciliation. For a resource or runtime change, follow Bounded Work and Approval; for request evidence, use the debugging workflow.