External Service Dependency Health Prompt

Platform operators and SRE teams run this prompt before dispatching an agent plan that depends on multiple external services. The job-to-be-done is risk mitigation: a single unhealthy dependency can corrupt a multi-step execution, leaving the system in an unrecoverable intermediate state. This prompt consumes structured health probe data—collected by your existing monitoring infrastructure—and produces a dependency health matrix that includes per-service status, SLA compliance flags, cascading failure risk assessment, and degraded-mode recommendations. The ideal user is an agent orchestrator or workflow engine that needs a programmatic go/no-go signal before committing to a plan that touches more than two external dependencies.

Use this prompt when the agent plan has a fan-out dependency graph where failure in one service could invalidate work already performed by others. For example, a plan that reads from a customer database, enriches data via a third-party API, writes to a billing system, and sends a notification requires all four services to be healthy. If the billing system is degraded, the prompt should recommend either aborting the plan or proceeding in a read-only mode that skips the write step. The prompt is not a replacement for your monitoring stack—it is a reasoning and synthesis layer that interprets pre-collected probe results, identifies transitive risks, and recommends execution modes. You must supply structured probe data as input; the prompt does not perform live health checks.

Do not use this prompt for real-time health monitoring or alerting. It is designed for pre-flight validation, not continuous observation. If your probe data is stale by more than the SLA window of your fastest-changing dependency, the matrix output will be unreliable. Also avoid this prompt for single-dependency plans where a simple binary health check suffices—the synthesis overhead adds latency without benefit. Before integrating this prompt into your harness, ensure you have a mechanism to collect and refresh probe data on demand, and that your eval suite includes checks for stale input detection, cascading failure false negatives, and partial-degradation misclassification.

This prompt is designed to be pasted directly into your agent harness or orchestration layer before executing a multi-step plan that depends on third-party services. It instructs the model to produce a structured health matrix covering each dependency's status, SLA compliance, and degraded-mode recommendations. The output is intended to be machine-readable so your harness can programmatically decide whether to proceed, pause, or route to a fallback path.

textCopy
You are a dependency health auditor for an autonomous agent system. Your job is to produce a unified readiness view of all external services that a planned agent execution depends on.

## INPUT
- Planned agent steps: [PLAN_STEPS]
- Dependency catalog with current status data: [DEPENDENCY_CATALOG]
- SLA thresholds: [SLA_THRESHOLDS]
- Recent incident log (last [INCIDENT_WINDOW_HOURS] hours): [INCIDENT_LOG]

## OUTPUT_SCHEMA
Return a valid JSON object with this structure:
{
  "overall_readiness": "GO" | "DEGRADED" | "NO_GO",
  "generated_at": "ISO-8601 timestamp",
  "dependencies": [
    {
      "service_name": "string",
      "dependency_type": "API" | "DATABASE" | "AUTH" | "FILE_STORE" | "SECRETS" | "OTHER",
      "status": "HEALTHY" | "DEGRADED" | "DOWN" | "UNKNOWN",
      "latency_p95_ms": number | null,
      "error_rate_5m": number | null,
      "sla_compliant": true | false,
      "sla_breach_detail": "string | null",
      "certificate_expiry_days": number | null,
      "rate_limit_remaining": number | null,
      "affected_steps": ["step_id"],
      "degraded_mode_recommendation": "PROCEED" | "RETRY_WITH_BACKOFF" | "SKIP_STEP" | "USE_FALLBACK" | "ABORT_PLAN",
      "evidence": ["string"]
    }
  ],
  "cascading_failure_risk": "LOW" | "MEDIUM" | "HIGH",
  "cascading_failure_detail": "string",
  "recommended_action": "PROCEED" | "PROCEED_WITH_CAUTION" | "DELAY" | "ABORT",
  "human_review_required": true | false,
  "human_review_reason": "string | null"
}

## CONSTRAINTS
- If any dependency status is UNKNOWN, set overall_readiness to DEGRADED and flag for human review.
- If two or more dependencies serving the same step are DOWN, set cascading_failure_risk to HIGH.
- If certificate_expiry_days is less than [CERT_EXPIRY_WARNING_DAYS], mark sla_compliant as false.
- If rate_limit_remaining is below [RATE_LIMIT_BUFFER_PERCENT]% of the total quota, recommend USE_FALLBACK.
- Do not fabricate latency, error rate, or certificate data. Use null when data is unavailable.
- Cite specific evidence from the incident log or dependency catalog for every non-HEALTHY status.
- If overall_readiness is NO_GO, human_review_required must be true.

## RISK_LEVEL
[HIGH | MEDIUM | LOW]

If RISK_LEVEL is HIGH, require explicit human approval before returning a GO recommendation. Flag any dependency where degraded_mode_recommendation is ABORT_PLAN for immediate escalation.

To adapt this template, replace each square-bracket placeholder with live data from your infrastructure monitoring, incident management, and service catalog systems. The DEPENDENCY_CATALOG should include real-time health metrics, not stale configuration data. The PLAN_STEPS input should be the exact step list your agent planner generated, including step IDs that map to the affected_steps field. Before deploying, validate that your harness can parse the JSON output and act on the recommended_action field programmatically. For high-risk workflows, always route human_review_required: true responses to an on-call queue before proceeding.

The External Service Dependency Health Prompt is designed to run as a pre-flight gate before any agent plan that depends on third-party services. In a production harness, this prompt should execute after the agent has produced a plan but before it begins executing steps that call external APIs. The harness is responsible for extracting the list of required services from the plan, injecting them into the prompt's [DEPENDENCY_LIST] placeholder, and then evaluating the structured output to decide whether to proceed, degrade, or abort. This is not a one-shot check—it should be re-run whenever the plan is revised or when a service call fails mid-execution, as dependency health can change between steps.

Validation and retry logic must be layered around this prompt. The output schema should be strictly validated: every service in the input list must appear in the output matrix, each status must be one of healthy, degraded, or unhealthy, and SLA compliance fields must be parseable booleans or timestamps. If validation fails, retry once with the same input and a stronger constraint instruction appended (e.g., 'You must include every service from the input list in your output matrix'). If the second attempt also fails validation, the harness should log the malformed response and treat all unvalidated services as unhealthy to avoid silent proceed-on-bad-data failures. For high-risk production environments, add a human review step when any service reports unhealthy and the agent plan would still attempt a call—this prevents the model from making overly optimistic degradation recommendations.

Model choice and tool integration matter here. This prompt benefits from models with strong structured output support (GPT-4o, Claude 3.5 Sonnet) and should use the provider's native JSON mode or structured output API rather than relying on text parsing. The harness should also connect this prompt to real monitoring data where available: if you have a live status endpoint or internal health dashboard, inject that data into [CONTEXT] as ground truth rather than asking the model to hallucinate service status. For services behind circuit breakers, the harness should read breaker state directly and merge it with the model's assessment, giving precedence to the live signal. Logging must capture the full prompt input, output, validation result, and the go/no-go decision for every execution—this trace is essential for debugging cascading failures where a dependency was marked healthy but later failed.

What to avoid: Do not run this prompt once at startup and cache the result for the entire agent session. Dependency health is time-sensitive; a service that was healthy five minutes ago may be degraded now. Do not let the model invent status for services it has no information about—if [CONTEXT] is empty for a given service, the harness should treat that as a signal to either perform a live probe or mark the service as unknown and escalate. Finally, do not use this prompt as a substitute for actual health checks and circuit breakers in your infrastructure. The prompt is a reasoning and aggregation layer that helps the agent make informed decisions; the harness must still enforce timeouts, retries, and fallback logic at the transport level.