Firebro

Inspiration

Incident response is one of those workflows where an AI agent could genuinely save time, but it is also a workflow where giving an agent unrestricted control would be a terrible idea.

During an outage, engineers jump between service health, deployments, logs, traces, alerts, runbooks, and incident timelines while trying to answer a few basic questions:

What changed? What is actually failing? What evidence supports that diagnosis? And what is safe to do next?

I wanted to explore what incident response looks like when the agent can work inside the same operational console as the human instead of operating through a separate chatbot or a disconnected API.

That became Firebro.

The design principle behind the project is simple:

Agent capability, human authority.

What it does

Firebro is an incident response console built around WebMCP.

An agent can investigate an active incident by checking service health, dependencies, recent deployments and changes, logs, traces, alerts, metrics, runbooks, and the incident timeline.

It can correlate that evidence, identify a likely cause, and propose a remediation.

For example, one incident starts with degraded checkout performance after a bad deployment. The agent can compare service metrics, inspect traces and logs, find the deployment that introduced the regression, and propose rolling it back.

But the agent cannot simply execute a consequential remediation on its own.

Actions such as a rollback can require an approval tied to the exact proposed action. The approval has to come from a real human interaction in the console before the action can proceed.

Once remediation starts, the simulated production environment reacts. Metrics recover, logs change, and the incident moves through recovery and monitoring before it can be resolved.

Firebro includes multiple deterministic incident scenarios so the correct response is not always "roll back the latest deployment." Some incidents involve resource exhaustion, feature flags, memory leaks, or even third-party failures where the best action may be to wait rather than make an unnecessary production change.

How I built it

Firebro is built as a web-based incident console with a WebMCP capability layer on top of the same operational state visible to the human operator.

The system exposes tools across the full response workflow: incident discovery, service health, dependencies, deployments, recent changes, logs, traces, metric comparisons, alerts, runbooks, incident notes, remediation actions, approvals, and incident resolution.

One of the main implementation goals was avoiding a separate "agent version" of the application.

When an agent investigates something, the console reacts too. A service can be highlighted in the topology, log views can focus on relevant entries, metric comparisons become visible, traces can be surfaced, and approval requests appear next to the operational evidence the human needs to make a decision.

Tool availability also depends on context. Capabilities can change based on the selected incident, current incident state, and what actions are currently valid.

The backend runs a deterministic incident simulation. Each scenario has a known underlying cause, but that ground truth is intentionally hidden from the WebMCP tools. The agent has to diagnose the incident using the same observable evidence available through the console.

Mutations and incident events are persisted so the UI and tool layer stay synchronized as the incident evolves.

Challenges I ran into

The hardest part was making the environment realistic enough that the agent actually had to investigate.

If every incident simply had an obvious error message pointing to the answer, there would be no real diagnostic workflow. Firebro includes misleading signals and plausible alternatives so the agent has to correlate evidence instead of choosing the loudest symptom.

Another challenge was tool design.

Returning thousands of raw log lines or metric samples makes an agent less useful, not more useful. The tools needed to expose enough evidence to support a diagnosis without turning every response into an unstructured data dump.

I also had to think carefully about approvals.

A generic "approved: true" flag would not be enough for a real operational workflow. Approval has to be tied to the exact action being proposed so an approval for one operation cannot silently authorize another one.

Keeping the simulation deterministic was another important challenge. The same incident needs to behave consistently enough for automated evaluation while still looking like a live operational system.

Accomplishments that I'm proud of

I'm most proud that Firebro feels like one shared workspace rather than a dashboard on one side and an agent on the other.

The agent works with the same incident, graphs, logs, services, and actions the human is looking at.

Investigation has visible consequences in the interface, and consequential actions pass through an approval workflow instead of bypassing the operator.

I'm also proud of the incident simulation itself. Different scenarios require different forms of reasoning, and remediation does not always produce an immediate perfect recovery. Some actions only partially help, some have no effect, and the system can regress if the diagnosis was wrong.

That makes it possible to evaluate more than whether an agent can successfully call a tool.

What I learned

The biggest thing I learned is that agentic interfaces need more than a large tool list.

The useful part is the structure around those tools: when they are available, what evidence they return, how their effects appear to the human, and what happens when the agent is wrong.

I also learned that human approval is much more useful when it happens next to the evidence supporting the action.

Asking someone to approve a rollback in isolation is very different from asking them while they can see the deployment, affected metrics, traces, and the agent's proposed action in the same console.

WebMCP also made browser context much more important than I originally expected. The agent is not operating a remote service in the abstract. It is operating the application the human currently has open.

What's next for Firebro

The current version uses deterministic simulated infrastructure so incidents can be reproduced and evaluated reliably.

The next step would be connecting the same interaction model to real observability and incident-management systems while keeping the approval boundary intact.

I'd also like to expand the scenario set, add more complex multi-service failures, improve automated agent evaluations, and explore richer policy controls for actions with different levels of operational risk.

The long-term idea is not an autonomous system that replaces the incident commander.

It is an incident console where an agent can do far more of the investigation and coordination work while the human keeps authority over decisions that can affect production.

Built With

• css3
• fastify
• html5
• javascript
• netlify
• netlify-blobs
• playwright
• react
• recharts
• tailwind-css
• typescript
• vite
• webmcp