JL Jake Lozano
← Writing

IR-Bridge: a lean IR triage tool I built for myself

June 27, 2026

For how I actually work a detection, most enterprise IR ticketing gives me far more surface than I want. Observables panels, correlation graphs, an investigation tab, auto-parsed labels, a wall of buttons I’ll never press. It looks powerful in a demo. In the middle of an investigation it’s friction. I spend attention navigating the tool instead of working the detection, and every extra tab is one more place context goes to hide.

Here’s what I want instead: a clean, markdown-first ticket manager where an analyst writes their notes and attaches their evidence. A timeline. A screenshot. Maybe a .csv. All on one page. The moment I have to jump between tabs to assemble what I already know, the tool is working against me.

So I built it. It’s called IR-Bridge.

The whole philosophy is subtraction

The hard part of a tool like this isn’t what you add. It’s what you refuse to add. It’s easy to anticipate every feature someone might want and end up with the mess we click through every day. IR-Bridge only includes what an analyst reaches for on a real detection. One page. Markdown notes. Evidence inline. Severity as a plain label, not a colored badge fighting for your eye. If a control doesn’t earn its place in a real investigation, it isn’t there.

Why I could build the lean version

The hard part isn’t writing the tool, it’s knowing what to leave out, and that only comes from working detections for years. Which fields get used and which get skipped. Which screen an analyst actually lives on. Where the flow breaks under pressure. Design without that and you ship what you assume IR needs: the same bloat under a new logo.

I started by testing an existing open-source IR platform. It’s capable, but I wanted full control over exactly what an analyst sees and nothing they don’t, and that meant building from scratch.

Agentic-first, not agent-bolted-on

This is what makes IR-Bridge more than a lighter ticket manager: the agent, not the UI, is the point.

Detections arrive as raw JSON, straight from whatever fired them. That raw payload is the input to an agentic pipeline, not a form for an analyst to fill in. The unit of work is a detection (IR-NNNN), and the primary action is Investigate.

Investigate runs the detection through layers. A deterministic parse and normalize of the raw payload first, ground truth with no model in the loop. Then enrichment, pulling in the context the raw event didn’t carry. Then an agent interprets the parsed detection and its enrichment and posts a structured verdict, with its evidence and a confidence level, to the timeline. The analyst opens the detection to a finished assessment instead of building one.

It’s my first real attempt at an agentic-first IR ticketing system rather than a traditional one with AI sprinkled on top. The pipeline is the product. The lean UI is just what becomes possible once the agent carries the weight underneath it.

Under the hood

IR-Bridge is a working stack, not a mockup:

To be clear about where it stands: this is a personal build on synthetic data, and the platform enrichment is still a seam, currently stubbed, waiting on a live connector. The bones are real, some of the plumbing isn’t.

The IR-Bridge detection queue, sorted by severity

The takeaway

Lean isn’t a compromise for incident response. For how I work a detection, it’s the requirement. The whole thing fits in one person’s hands: a web client, a terminal client, an agent, and a test suite. The agent does the legwork, and the analyst gets a verdict with its evidence already assembled. That’s the bet, and it’s the part I’m still sharpening.