Hiro: an ops triage console where the agent can reach its human

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, and when must it stop and ask a person? Hiro is the prototype we built in a design sprint to answer that question on one screen. To be plain about what it is: a design-sprint outcome you can open and click through, with demo data, and no software running for customers. The interesting part of what came out isn't the triage. It's the direction of the conversation: the agent gets a channel to reach its human. First we show the rule that decides when it may act, then the console where its questions land, then what the ratio buys.

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 at what you remember to ask. 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 still approve anything consequential before it happens. The difference is who initiates: the agent brings decisions to you, instead of you patrolling the software to find them. We wrote about why that matters in The Tideline: how much of the work you can hand to an agent depends on which stage of the work you're looking at, and calls like these sit in the stages that stay human.

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 does more than gate 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. The operator never opens a form.

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 instead of an act of faith. Even the actions the agent is cleared to take alone leave a card in the transcript. The design refuses silent autonomy, 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.

The operator becomes a supervisor

The break from the tools Hiro would replace is who does the work and who watches. The incumbent categories both point their channel at a person. An incident platform turns monitoring events into alerts and alerts into incidents, then notifies the on-call responder through an escalation policy until a human acknowledges and resolves [1]. A ticket system works at lower urgency but the same way: views collect the unsolved tickets into lists, routing assigns each one to an agent, and a person works the list item by item [2]. Both are built to deliver work to humans. Hiro assumes the software works the queue and the person supervises the result: the agent reads the inbox, the payments dashboard, and the issue tracker as one stream, clears what's safe, and brings up only the calls that need an owner, each arriving addressed with its evidence and a recommendation.

The operator's day stops being “get through the pile” and becomes “answer the five things the software couldn't decide alone.” That is a supervisor's job, and it is why the center pane stays empty until the agent has something to say. It is also why the surface gives the supervisor the two things a dashboard never did: a way for the work to reach them, so a decision made at 3am comes to you instead of waiting silently in a tool you aren't looking at, and a way to check the agent's work without redoing it, through the plan that discloses intent, the card left on every autonomous step, and the one rose color that says who acted.

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 value is in how those five arrive: as decisions, each with its evidence, its history, and a recommendation, so the judgment part of the job gets your full attention. 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, this console is what an ops tool becomes. The workspace, the thresholds, and the demo transcript here are illustrative. The design argument is the deliverable: agents should have a channel to their humans, and consequential decisions should keep a human owner.

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 belongs, and it is a lot shorter than the pile you're clearing today.

The channel itself is where we plan to take this next. 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.