An AI assistant for incident triage with human approval.

Gather evidence. Propose a diagnosis. Ask before acting.

Example scenario: an application starts returning errors after a release. This proposed workflow helps an engineer investigate. The example is illustrative and has not been presented as a deployed client system.

An alert starts an investigation, not an automatic production change.

No approval means no consequential action. Missing or conflicting evidence returns the investigation to a person.

• Illustrative investigation: Alert: A service reports errors → Gather evidence: Read allowed logs and runbooks → Propose diagnosis: Cite evidence and uncertainty → Policy check: Check permissions and action risk → Human decision: Approve, reject, or investigate
• Incident signal: An alert or ticket identifies a service and a symptom to investigate. Alerts, Tickets
• Approved evidence: Model Context Protocol (MCP) exposes allowed tools; retrieval respects source permissions and freshness. Read tools, Logs, Runbooks
• Proposed diagnosis: The assistant connects evidence to a possible cause and identifies what it cannot establish. Citations, Uncertainty
• Action boundary: A diagnosis is separate from permission to change the system. Policy checks, Human approval
• Evaluation and trace: Record tool requests and decisions, then test evidence quality and action controls before wider use. Evaluation, Audit trace
• What can the assistant read or change? Access to incident evidence must not grant permission to modify production. Start with scoped read tools. Keep action tools separate and require policy checks and human approval for consequential actions. The initial assistant would investigate and propose. Execution authority would require a separate, tested operating decision.
• What if the evidence is missing or contradictory? A confident answer can still be wrong when logs are incomplete or a runbook is outdated. Check source permissions and freshness, cite supporting records, and surface missing evidence or conflicting signals. The assistant should ask for investigation or escalate to an engineer rather than present an unsupported cause as established. Test this behavior with incomplete-evidence scenarios.
• How would we know the assistant helps? A fast answer is not useful if it points engineers at the wrong cause. Compare assisted investigations with a baseline and evaluate evidence support, incorrect diagnoses, escalation, and blocked actions. Measure time to a supported diagnosis together with errors and cost. These are proposed evaluation criteria, not published client results.

Why the system matters more than the model.

The design engineers the system around the model: scoped access through MCP, grounding through retrieval with citations, bounds through a policy engine, proof through evaluation, and a human in the loop before any consequential action executes.

• Triage load: Turn signal overload into prioritized action. The agent reads across internal systems and proposes what matters, so engineers spend time on response instead of correlation.
• Safe access: Reach internal tools without manual handoff. MCP servers expose read tools and action tools through scoped, auditable interfaces instead of brittle one-off integrations.
• Governance: Make every step reviewable. Policy checks, evaluation gates, and tracing make the agent behavior measurable and auditable, so it can be trusted in a real environment.
• Correlate logs, metrics, and alerts into a single proposed picture of an incident.
• Separate read tools from action tools so observation can mature before execution authority is granted.
• Filter retrieved context by source permissions, freshness, and citations before it reaches the model.
• Route sensitive or high-impact actions through policy classification, risk scoring, and human approval.
• Gate releases with offline regression evals and score every production run with online evals and traces.

The system around the model: access, grounding, control, and review.

Internal systems are exposed to the agent through scoped MCP read and action tools. The agent plans, acts, and observes in a controlled loop, grounded by retrieval over trusted context with ACL filtering, freshness checks, and citations. A model gateway handles routing, prompts, caching, and budget. Every proposed action passes through policy and risk classification, every run is scored by evaluation, and every prompt, tool call, retrieved context, approval, and result lands in a trace ledger. Consequential actions route to a human before execution.

• Scoped access: MCP read and action tools are separated, scoped, and audited.
• Grounded reasoning: Retrieval applies ACL filtering, freshness checks, and citations before model use.
• Policy control: Input, output, and tool-use policy checks plus risk classification gate consequential actions.
• Evidence loop: Offline evals, online scoring, and traces gate releases and make behavior measurable.
• Access: The agent reaches internal systems through controlled interfaces. MCP read tools expose logs, metrics, alerts, tickets, and runbooks for observation. MCP action tools stay separate, scoped, audited, and unavailable until policy allows them. A credential and scope broker records identity, allowed tool scope, approval state, and trace identifiers.
• Control: Behavior is bounded and measured, not assumed. Retrieval filters context by source permissions, freshness, and relevance before the model sees it. A model gateway routes work by risk, cost, latency, and capability, with prompts and cache under control. The policy engine classifies intent, blocks unsafe outputs, and escalates sensitive tool use.
• Review: Humans stay in the loop where it matters. Offline eval suites gate release of new prompts, tools, retrieval changes, and model upgrades. Online evals score grounding, policy adherence, task outcome, latency, and cost on every run. Consequential actions require human approval before the action executor can call MCP action tools.

Start with investigation. Evaluate before allowing action.

The operating model is staged on purpose. The agent starts read-only, grounding and measurement come before action, and authority is granted only as evaluation confidence, policy coverage, trace completeness, and human approval workflows mature.

• Start read-only: The agent begins with read MCP tools only. It observes, correlates, and proposes, but cannot execute changes until its judgment has been validated.
• Ground before you generate: Retrieval, ACL filtering, source freshness, and citations are built first, so the agent reasons over trusted context rather than its own assumptions.
• Measure from day one: Offline evals, online scoring, and trace capture are part of the build, so quality, safety, and cost are visible rather than anecdotal.

Intended benefits and how we would evaluate them.

These are evaluation goals, not observed client outcomes. We would compare assisted and unassisted investigations, check whether evidence supports each diagnosis, and test that unapproved actions remain blocked.

• Time to a supported diagnosis: Compare the time engineers need to reach an evidence-supported diagnosis, with and without assistance. Include incorrect diagnoses and escalation time.
• Action controls under test: Test that denied tools, missing approval, and insufficient permissions prevent execution. Measure failures as well as successful policy blocks.
• Audit-ready AI operations: Every prompt, retrieved context, tool request, policy decision, approval, outcome, latency, and cost lands in the trace ledger for review and replay.
• Controlled path to automation: The operating model starts with observe and propose, then earns action capability through evaluation confidence, trace completeness, and approval workflow maturity.
• Predictable AI unit economics: Model routing, prompt versions, cache, rate limits, budgets, and run-level cost tracking keep each task measurable as usage grows.

Grounded. Governed. An agent that is safe to operate.

The trade-off is deliberate: engineering the system around the model takes work up front. It is what lets an agent reach internal systems, reuse a governed MCP integration layer, propose action, and still prove access control, grounding, policy enforcement, evaluation quality, human accountability, and auditability in a real environment.