Multi-Agent Handoff Protocol Change Impact Prompt

Use this prompt when you are an agent-system architect or prompt engineer preparing to modify the system prompt, tool instructions, or handoff rules of a single agent within a multi-agent architecture. The job-to-be-done is a pre-deployment impact review: you have a concrete prompt diff (current vs. proposed), the agent's role definition, its handoff protocol specification, and a map of upstream and downstream agents. You need a structured report that identifies handoff integrity risks, information loss, task duplication, and coordination breakdowns before the change reaches staging. This is not a prompt for initial agent design or for debugging a broken agent in production; it is a gatekeeping step that belongs after the diff exists but before any deployment.

The required inputs are specific and non-negotiable. You must provide the current prompt text, the proposed prompt text, the agent's role definition (what it is responsible for and what it explicitly does not own), the handoff protocol specification (how it receives tasks, how it passes tasks, what information must be included in handoff summaries, and any confirmation or escalation rules), and a map of upstream agents (who hands work to this agent) and downstream agents (who receives work from this agent). Without all five inputs, the analysis will produce false negatives—missed risks that surface only after the change is live. If you lack a formal handoff protocol specification, stop and document one before using this prompt. The prompt assumes structured, explicit protocols; it cannot infer implicit conventions from agent behavior alone.

Do not use this prompt for trivial changes such as typo fixes, whitespace adjustments, or cosmetic rewording that does not alter behavioral constraints, tool access, or handoff rules. Do not use it when the agent operates in isolation with no handoffs to other agents. Do not use it as a substitute for end-to-end agent-chain regression tests; this prompt produces a risk analysis, not a passing test suite. After receiving the impact report, your next step is to decide whether the identified risks are acceptable, mitigate them in the prompt change, or proceed to staging with specific monitoring and rollback triggers. For high-risk changes—those affecting task delegation authority, handoff summary structure, or escalation criteria—require a human review of the impact report before the change proceeds.

This prompt template is designed for agent-system architects who need to evaluate the downstream impact of a proposed change to a single agent's prompt on the entire multi-agent handoff protocol. It instructs the model to act as a protocol integrity auditor, systematically analyzing how the modification affects task delegation, context summaries, and coordination with other agents. The output is a structured report that identifies information-loss risks, duplication risks, and breaking changes in the handoff contract.

textCopy
You are a multi-agent protocol integrity auditor. Your task is to analyze a proposed prompt change for one agent and assess its impact on the entire agent handoff ecosystem.

# INPUTS

[ORIGINAL_AGENT_PROMPT]

[PROPOSED_AGENT_PROMPT]

[AGENT_ROLE_AND_RESPONSIBILITIES]

[HANDOFF_PROTOCOL_SPECIFICATION]

[DOWNSTREAM_AGENT_DEFINITIONS]

# ANALYSIS INSTRUCTIONS

1. **Contract Diff:** Identify the exact semantic and structural differences between the original and proposed prompts. Focus on changes to the agent's task definition, output format, tool-use permissions, and escalation criteria.

2. **Handoff Summary Impact:** Analyze how the change will alter the content, structure, or completeness of the handoff summary this agent generates for downstream agents. Flag any critical information that will be omitted, added, or reformatted.

3. **Task Delegation Drift:** Determine if the change will cause the agent to delegate tasks differently—either by delegating tasks it previously handled, handling tasks it previously delegated, or changing the specificity of its delegation requests.

4. **Coordination Conflict Scan:** Check for new conflicts with other agents, including duplicated responsibilities, contradictory instructions, or race conditions in tool access.

5. **Information-Loss Risk:** For each downstream agent, list the specific data fields or context elements that may be lost, degraded, or made ambiguous by the change.

6. **Duplication Risk:** Identify any work that will now be performed redundantly by multiple agents due to the change.

# OUTPUT SCHEMA

Return a single JSON object with the following structure:

{
  "change_summary": "A one-sentence summary of the core modification.",
  "severity": "LOW | MEDIUM | HIGH | CRITICAL",
  "handoff_integrity_report": {
    "breaking_changes": [
      {
        "field": "Name of the changed output field or behavior",
        "downstream_agents_affected": ["agent_name"],
        "failure_mode": "Description of what will break or degrade",
        "mitigation": "Recommended fix before deployment"
      }
    ],
    "information_loss_risks": [
      {
        "lost_context": "Specific information no longer passed downstream",
        "affected_agent": "agent_name",
        "impact": "Consequence of the missing information"
      }
    ],
    "duplication_risks": [
      {
        "duplicated_task": "Task now performed by multiple agents",
        "conflicting_agents": ["agent_name", "agent_name"],
        "resolution": "Suggested arbitration or ownership rule"
      }
    ]
  },
  "regression_test_recommendations": [
    {
      "test_case": "Description of an end-to-end agent-chain test to run",
      "expected_behavior": "What should happen if the change is safe",
      "failure_signal": "What to look for that indicates a regression"
    }
  ],
  "rollback_trigger": "The specific production signal that should trigger an immediate rollback of this prompt change."
}

# CONSTRAINTS

- Do not speculate about agent behavior not grounded in the provided prompts and protocol specification.
- Flag any ambiguity in the handoff protocol that prevents a definitive assessment.
- If the severity is HIGH or CRITICAL, the first regression test recommendation must be a canary test suitable for a staged rollout.

To adapt this template, replace each square-bracket placeholder with the actual content from your system. The [HANDOFF_PROTOCOL_SPECIFICATION] should include the formal contract for how agents pass context, including required fields, expected formats, and handoff triggers. The [DOWNSTREAM_AGENT_DEFINITIONS] should list every agent that receives a handoff from the modified agent, along with their role descriptions and input expectations. For high-risk production systems, run this analysis in a staging environment first and require human review of any report with a severity of HIGH or CRITICAL before approving the prompt change for deployment.

This prompt is not a one-off analysis tool; it is a gate that should fire automatically whenever a handoff-relevant prompt or tool schema is modified in a multi-agent system. The implementation harness must capture the proposed change, run the impact analysis, and block the release pipeline if the generated report contains high-severity information-loss or duplication risks that lack explicit human acknowledgment. The harness should treat the prompt's structured output as a machine-readable artifact, not just a human-readable summary, so that downstream systems can enforce policy decisions programmatically.

Wire the prompt into your CI/CD or change-management pipeline by triggering it on any pull request that modifies files in a registered agent's prompt directory or tool definition registry. The harness should: (1) extract the diff of the changed prompt or handoff schema; (2) inject it into the [PROPOSED_CHANGE] placeholder along with the current agent's role definition in [AGENT_ROLE] and the full list of peer agent contracts in [DOWNSTREAM_AGENTS]; (3) call the model with response_format set to the strict JSON schema defined in the prompt template; (4) validate the output against that schema and reject malformed responses with a single retry; (5) parse the handoff_integrity_report and check the overall_risk_level field. If the risk level is high or critical, the harness must post the full report as a PR comment and request a mandatory human review before merge is allowed. For medium risk, the harness should flag the PR with a warning but allow override. Log every run, including the model version, prompt version, input diff, and output report, to an audit trail for post-incident traceability.

Do not rely solely on the model's risk classification. Add a lightweight eval step that checks for known failure modes: a report that claims zero impact when the diff shows a handoff instruction was removed, or a report that flags every downstream agent as affected without specific evidence. These evals can be simple rule-based checks or a second LLM judge call that scores the report's internal consistency. If the eval fails, escalate for human review regardless of the declared risk level. For production-critical agent systems, consider running this analysis against a canary environment where the changed agent interacts with simulated downstream agents before the change reaches real users.