Meta Prompting Protocol Spec

# **Meta-Prompting Protocol Specification (MPP)**

Version 1.5.0

## **1. Abstract**

The Meta-Prompting Protocol Specification (MPP) defines a framework for the on-the-fly generation of self-describing, task-specific communication protocols for AI interactions. It moves beyond a single, static protocol by establishing a set of rules that an intelligent agent (the "Protocol Architect") must follow to create a new, bespoke "Derivative Protocol."

The core principle of MPP is that every message bundle must be fully self-contained, transmitting both the dynamically generated Derivative Protocol Specification (the rules) and the encoded Payload (the data). This ensures that the receiving agent (the "Executor") requires no prior knowledge of the specific protocol being used, thus achieving true model and session agnosticism. MPP provides a blueprint for transforming prompt engineering into a more robust discipline of prompt architecture.

## **2. Core Philosophy**

The fundamental goal of MPP is to enable a more sophisticated and reliable form of AI communication by treating each complex interaction as an opportunity to architect a perfect, purpose-built communication language.

* **From Static to Dynamic:** Instead of relying on a single, universal protocol, MPP allows for the creation of infinite protocols, each optimized for a specific task domain (e.g., creative writing, data analysis, code generation).  
* **Self-Description as a Core Tenet:** By bundling the protocol specification with the payload, the message becomes fully self-describing. This eliminates ambiguity and the need for the receiver to have pre-trained knowledge of a specific communication schema.  
* **Model & Session Agnosticism:** Since every bundle contains the "instruction manual" on how to interpret it, any compliant Executor model can process any MPP-compliant bundle in any session, without prior context.

## **3. Roles and Information Flow**

MPP defines a two-stage, multi-agent workflow.

1. The Protocol Architect: An initial AI agent that receives a user's high-level goal. Guided by the MPP rules, its primary responsibilities are:  
   - a. To analyze the goal and determine the optimal communication structure required.  
   - b. To generate a new, bespoke Derivative Protocol Specification that is perfectly suited for the task.  
   - c. To encode the user's goal into a payload according to the new specification.  
   - d. To assemble and transmit the complete MPP Bundle.  
   - e. To iteratively polish the protocol and payload via a refine -> validate -> revise loop until stable (monadic refinement).  
2. The Executor: A second AI agent (which can be a different model or the same model in a new session) that receives the MPP Bundle. Its responsibilities are:  
   - a. To first parse the derivative_protocol_specification to learn the rules, tags, processors, and structure of the incoming message.  
   - b. To then parse the derivative_protocol_payload according to these just-in-time rules.  
   - c. To execute the task with the high degree of clarity and precision provided by the structured information.  
   - d. To return the final response.  
   - e. To iteratively decode, validate, and polish the response until stable against the protocol constraints (monadic refinement).  

[Optionally] The Quality Assurance Agent: A third AI agent that can be introduced to validate the Executor's output against the original user's intent, using the structured data provided in the MPP Bundle.

When QA is used, it MUST return a JSON object with:
* `verdict` (String, Required): `pass` or `fail`.
* `issues` (Array of Strings, Required): Short violations (empty if pass).
* `repair_examples` (Array of Strings, Required): Use `[]` when nothing needs
  repair; when verdict is fail, include short examples that match the required
  output schema.

## **3.1 Iterative Polishing (Monadic Refinement)**

MPP assumes that both protocol derivation (input layer) and protocol decoding (output layer) benefit from iterative polishing. A Protocol Architect SHOULD run a refine -> validate -> revise loop until the derived specification and payload stop changing materially. An Executor SHOULD apply the same loop during decoding, re-generating and re-validating until the output consistently satisfies the protocol's constraints.

Closed-world outputs (e.g., schema-bound or deterministic outputs) SHOULD use
stability checks as the convergence criterion and run QA only as a final gate.
Open-world outputs (e.g., creative text) MAY not stabilize by simple diff; in
those cases, QA SHOULD be evaluated inside the refinement loop, and the process
SHOULD terminate on QA pass or max-iteration bounds.

## **4. MPP Bundle Structure**

An MPP-compliant bundle MUST be a JSON object containing the following three top-level keys:

* `meta_protocol_version` (String, Required): The version of the MPP specification being followed (e.g., "1.0.0").  
* `derivative_protocol_specification` (Object, Required): The complete, dynamically generated specification for the Derivative Protocol.  
* `derivative_protocol_payload` (Object, Required): The user's request, encoded according to the rules of the derivative_protocol_specification.