Copilot
The copilot is InfraSage's conversational agent: an SRE that investigates with your live telemetry and can queue operational actions. One rule sits underneath all of it. Nothing mutates production without a human approving it first.
It lives in two places. The dock is a full-height panel available on every console page; toggle it
with ⌘I (Ctrl+I), the launcher pill, or the top bar's Ask InfraSage. The workspace is
/copilot in the nav, a full-page view with the conversation rail for long investigations.
Expanding the dock lands you in the same conversation.
You watch it work
A turn streams as it runs. Tool calls appear the moment the agent makes them, with the name, arguments, and a running spinner, then resolve in place with the result and how long they took. Every row expands to the raw input and output, so the evidence chain behind an answer is right there and clickable.
Each completed turn carries its provenance: which model ran it, how many tools it used, token count, and cost.
It knows what you're looking at
Every message carries the ambient console context: the page you're on, the service or incident in view, and the active time range. Ask "why is this service slow?" from a service dashboard and the copilot resolves this service the way a colleague looking over your shoulder would. The composer shows what will be attached as small chips above the input. Context never widens access, because every tool call is re-checked against your tenant on the server.
It remembers the whole conversation
Recent turns replay verbatim, including what earlier tool calls actually returned, not just the prose conclusions. Older turns fold into a rolling summary maintained on the session, so a two-hour incident thread keeps its numbers, hypotheses, and decisions without unbounded prompt growth.
What it can do
Read tools auto-execute: the full RCA evidence toolset (metrics, logs, traces, anomaly scores, dependencies, SLO burn, past incidents), plus operator-surface tools for active alerts, recent incidents, the runbook catalog, and runbook execution history.
Anything that acts is human-gated:
| Tool | Gate |
|---|---|
queue_runbook | Lands in the Decision Queue as a pending action, the same gate as the console's trigger button. Nothing executes until an operator approves. |
update_incident_status | Approval card in the conversation before it runs. |
add_incident_note | Approval card in the conversation before it runs. |
The copilot is prompted to report queued work honestly, as "queued for approval" and never as
"done", and its actions are stamped copilot:<user> in the audit trail and incident timelines.
Cost-aware model routing
Casual questions run on the fast model. Investigation intent (investigate, root cause, why
did…) escalates to the deep model with a larger tool budget. Each turn shows the model that
actually served it. Routing is configured with BEDROCK_HAIKU_MODEL (see
Environment Variables); unset routes
everything through the primary model.
Per-turn budgets cap runaway loops, and per-tenant rate limits keep one conversation from starving the platform.
Tenant boundaries
You can use service names the way operators say them: checkout-service, not the tenant-qualified
id. The server qualifies bare names under the caller's tenant and refuses ids that point into
another tenant; the refusal goes back to the model, which then corrects itself. Incident tools
require every service in the incident to be visible to the caller.