Hiro: an ops triage console that acts on its own

The overnight pile, and the question underneath it

Whoever is on call for operations wakes up to a mess made while they slept: an inbox that filled overnight, a Slack thread they've fallen behind on, a payments dashboard, a data warehouse, an issue tracker. Each tool holds a fragment of the same events. The first hour of the day goes to reconstructing what happened, and the second goes to deciding what actually needs a person. Most of it is routine. A handful of items carry real judgment, and you can't tell which is which without reading all of it.

Software that can act could clear most of that pile. Agents can read the inbox, diagnose the failed run, pause the retry loop, draft the incident note. The moment you let them, though, a sharper question appears: when may the agent just act, when must it stop and ask a person? And the part almost nobody designs for: where does that question go? Hiro is the prototype we built in a design sprint to answer those three questions on one screen. It's a design exploration, not a shipped product, and the rest of this piece walks through what we learned drawing it.

The agent gets a channel to you

Almost every AI tool you can buy today is chat-first. The human opens a window, types a request, and the agent responds; when the human closes the window, the relationship is over until the human comes back. That shape quietly caps what the agent can do for you. Work that happens while you're asleep has no way to raise its hand. Decisions queue up silently inside a tool you aren't looking at.

Hiro turns the channel around. The agent works through the night on its own, and when it hits a decision that belongs to a person, it reaches out. The question arrives with its context, its evidence, and a recommendation, addressed to the human who owns the call. You're still in the loop before anything consequential happens. But you're in it the way a captain is: the agent brings decisions to you, rather than you patrolling the software to find them. We wrote about why that distinction matters in The Tideline: the helm is where a person belongs, and the middle of the work is where they drown.

Our goal is to take this beyond one console: we intend to launch Hiro as an MCP server, so that any agent (a coding agent, an ops agent, a back-office workflow) can use it to ask its human what needs to be done, and get an answer it can act on. The human becomes someone the agent has access to, through a surface built for exactly those requests.

When it may act, and when it must ask

A channel to the human only works if the agent knows when to use it. The prototype draws that line with a rule simple enough to fit in a footer, and the demo scenarios exercise both sides of it.

The software may act when an action is safe, reversible, and inside a stated threshold. It must ask when an action is public, irreversible, or over the line.

The may-act/must-ask boundary. One quadrant is the agent's; the other three arrive as questions with evidence attached.

In the demo run, the agent diagnoses a failed finance_hourly sync, traces it to an expired warehouse credential, pauses the schedule so it stops retrying, opens the incident, and drafts the note. All of that is autonomous, all of it logged with evidence chips (the ticket ID, the 03:14 UTC timestamp). Pausing a job that's already failing costs nothing and buys time, so the software just does it.

Then it stops. "Want me to notify the finance channel, or hold until you confirm the credential?" Posting in a shared channel speaks to other people on the team's behalf and can't be un-said, so the agent turns it into a question. The refund thread shows the other half of the rule: a $1,240 refund lands over the $500 auto-approve line, the agent pulls the account, finds two partial refunds already this quarter, and says so plainly: "The pattern is unusual. I would hold and ask billing before approving." It prepares the decision and hands it up with the history attached. It does not approve.

Notice what the threshold is doing in both cases. It isn't just gating a dollar amount; it defines which decisions have a human owner. And because the operator set the line, an empty queue is believable. Everything under it was handled, everything over it came to you, and the log shows both.

The console is the human's end of the channel

If the agent can reach the human, the human needs a surface where those requests land—one that makes answering fast and checking easy. The prototype's answer has two parts: a transcript you can talk to, and a plan you can watch.

The center of the screen is a running transcript: the agent's messages, the actions it took, the operator's replies, in the order they happened. Triage reads like a handover note because that's what it is: the failed run appears as a beat in a sequence (the failure, the diagnosis, the action, the question back to you) instead of as a red tile on a dashboard. And because the surface is a conversation, answering is natural: in the demo the operator holds the mic, sends a four-second voice note asking the agent to notify the channel and loop in a teammate, and the agent's confirmation comes back beneath it. No form, no modal.

The right rail holds the plan: a live checklist of the run, marked 4/6 in the demo: scan the inbox, auto-clear the routine, hold the exceptions, diagnose the failure, notify finance, resume the schedule. What builds trust is the step that's visible but not started: resuming the schedule waits on a human-owned event, and you can see it waiting. The plan discloses intent before intent becomes action. Below it sits the working set (the incident file, the triage log, the ticket link), so checking the agent's work is one click, never an act of faith. Even the actions the agent is cleared to take alone leave a card in the transcript; silent autonomy is the one convenience the design refuses, because an operator who can't reconstruct why something happened will stop trusting the queue entirely.

One color rule ties the surface together: rose belongs to the machine, and nothing else. The agent's name, its voice replies, and every AGENT · AUTONOMOUS ACTION card carry it. In a mixed transcript of human and machine turns, who did this is the one thing a reader must never get wrong, and color answers it before you've read a word.

What the ratio buys you

The demo's numbers are synthetic, but they're shaped to show where the value sits: an overnight run takes 214 items down to 5 held for a person, and the mock weekly digest shows 8,400 ops emails with 97.6% resolved without escalation. The point of a screen like this isn't the volume it clears. It's that the five items that reach you arrive as decisions, each with its evidence, its history, and a recommendation, so the judgment part of the job gets your full attention and the rest of it gets none.

Hiro is one of the prototypes behind our bespoke SaaS argument: when software is designed around what agents can do and shaped to one team's thresholds, the console above is what an ops tool becomes. The workspace, the thresholds, and the demo transcript here are illustrative. The design argument is the real deliverable: agents should have a channel to their humans, and the humans should hold the helm.

A useful test on Monday: take last week's overnight exceptions and sort them into "safe and reversible" versus "public or irreversible." The first pile is what an agent should be doing for you already. The second is where a person and an agent-in-the-loop belong—and it's a lot shorter than the pile you're clearing today.