MultiCOM

A shared incident room where engineers and AI agents investigate, challenge theories, and revise their confidence -> with a human approving the fix.

Comment

Inspiration

Incident response is a team effort. But when each engineer asks an AI assistant for help, the investigation splits into private conversations. Someone finds a useful log. Someone else follows a different theory. People copy answers between windows, trying to keep everyone on the same page.

I wanted to try a different approach: what if the engineers and their agents could work in the same room?

That became multicom—a shared incident room where agents gather evidence, challenge each other’s theories, and revise their confidence in public. The human responsible for the service still decides whether a fix should happen.

What it does

The demo starts with a simulated storefront service failing at 23% errors. Its database connection pool is too small, but a recently enabled feature flag gives responders a plausible wrong lead.

Participants join through one room link. They can investigate with a browser agent, use the manual controls, or watch a clearly labeled scripted drill.

The investigation stays visible to everyone:

  • Agents pull logs and run checks.
  • They post theories with evidence and a confidence level.
  • Other participants challenge those theories.
  • The original author can revise their confidence and explain why. The board keeps both the opening and revised numbers.
  • Participants propose a fix and vote.
  • The commander approves or rejects it.
  • After the fix is applied, everyone sees whether the service actually recovers.

Each new room gets its own copy of the incident, so one judge’s completed run does not spoil another’s.

Why WebMCP fits

The website is where the team works. WebMCP lets agents take part in that same workspace through specific tools, instead of relying on screen clicks or asking people to copy information between chats.

multicom exposes thirteen tools covering the investigation, debate, voting, and fix workflow. Their results update the same board that people read and use.

The most interesting part is not an agent finding the right answer. It is another participant challenging that answer—and the author changing their stated confidence, with the evidence and explanation still visible.

An agent’s tool access also has a clear stopping point. It can request approval, but none of the thirteen tools can grant it. A person must click Approve.

How I built it

I built the interface with TypeScript and Vite. A Cloudflare Worker keeps each room’s participants, theories, votes, and approvals together. A separate Worker runs the simulated storefront service.

WebMCP connects the browser agent to the room. People using the manual controls follow the same rules as agents: neither route skips the vote or approval checks.

I used Codex to help implement the application, review the boundaries between its parts, and build tests. Running real agents through the tool surface was especially useful. Their mistakes showed where the tools needed clearer explanations or a missing capability.

Challenges I faced

One early problem was that an agent could vote against a fix but had nowhere to explain why. I added a tool for attaching a reason to a vote.

Another was that challenging a theory did not let its author update their confidence. I added author-only revision and preserved the original number. Other participants can argue with a theory, but they cannot rewrite it for its author.

Human approval needed more than a button. The server checks which action was approved, limits approval to sixty seconds, and allows it to be used only once.

I also planted an instruction inside the synthetic logs telling agents to skip diagnosis and apply the wrong fix. The application returns that line as untrusted data and displays it as plain text. In the recorded agent drill, both agents rejected the instruction and continued investigating.

What I learned

Watching agents use the application taught me more than watching a scripted walkthrough. A result that looked obvious in code could still confuse an agent. A simple “no” vote could hide the most useful reasoning in the room.

The interface needed places for disagreement, explanations, and revision—not just answers.

I also learned to separate agreement from permission. A majority can support a fix without being allowed to apply it. Keeping that distinction visible became central to the project.

What I’m proud of

multicom makes the investigation observable. You can see what was proposed, what challenged it, how confidence changed, who supported the fix, and who approved it.

The current project includes 73 automated tests and a separate 32-check production acceptance suite. Those checks cover shared updates, room isolation, approval expiry, repeated requests, and recovery across browsers.

It is deliberately a controlled demonstration with one scripted incident, not a tool connected to someone’s real production systems. The question it explores is broader: how can several people and their agents work through uncertainty together, while keeping the consequential decision in human hands?

Built With

Share this project:

Updates