💡 Agent Workload Health Monitoring & Escalation SLA Standard

[github-actions[bot]]

Summary

The org runs multiple autonomous agents (dev-lead, compliance-audit, canary-rollout, auto-rebase, feature-ideation) that can silently get stuck — 111 dev-lead issues were stuck from concurrency group cancellations (#402), and multiple issues carry the needs-human label awaiting manual intervention. This proposal creates a standard for agent workload health monitoring with completion rate SLAs, stuck-task detection, and automated escalation when agents cannot complete work.

Market Signal

The agentic CI/CD space is maturing rapidly. GitHub Agentic Workflows (GA 2026) includes built-in guardrails and audit logging via gh aw logs and gh aw audit. The OWASP Top 10 for Agentic Applications (ASI01-ASI10, published Dec 2025) identifies cascading failures (ASI08) and rogue agents (ASI10) as top risks — both manifest as silent workload stalls in practice. Anthropic now offers device verification for remote Claude Code sessions. The industry trend is clear: agent governance must include operational health monitoring, not just security controls.

User Signal

• Issue dev-lead: issue-pickup runs cancelled by concurrency group → 111 labeled issues stuck with no PR #402: dev-lead: issue-pickup runs cancelled by concurrency group → 111 labeled issues stuck with no PR — this accumulated silently
• Multiple issues carry the dev-lead:needs-human label (SonarCloud: GitHub Actions / dependency hardening (×13) #598, Compliance audit — 2026-07-03 #589) indicating agent failure
• Canary blockers (Canary blocker: add-to-project ring0->ring1 (cum_fail=27, PRE_EXISTING) #701, Canary blocker: ci-failure-analyst next->ring0 (cum_fail=0, -) #732) persist as open issues — the canary engine detects failures but agent workload health does not
• Fleet monitor health-check issues ([Fleet Monitor] petry-projects/.github — .github/workflows/sonarcloud.yml #758, [Fleet Monitor] petry-projects/.github — .github/workflows/dependency-hardening-tests.yml #759, [Fleet Monitor] petry-projects/.github — .github/workflows/canary-rollout-tests.yml #760) show workflow health degradation across multiple workflows
• The org has fleet monitoring for workflows but no equivalent monitoring for agent task queues

Technical Opportunity

The org already has fleet-tracker labels and health-check issues for workflow monitoring. The canary engine emits structured decision telemetry (#683). The compliance-audit runs on a schedule. Extending the fleet-monitor pattern to track agent task completion rate, queue depth, and escalation latency is architecturally consistent. The daily Org Status issue (#751) could include an "Agent Health" section with per-persona metrics.

Assessment

Dimension	Score	Rationale
Feasibility	med	Extends existing fleet-monitor pattern; requires new label queries per persona
Impact	high	Prevents silent agent failure accumulation (111+ stuck issues in #402)
Urgency	med	Pattern is recurring — needs-human issues and canary blockers accumulate weekly

Adversarial Review

Strongest objection: This is operational monitoring, not a feature. Agent issues get stuck because of bugs in the agents themselves (like the concurrency group issue #402) — monitoring won't fix the root causes.

Rebuttal: Monitoring is the prerequisite to fixing. The 111 stuck issues in #402 persisted because no one noticed the pattern until it accumulated. Detection latency directly determines blast radius. This standard doesn't replace bug fixes — it ensures bugs are caught in hours, not weeks. The canary engine demonstrates this principle: decision telemetry (#683) caught promotion failures that would have gone unnoticed without observability.

Suggested Next Step

Define agent health metrics (task completion rate, median time-to-close, needs-human escalation count, stuck-task age threshold) in a standards document. Extend the daily Org Status workflow to include an "Agent Health" section that queries issue labels and age for each agent persona (dev-lead, compliance-audit, canary-rollout).