Agent Role Failure Mode Analysis Prompt

This prompt is for reliability engineers, platform architects, and SRE teams who need to move beyond ad-hoc debugging and systematically identify how a specific agent role can fail in production. The job-to-be-done is producing a structured failure mode catalog—complete with severity ratings, blast radius estimates, and compensating controls—before those failures cause multi-agent coordination breakdowns. You should use this when you are designing a new agent role, auditing an existing one, or preparing for a failure injection testing campaign. The ideal user has access to the agent's role definition, capability boundary contract, tool access policy, and any existing incident reports.

Do not use this prompt when you need a real-time incident response playbook or a postmortem of a specific event. It is a proactive analysis tool, not a reactive one. It also assumes you already have a well-scoped agent role definition; if you are still drafting the role's purpose and boundaries, start with the Agent Role Definition Prompt Template or the Agent Capability Boundary Contract Prompt instead. The output is a planning artifact that feeds into test case generation and orchestration policy, not a runtime decision engine.

The prompt requires you to provide the agent's role contract, its declared capabilities and exclusions, its tool access manifest, and any known constraints or past incidents. The model will produce a table of failure modes, each with a severity score, detection mechanism, and suggested control. You should then review this output with domain experts, prioritize the high-severity items, and convert them into concrete failure injection tests using the scenarios the prompt generates. Never treat the model's severity ratings as final; validate them against your actual system's blast radius and business impact.

This template is designed to be copied directly into your prompt library or orchestration harness. It expects a structured agent role definition as input and produces a failure mode catalog with severity ratings, detection mechanisms, and compensating controls. The square-bracket placeholders let you swap in your own role contracts, risk thresholds, and output format requirements without rewriting the analysis logic.

textCopy
You are a reliability engineer analyzing an agent role for failure modes. Your task is to produce a structured failure mode catalog.

## AGENT ROLE DEFINITION
[ROLE_DEFINITION]

## CONTEXT
- System architecture: [SYSTEM_CONTEXT]
- Sibling agents and their responsibilities: [SIBLING_AGENTS]
- Tool access and capabilities: [TOOL_MANIFEST]
- Operational constraints: [CONSTRAINTS]

## INSTRUCTIONS
For the agent role described above, identify potential failure modes across these categories:
1. **Input failures**: malformed, missing, or adversarial inputs the agent might receive.
2. **Decision failures**: incorrect reasoning, ambiguity handling, or policy misinterpretation.
3. **Tool failures**: tool unavailability, malformed tool outputs, or tool misuse.
4. **Boundary failures**: the agent acting outside its scope, refusing valid requests, or failing to escalate.
5. **Interaction failures**: handoff corruption, context loss, or conflicting actions with sibling agents.
6. **Output failures**: malformed outputs, hallucinated claims, or missing required fields.

For each failure mode, provide:
- **Failure ID**: a short unique identifier (e.g., FM-ROLE-001).
- **Description**: what happens when this failure occurs.
- **Trigger conditions**: what causes this failure.
- **Blast radius**: what downstream systems, agents, or users are affected.
- **Severity**: CRITICAL, HIGH, MEDIUM, or LOW based on blast radius and recoverability.
- **Detection mechanism**: how this failure would be observed in logs, metrics, or outputs.
- **Compensating control**: what mitigation, fallback, or guardrail exists or should exist.
- **Failure injection test scenario**: a concrete test case that could trigger this failure in a controlled environment.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "agent_role": "string",
  "analysis_date": "string (ISO 8601)",
  "failure_modes": [
    {
      "failure_id": "string",
      "category": "input | decision | tool | boundary | interaction | output",
      "description": "string",
      "trigger_conditions": ["string"],
      "blast_radius": {
        "affected_systems": ["string"],
        "affected_agents": ["string"],
        "user_impact": "string"
      },
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "detection_mechanism": "string",
      "compensating_control": "string",
      "failure_injection_test": "string"
    }
  ],
  "coverage_gaps": ["string (areas not covered by current controls)"],
  "recommended_priorities": ["string (top actions to address first)"]
}

## CONSTRAINTS
- Do not invent failure modes that are impossible given the role definition and system context.
- If a category has no plausible failure modes, include an empty array for that category and note why in coverage_gaps.
- Severity ratings must be justified by blast radius, not speculation.
- Every failure injection test must be executable in a test environment without breaking production.
- If the role definition is incomplete or ambiguous, flag what is missing in coverage_gaps rather than guessing.

To adapt this template, replace each placeholder with your actual artifacts. [ROLE_DEFINITION] should be the full structured role contract from your agent registry. [SYSTEM_CONTEXT] should describe the multi-agent architecture, message bus, and shared state. [SIBLING_AGENTS] should list other agents with their responsibilities to detect interaction failures. [TOOL_MANIFEST] should include every tool the agent can call, its expected inputs and outputs, and its failure modes. [CONSTRAINTS] should capture rate limits, latency budgets, and security boundaries. If you are using this prompt inside an automated pipeline, wire the output JSON into a validation step that checks for duplicate failure IDs, missing severity justifications, and injection tests that reference unavailable test infrastructure.

Before shipping this prompt into a production reliability workflow, run it against at least three distinct agent roles and review the output for consistency. Common failure modes of this prompt itself include: producing vague detection mechanisms like "monitor logs" without specifying which logs or what patterns; assigning CRITICAL severity to low-impact failures because the blast radius description was too broad; and generating injection tests that require production access. Add a human review step for any failure mode rated CRITICAL or HIGH before accepting the catalog into your risk register.

This prompt is designed to run as a batch analysis job, not a real-time user-facing call. You feed it a complete agent role definition (identity, scope, tools, authority, stop conditions) and receive a structured failure mode catalog. The output is intended for human review by reliability engineers before any failure injection tests are designed or compensating controls are implemented. Because the analysis covers production risk, the harness must treat the model's output as a draft for expert review, not as an operational artifact.

Integration pattern: Wrap the prompt in a job that accepts a role definition JSON payload and returns a failure mode catalog. Validate the output against the expected schema before storing it. Key validation checks include: every failure mode must have a non-empty severity field from the allowed enum, every detection_mechanism must reference an observable signal, and every compensating_control must be actionable. Reject or flag records that contain placeholder text, circular reasoning (e.g., 'detect by noticing the failure'), or severity ratings inconsistent with the described blast radius. Log all validation failures for the engineering team to review.

Model choice and retries: Use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature low (0.0–0.2) to reduce variance in severity ratings and control descriptions. If the output fails schema validation, retry once with the validation errors appended to the prompt as [PREVIOUS_ERRORS]. If the second attempt also fails, flag the role definition for manual analysis rather than looping indefinitely. Human review gate: Before any failure injection test is executed based on this catalog, a reliability engineer must sign off on severity ratings, blast radius assessments, and compensating control adequacy. The model can miss domain-specific failure interactions that only an experienced operator would recognize.

Tool use and RAG considerations: This prompt does not require tool calls or retrieval during execution. However, you should store the validated failure mode catalog in a searchable registry (e.g., a vector database or structured incident repository) so that future role definitions can be compared against known failure patterns. When analyzing a new agent role, retrieve similar roles and their failure catalogs as [PRIOR_FAILURE_EXAMPLES] to ground the analysis in historical findings. This turns the prompt from a one-shot analysis into a cumulative reliability knowledge base.

What to avoid: Do not feed this prompt partial or draft role definitions. Incomplete scope descriptions produce vague failure modes that waste review time. Do not skip the human review gate for high-severity findings. Do not treat the model's severity ratings as final—they are a starting point for engineering judgment. Finally, do not run this prompt in a user-facing product flow; it belongs in a pre-deployment reliability review pipeline with clear ownership and sign-off.