IncidentBridge

Inspiration

Recruiting bots and sales-outreach agents are the two examples AICOO leads with in their own docs, so I figured most of the hackathon would build one of those. I wanted something with actual stakes attached to the moment two agents talk, not just a nicer scheduling flow. An outage does that on its own. Nobody's negotiating a salary. Somebody's payment API is down, a real customer relationship is on the line, and the question of who gets to see what isn't a nice-to-have, it's the whole reason a vendor can't just paste their internal Slack thread into a support ticket. That felt like the sharpest version of what AICOO is actually for.

What it does

An incident starts (payment API down, in the demo). The vendor's on-call agent and the client's ops agent each hold their own private context, the vendor knows internal service names and deploy details, the client knows their own traffic and SLA tier, and neither one can see the other's private fields by default. They exchange messages back and forth through AICOO, each one sharing only what it's permitted to share, with anything withheld shown clearly on screen instead of just quietly missing. When the vendor's proposed fix is a rollback that would affect other customers, both agents stop mid-conversation. A human has to approve or deny it before anything moves again. Once approved, the incident resolves and the timer stops.

How we built it

Next.js on the frontend, one page holding all the state so both panels and the approval modal stay in sync off a single source of truth instead of drifting apart. Two Claude calls handle the agent reasoning, one persona each, both built off the same prompt template with different allowed-field lists swapped in. The AICOO piece sits behind a small wrapper module so the rest of the app never talks to AICOO's API directly, it talks to sendMessage() and getMessages(), which made it possible to keep building the UI even in the twenty minutes I spent figuring out AICOO's actual request shape.

The escalation trigger is not left up to the model. Early on, I had the LLM self-report whether its proposed fix needed human sign-off, and it was right most of the time, which for a live demo is a different thing from right every time. I moved that check into a plain rule: if the proposed fix is a rollback and the incident data says it affects other customers, it escalates. Full stop, no exceptions, no model judgment call in the loop for that specific decision.

Challenges we ran into

AICOO's public docs don't spell out every endpoint shape, so the first real hour went into getting one message to pass between two identities before any UI existed at all, on purpose, because that's the piece with the most unknowns. Once that worked, everything downstream was ordinary web development.

The redaction was invisible in early versions. Withheld fields just weren't rendered, and on a small demo screen that reads as nothing happened rather than as something was deliberately kept private. Adding a lock icon and the literal word "redacted" fixed it in about ten minutes, but I wouldn't have caught it without watching a test run and asking why the demo felt flat.

Accomplishments that we're proud of

The escalation freeze is the moment that actually lands. Watching both panels stop and a real approval prompt appear, instead of the agents just quietly deciding for you, is the one beat where people watching the demo visibly react. Getting a full exchange running between two genuinely separate AICOO identities, not two components pretending to be separate, mattered more to me than I expected going in.

What we learned

Making a permission boundary functional and making it visible are two different problems, and the second one took longer. It's easy to write code that correctly withholds a field. It's harder to make a stranger glancing at a screen for ten seconds understand that something was withheld on purpose. The lock icon fix taught me that the interesting part of a product like this isn't the logic, it's finding the one visual choice that makes the logic legible.

What's next for IncidentBridge

Real incident data instead of a scripted JSON file, probably a PagerDuty or Datadog webhook feeding the incident object. Right now the redaction rules are hardcoded per persona; the obvious next step is letting each company configure its own field-visibility policy instead of me deciding it for them. And if AICOO ships native field-level permission scoping, that's a clean swap for the redaction logic I wrote by hand, worth revisiting once the docs catch up.

Built With

• aicoo-api
• anthropic-claude-api
• next.js
• react
• tailwind-css
• typescript