Inter-Agent Communication Contract Prompt

This prompt is for system architects and platform engineers who need to define a formal, machine-readable contract between two AI agents before any code is written. The job is to produce a specification that eliminates ambiguity in inter-agent communication by explicitly declaring input/output types, preconditions, postconditions, error responses, and conformance criteria. Use this when you are integrating two specialized agents—such as a research agent and a synthesis agent, or a code-generation agent and a review agent—and the cost of a parsing failure or silent data loss is high. The ideal user has already scoped each agent's role and knows the handoff points, but needs a rigorous boundary definition to prevent integration drift.

Do not use this prompt for simple, single-agent workflows where structured output alone is sufficient. It is overkill when the two agents share a memory space, are tightly coupled in the same execution context, or when the communication payload is trivial (e.g., a single boolean flag). This prompt is also not a substitute for a shared schema definition—it assumes you will reference or embed one. If you are still prototyping agent roles and haven't settled on responsibilities, start with the Agent Role and Specialization Prompts pillar first. The contract produced here is a design artifact, not a runtime enforcement mechanism; you will need separate validation prompts and middleware to enforce it in production.

Before using this prompt, gather the following context: the names and responsibilities of both agents, the direction of communication, the expected payload schema (or a reference to one), the preconditions that must be true before the message is sent, the postconditions that must be true after it is processed, and a catalog of known failure modes. The prompt will produce a contract document with sections for each of these, plus eval criteria you can use to test whether an agent's output conforms. After generating the contract, your next step is to implement the Agent-to-Agent Message Validation Prompt Template to enforce it at runtime, and to version the contract alongside your agent code. Avoid the temptation to make the contract overly generic—precision about one specific interaction boundary is more valuable than a vague template that covers every possible handoff.

This prompt template produces a formal communication contract between two agents. It defines the input/output types, preconditions that must hold before invocation, postconditions guaranteed after successful execution, and structured error responses for every failure mode. Use this when you need a machine-readable contract that can be validated in code, not just a handshake agreement. The template is designed to be adapted for any agent pair—replace the placeholders with your specific agent roles, message schemas, and operational constraints.

textCopy
You are a system architect defining a formal communication contract between two agents in a multi-agent system.

Generate a complete inter-agent communication contract using the following structure. Every field is required unless marked optional.

## Agent Roles
- **Caller Agent**: [CALLER_AGENT_NAME] — [CALLER_AGENT_DESCRIPTION]
- **Callee Agent**: [CALLEE_AGENT_NAME] — [CALLEE_AGENT_DESCRIPTION]

## Message Schema
Define the request and response payloads using the following JSON Schema format:

### Request Schema
```json
[REQUEST_SCHEMA]

Response Schema

jsonCopy
[RESPONSE_SCHEMA]

Preconditions

List every condition that must be true before the callee agent can process the request. For each precondition, specify:

• Condition: [PRECONDITION_DESCRIPTION]
• Validation: How the callee agent verifies this condition
• Failure Response: The error code and message returned if the precondition is not met

Postconditions

List every condition guaranteed to be true after a successful response. For each postcondition, specify:

• Condition: [POSTCONDITION_DESCRIPTION]
• Verification: How the caller agent can confirm this condition holds

Error Responses

Define every possible error the callee agent can return. Use this structure for each error:

• Error Code: [ERROR_CODE]
• HTTP Status Analog: [STATUS_CODE]
• Condition: When this error is triggered
• Response Body: Exact JSON structure of the error payload
• Retryable: Yes/No with conditions
• Escalation Path: What the caller agent should do if retries are exhausted

Contract Metadata

• Contract Version: [VERSION]
• Deprecation Policy: [DEPRECATION_RULES]
• Schema Evolution Rules: [EVOLUTION_RULES]
• SLA Tier: [SLA_TIER]
• Timeout: [TIMEOUT_MS]ms
• Idempotency: [IDEMPOTENCY_REQUIREMENTS]

Constraints

• [CONSTRAINT_1]
• [CONSTRAINT_2]
• [CONSTRAINT_3]

Output Format

Return the contract as a single JSON object with the following top-level keys: contract_version, agents, message_schemas, preconditions, postconditions, error_responses, metadata, constraints.

To adapt this template, replace each square-bracket placeholder with concrete values from your agent architecture. The [REQUEST_SCHEMA] and [RESPONSE_SCHEMA] placeholders should contain valid JSON Schema definitions—include field types, required fields, enum constraints, and example payloads. For preconditions, be exhaustive: missing a precondition means the contract silently permits invalid invocations. For error responses, map every failure mode you've observed in integration testing plus every precondition violation. The contract metadata section is critical for production systems—versioning and deprecation rules prevent silent breakage when agents evolve independently. After generating the contract, validate it by running the conformance eval criteria in the Evaluation and Testing section against both agents in a sandbox environment before deployment.

This prompt is designed to be called programmatically as part of a system architect's design workflow or an automated CI/CD pipeline for agent registries. The primary integration point is an API call to a capable LLM (such as GPT-4o or Claude 3.5 Sonnet) where the prompt template is populated with the agent specifications for two interacting agents. The output is a structured JSON contract, which means your application must treat this as a code-generation task with strict post-processing. Do not treat the raw model output as the final artifact; it is a draft that must pass a validation gateway before being committed to a schema registry or agent configuration store.

The implementation harness should follow a validate-on-output pattern. After receiving the model's JSON response, immediately parse it with a JSON schema validator that checks for the required top-level keys: contract_metadata, agent_a_spec, agent_b_spec, message_schemas, error_responses, and contract_conformance_tests. If parsing fails, use a retry loop with a maximum of 2 additional attempts, appending the parse error to the [CONSTRAINTS] field in the retry prompt. For high-risk production systems, log every generated contract to an audit table with the model version, input hashes, and validation status. This creates a traceable record for debugging communication failures between agents later. When integrating with agent frameworks, map the message_schemas directly into Pydantic or Zod validators to enforce the contract at runtime, not just at design time.

Avoid wiring this prompt directly into a live agent handoff path without human approval. The generated contract is a design artifact, not a runtime decision. After validation passes, route the contract to a review queue where a platform engineer confirms the preconditions, postconditions, and error codes align with the actual agent capabilities. Only after approval should the contract be published to the agent registry. A common failure mode is treating the model's first successful JSON parse as correct; always run the embedded contract_conformance_tests against a sandboxed agent pair before production deployment to catch semantic errors that valid JSON hides.