Agent Health Check Monitoring Prompt

This prompt is a programmatic pre-flight check for platform operators and SRE teams managing multi-agent systems. Its job is to produce a structured health assessment that an orchestrator can consume before routing work to a specific agent. You run this prompt when you need a machine-readable signal—availability status, degraded-capability flags, recent failure patterns, and a clear routing recommendation—to feed directly into a routing decision. The ideal user is an engineer wiring agent readiness checks into an orchestration loop, not someone building a dashboard for manual review.

To use this prompt effectively, you must provide recent agent execution logs, error counts, latency percentiles (p50, p95, p99), and a current capability declaration for the agent. The prompt assumes these inputs are available and reasonably fresh—stale data will produce misleading health signals. The output is a structured JSON block with fields like availability_status, degraded_capabilities, failure_pattern_summary, and routing_recommendation. You should validate this output against a schema before allowing the orchestrator to act on it. If the agent is marked degraded but the routing recommendation is route, flag the inconsistency for human review. This is a high-stakes decision point; a false-negative health signal can route critical work to a failing agent, while a false-positive can unnecessarily drain capacity from healthy agents.

Do not use this prompt for real-time sub-millisecond health checks. It is designed for pre-routing evaluation cycles measured in seconds, where the orchestrator can afford a model inference round-trip before committing to an agent. Do not use it as a replacement for metric-based threshold alerting or heartbeat monitoring—those belong in your observability stack. This prompt is the semantic layer that interprets raw telemetry into a routing decision, and it should be paired with deterministic circuit breakers that can override the model's recommendation if error rates exceed hard limits. If the agent's capability declaration changes frequently, ensure the prompt receives the latest version; stale capability data is a common failure mode that causes the model to recommend routing to an agent that no longer supports the required task.

This prompt template is designed to be integrated directly into your agent orchestration health-check harness. It evaluates the readiness of a target agent by analyzing its recent telemetry, failure patterns, and current resource state. The output is a structured health assessment that your routing layer can consume to decide whether to forward work, hold tasks in a queue, or trigger a fallback agent. Replace every square-bracket placeholder with live data from your monitoring system before each evaluation cycle. The prompt enforces a strict JSON output contract to ensure machine-readability in automated decision pipelines.

textCopy
You are an agent health evaluator for a multi-agent orchestration platform. Your job is to assess the readiness of a single agent before routing work to it. You must produce a structured health assessment based on the provided telemetry and failure data.

## Agent Identity
- Agent Name: [AGENT_NAME]
- Agent Role: [AGENT_ROLE]
- Agent Capabilities: [AGENT_CAPABILITIES]
- Current Uptime: [UPTIME_DURATION]

## Health Metrics
- Availability Status (last 5 minutes): [AVAILABILITY_STATUS]
- Average Response Latency (ms): [AVG_LATENCY_MS]
- Error Rate (last 15 minutes, percentage): [ERROR_RATE_PERCENT]
- Active Circuit Breaker State: [CIRCUIT_BREAKER_STATE]
- Pending Task Queue Depth: [QUEUE_DEPTH]

## Recent Failure Patterns
- Last 10 Failure Reasons (chronological): [FAILURE_REASONS_LIST]
- Failure Category Distribution (JSON): [FAILURE_CATEGORY_DISTRIBUTION]
- Time Since Last Successful Task Completion (seconds): [TIME_SINCE_LAST_SUCCESS]

## Degradation Flags
- Active Degradation Flags (list): [ACTIVE_DEGRADATION_FLAGS]
- Resource Pressure Indicators (CPU/Memory/Disk): [RESOURCE_PRESSURE]
- Dependency Health Status (JSON): [DEPENDENCY_HEALTH]

## Output Schema
Produce a JSON object with exactly this structure:
{
  "agent_name": "string",
  "evaluation_timestamp": "ISO 8601 UTC",
  "overall_readiness": "healthy|degraded|unavailable",
  "routing_recommendation": "route|hold|fallback|drain",
  "degraded_capabilities": ["capability_name"],
  "active_failure_patterns": [
    {
      "pattern": "string describing the recurring failure mode",
      "frequency": "count in evaluation window",
      "severity": "low|medium|high|critical"
    }
  ],
  "risk_assessment": {
    "immediate_failure_probability": "low|medium|high",
    "data_loss_risk": "low|medium|high",
    "cascading_failure_risk": "low|medium|high"
  },
  "recommended_cooldown_seconds": 0,
  "human_escalation_required": true,
  "escalation_reason": "string, required if human_escalation_required is true",
  "evidence_summary": "string summarizing the key signals that drove this assessment"
}

## Constraints
- If AVAILABILITY_STATUS is 'offline' or CIRCUIT_BREAKER_STATE is 'open', overall_readiness MUST be 'unavailable' and routing_recommendation MUST be 'fallback'.
- If ERROR_RATE_PERCENT exceeds 20% or QUEUE_DEPTH exceeds [QUEUE_DEPTH_THRESHOLD], overall_readiness MUST be at least 'degraded'.
- If any ACTIVE_DEGRADATION_FLAGS include 'data_corruption_risk' or 'tool_auth_failure', human_escalation_required MUST be true.
- Never fabricate evidence. If the provided data is insufficient to make a determination, set overall_readiness to 'degraded', routing_recommendation to 'hold', and state the missing data in evidence_summary.
- recommended_cooldown_seconds must be 0 if overall_readiness is 'healthy'.
- Do not include any text outside the JSON object.

To adapt this template for your environment, start by mapping your existing monitoring metrics to the placeholders. The [FAILURE_CATEGORY_DISTRIBUTION] and [DEPENDENCY_HEALTH] placeholders expect pre-formatted JSON strings—ensure your monitoring pipeline serializes these before injection. The [QUEUE_DEPTH_THRESHOLD] inside the Constraints section should be replaced with your organization's specific SLO threshold. If your agent platform does not support circuit breakers, replace [CIRCUIT_BREAKER_STATE] with a static value of 'not_implemented' and adjust the constraint logic accordingly. Test this prompt against historical outage data to verify that the routing_recommendation field correctly triggers fallback or drain actions before a user-facing incident occurs.

This prompt is not a one-off diagnostic tool; it is a scheduled component of an agent orchestration harness. It should run on a regular cadence—typically every 30 to 120 seconds—for each registered agent in the fleet. The output is a structured health record that feeds a live routing table, which the orchestrator queries before delegating work. The harness must treat the LLM's health assessment as a signal, not as ground truth, and should cross-reference it with objective metrics like heartbeat latency, tool-call success rate, and queue depth before updating the routing table.

To wire this into production, wrap the prompt in a function that accepts an agent_id and fetches the required [AGENT_METRICS] and [RECENT_FAILURE_LOG] from your observability stack (e.g., Prometheus, Datadog, or custom agent logs). The prompt's [OUTPUT_SCHEMA] must be enforced with a strict JSON schema validator. If the model's output fails validation, retry once with the validation error injected into the [CONSTRAINTS] field. After a second failure, mark the agent's health status as "unknown" and escalate to the on-call channel. The validated output is then merged into the routing table, where a separate circuit-breaker rule can override the LLM's recommendation based on hard thresholds (e.g., error rate > 20% forces "unavailable" regardless of the model's assessment).

Model choice matters here. Use a fast, low-cost model (e.g., GPT-4o-mini, Claude Haiku) because this prompt runs frequently and the reasoning task is narrow. Avoid models with high latency variance, as a slow health check is worse than a stale one. Log every health assessment with the model version, raw response, validation result, and final routing decision. This audit trail is critical for diagnosing cascading failures where a bad health signal caused the orchestrator to route work to a degraded agent. Never allow the LLM's health assessment to directly trigger agent restarts or infrastructure changes; always route such actions through a human-approved runbook or a pre-tested automation with a manual approval gate.