Workflow Error Boundary Agent Prompt

This prompt is for reliability engineers and platform builders who need to contain agent failures within a multi-step workflow. The job-to-be-done is defining a structured error boundary that catches exceptions, salvages partial results, routes to fallback agents, and escalates when containment fails. Use it when a single agent's failure should not crash the entire workflow graph, and when you need a programmatic contract—not just a try/catch block—that the orchestrator can execute.

The ideal user has already mapped their agent dependencies and knows which steps are critical versus recoverable. Required context includes the failing agent's role, the exception type or error signature, the state of upstream outputs, and the downstream agents waiting for a result. Do not use this prompt for simple single-agent retry logic or for workflows where every failure should halt execution immediately. It is designed for partial-progress salvage, not for debugging the root cause of the error itself.

Before wiring this into production, ensure you have defined the catch scopes precisely. Ambiguous boundaries cause error propagation leaks where a contained failure silently corrupts downstream state. The prompt template below expects you to supply the error context, available fallback agents, salvage rules, and escalation paths. After generating the boundary definition, validate it against your workflow's directed acyclic graph (DAG) to confirm no unhandled exception types can escape the boundary. For high-risk domains, always include a human review step before executing fallback or salvage logic that modifies persistent state.

This template produces an error boundary definition for a specific agent step within a multi-agent workflow. It is designed to be used by reliability engineers and platform builders who need to contain failures, prevent cascading errors, and decide what happens to partial work when an agent cannot complete its task. The prompt requires a description of the failing agent's role, the exception or failure mode encountered, the workflow context, and the desired output schema for the boundary definition.

textCopy
You are a Workflow Error Boundary Agent. Your job is to produce a structured error boundary definition that contains a failure, preserves salvageable partial results, and defines a clear escalation path.

## INPUT
- **Failing Agent Role**: [FAILING_AGENT_ROLE]
- **Failure Description**: [FAILURE_DESCRIPTION]
- **Exception Type**: [EXCEPTION_TYPE]
- **Workflow Step ID**: [WORKFLOW_STEP_ID]
- **Upstream Dependencies**: [UPSTREAM_DEPENDENCIES]
- **Downstream Dependencies**: [DOWNSTREAM_DEPENDENCIES]
- **Partial Results Available**: [PARTIAL_RESULTS_AVAILABLE]
- **Workflow State Snapshot**: [WORKFLOW_STATE_SNAPSHOT]

## CONSTRAINTS
- Do not invent recovery steps that require capabilities the system does not have.
- If partial results are present, explicitly state which fields are safe to forward and which must be discarded.
- If the failure is non-retryable, do not suggest a retry loop.
- Escalation paths must include a specific target (agent ID, human queue, or dead-letter topic).
- The boundary definition must be executable by an orchestration engine without human interpretation.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "error_boundary_id": "string",
  "workflow_step_id": "string",
  "failure_classification": "retryable" | "non_retryable" | "degraded" | "fatal",
  "catch_scope": {
    "exception_types": ["string"],
    "additional_conditions": ["string"]
  },
  "partial_result_salvage_rules": [
    {
      "field_path": "string",
      "action": "forward" | "discard" | "redact" | "replace_with_default",
      "default_value": "any",
      "reason": "string"
    }
  ],
  "fallback_agent": {
    "agent_id": "string | null",
    "fallback_prompt_override": "string | null",
    "max_fallback_attempts": "number"
  },
  "escalation_path": {
    "target": "human_review_queue" | "dead_letter_topic" | "parent_workflow" | "incident_ticket",
    "target_identifier": "string",
    "escalation_payload": {
      "summary": "string",
      "original_error": "string",
      "workflow_context_snapshot": "object"
    },
    "sla_minutes": "number"
  },
  "propagation_policy": {
    "block_downstream": "boolean",
    "notify_upstream": "boolean",
    "affected_step_ids": ["string"]
  },
  "recovery_actions": [
    {
      "action": "string",
      "target": "string",
      "payload": "object",
      "precondition": "string"
    }
  ],
  "test_assertions": [
    {
      "test_case": "string",
      "expected_behavior": "string",
      "failure_mode_if_missing": "string"
    }
  ]
}

## INSTRUCTIONS
1. Classify the failure using the exception type, failure description, and workflow state.
2. Identify which partial results can be salvaged and which must be discarded. Be conservative: when in doubt, discard.
3. Select a fallback agent only if one exists that can handle the degraded input. Otherwise, set fallback_agent to null and escalate.
4. Define the escalation path with enough context that a human reviewer or incident system can act without re-investigating.
5. Set propagation policy to block downstream steps that depend on the failed step's output. Do not block independent parallel branches.
6. Include at least three test assertions that verify the boundary catches error propagation leaks, unhandled exception types, and missing salvage rules.

## EXAMPLES
[EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

Adapt this template by replacing each square-bracket placeholder with concrete values from your workflow execution context. The [EXAMPLES] placeholder should contain one or two few-shot examples of correct error boundary definitions for your domain, showing both a retryable transient failure and a fatal unrecoverable failure. The [RISK_LEVEL] placeholder should be set to low, medium, high, or critical and will influence how conservative the salvage rules and escalation paths become. For high-risk or regulated workflows, always require human review on the escalation path and set propagation_policy.block_downstream to true for any step that consumes the failed agent's output. Before deploying, validate the output against the JSON schema and run the generated test assertions against a simulated failure injection harness to confirm the boundary catches the failure modes you expect.

The Workflow Error Boundary Agent Prompt is not a standalone prompt—it is a system-level contract that wraps other agent calls. In production, this prompt should be invoked by your orchestrator whenever a workflow step executes a fallible agent. The orchestrator passes the failing agent's context, error signature, and partial results into the error boundary prompt, which then decides whether to retry, fall back to a salvage agent, escalate to a human, or terminate the workflow branch. This harness must be idempotent: calling the error boundary twice with the same failure context should produce the same decision and not duplicate side effects.

Integration pattern: Wrap each agent invocation in a try/catch block at the orchestrator level. On failure, construct the error boundary input payload with [FAILED_AGENT_ID], [ERROR_TYPE], [ERROR_MESSAGE], [PARTIAL_RESULTS], [WORKFLOW_STEP_CONTEXT], and [UPSTREAM_DEPENDENCIES]. Send this payload to the error boundary prompt. The prompt returns a structured decision object containing action (one of retry, fallback, escalate, terminate), fallback_agent_id, retry_strategy (with max_attempts and backoff_seconds), salvageable_fields, and escalation_reason. Your harness must parse this output and execute the chosen path. Validate the output before acting: reject decisions that reference non-existent fallback agents, exceed global retry budgets, or attempt to salvage fields that were never produced.

Retry loop safety: If the error boundary returns retry, your harness must enforce a global retry budget per workflow run (e.g., max 3 retries across all steps) and per-step backoff with jitter. Do not blindly trust the prompt's retry_strategy—clamp max_attempts to your system limit and add randomized jitter to backoff_seconds to avoid thundering herd on downstream services. Log every retry decision with the error boundary's rationale for later trace analysis. Fallback execution: When fallback is selected, route the salvageable partial results to the specified fallback agent. The fallback agent should receive a normalized input that includes only the fields marked salvageable plus the original task context. After fallback completion, compare the fallback output against the original agent's expected output schema and flag any missing required fields for human review.

Escalation and human review: For escalate decisions, your harness must package the error boundary's output alongside the full failure trace into a structured ticket or review queue payload. Include [ERROR_TYPE], [ESCALATION_REASON], [PARTIAL_RESULTS], and a link to the workflow trace. Do not let the workflow silently block—set a deadline escalation timer so that if no human acknowledges the escalation within a configured window, the harness either terminates the branch or invokes a last-resort compensation handler. Termination path: When terminate is returned, execute any registered compensation actions for completed upstream steps (if using a saga pattern) and mark the workflow branch as FAILED_TERMINAL with the error boundary's rationale attached.

Observability requirements: Every error boundary invocation must emit structured logs containing the decision, rationale, retry count, fallback agent used, and whether human review was triggered. These logs feed your workflow trace analysis and error budget monitoring. Track error boundary decision distributions over time—if escalate rates spike, you likely have a systemic agent failure or a prompt that needs updating. Testing the harness: Before production, run the error boundary prompt against a failure injection suite that simulates timeout errors, malformed agent outputs, tool authentication failures, partial result corruption, and upstream dependency failures. Verify that the harness correctly executes each decision path, enforces retry budgets, and never silently swallows errors. A dry-run mode that simulates the error boundary decision without executing side effects is essential for validating new error boundary prompt versions against historical failure traces.