Protocol overview

How PC2 works

PC2 connects agreements between agents to the actions they execute. Its reference design combines a formal contract, proof checking for governed actions, and rules for delegation and completion.

The travel example below follows an agreement between distinct principals through execution, delegation and settlement. The scientific programme then explains how the proposed guarantees and practical costs will be assessed.

A PC2 interaction

The narrated animation follows a contract from agreement through tool use to completion and payment. The sections below explain the mechanism and extend the interaction to multi-principal delegation.

From agreement to completion1:50 · Narrated protocol illustration

Proof Carrying Contracts

Verifiable commitments for the economy of AI agents.

The animation illustrates the protocol design. The planned demonstration will provide a separate executable example.

01 · Agreement

Establishing the contract

A principal is the person or organisation an agent represents. Consider a traveller's agent commissioning a provider's agent to arrange a trip. The traveller specifies a budget and rules for disclosing documents. The provider agrees what it will deliver and what evidence establishes completion.

The parties express the agreement as a formal contract. It describes the relevant resources and their initial state, the constraints that must remain satisfied, and the goal that defines completion. A paid interaction also specifies its payment arrangement and the conditions for expiry or refund.

The traveller agent and provider agent contribute to one shared contract defining the task, resources, constraints and completion conditions. Both principals approve the contract and its execution environment.
One contract approved by both parties

The participating agents work towards a common specification of the task and its constraints. The principals approve the contract and the execution environment that will enforce it.

Contract assistants can draft candidate terms, explain them in ordinary language and generate examples that reveal ambiguity or unintended permissions. These steps help the principals review what the formal contract actually permits before approving it. Enforcement applies to the signed terms; a mismatch with the intended requirement remains possible.

Conditions that require expert judgement

The parties can agree on an evaluation procedure for a condition that requires judgement, such as whether accommodation meets a stated rubric. Its verdict becomes an input to the formal reasoning. The reliability of that judgement remains a separate evaluation question; the proof checker establishes what follows from the supplied verdict and the contract.

02 · Execution

Checking actions before execution

The Airlock is the controlled execution environment in PC2's reference design. It maintains the contractual state and mediates the executing agent's access to the governed resources. Before signing, both principals check its remote attestation: evidence that it runs the agreed reference build.

For each proposed tool call, the system constructs the statement that must be proved under the contract and current state. The proof must establish that every outcome covered by the tool's declared model preserves the required constraints.

PC2's reference research uses Lean, a proof assistant that checks formal proofs against precise definitions and logical rules. Models and automated methods can construct candidate proofs; the checker validates the final argument independently of how it was generated.

Proof generation
Construct an argument using formal libraries, automated reasoning and learned methods.
Proof checking
Validate the submitted argument against the statement required for the proposed action.
An agent inside the Airlock proposes an action with a proof. The proof check inside the Airlock uses the contract, current state and declared tool model. Acceptance permits the governed tool call outside the Airlock. Without an accepted proof, no tool call executes. In either case, the check result returns to the agent through a feedback loop below the main flow. After execution, the recorded result updates the state used for the next check.
The proof check controls the tool call

The proposed action and its proof are checked using the contract, current state and declared tool effects. An accepted proof permits execution. The resulting state is then available for subsequent checks.

Without an accepted proof, the governed tool call does not execute. The agent can revise its plan, seek further evidence or stop. A failed attempt may reflect the limits or cost of proof search even when the proposed action satisfies the contract.

Each executed call updates the recorded state. For example, a new booking must be considered together with money already committed to the trip. The guarantee is relative to the signed contract and its trusted base: the proof checker and obligation compiler, the Airlock, tool models and implementations, and the attestation and payment infrastructure. Expert verdicts, when used, are also assumptions of the reasoning.

03 · Delegation

Preserving commitments through delegation

A provider may assign the visa part of a travel task to a sub-agent acting for another principal. The subcontract defines that subtask, the resources available to the sub-agent and the conditions under which it may act.

PC2 treats delegation as a governed action. Before creating a subcontract, the contractor must supply a proof that the proposed child contract, considered together with its outstanding delegations, preserves the parent contract's constraints and resource limits.

The provider proposes a subcontract with a proof. The proof check considers the parent contract and existing delegations together. Acceptance establishes an approved subcontract that assigns scoped authority to the sub-agent. The parent constraints remain in force.
A subtask remains governed by the parent agreement

The new subcontract is checked alongside existing delegations before authority is passed to the sub-agent. It must fit within the resources and restrictions already committed by the parent contract.

In the travel example, the visa service receives the authority and access assigned to its subtask. Documents governed by the contract remain in controlled custody and are accessed through the permitted interfaces. The parent agreement continues to constrain the overall task as work passes between agents.

The proposed composition guarantee applies within a contract tree. Aggregate obligations and interference across separate contract trees remain open research questions.

04 · Completion

Completion and settlement

Completion is governed by the contract, whether or not work has been delegated. The executing agent uses recorded actions, delegation certificates and any agreed expert verdicts to prove that the goal has been reached. Where payment is involved, settlement requires the corresponding checked proof. Expiry and refund conditions follow the contract and the selected payment mechanism.

Scientific programme

How the protocol will be tested

The project will release a formal protocol, a research reference implementation and PC2-Bench. Together, these instruments will establish which guarantees follow from the model, how faithfully the implementation enforces it, and whether the approach is useful on realistic tasks.

Formal guarantees and conformance

The formal development will prove preservation of contractual constraints, completion requirements for settlement, and preservation through delegation under explicit assumptions. A conformance suite will connect those assumptions to tests of the reference Airlock, including isolation, state custody, proof checking and logging.

Tool implementations will be checked against their formal models. The release will distinguish machine-checked theorems from implementation properties supported by testing and state the components that remain trusted.

Contract fidelity and proof cost

Candidate contracts will be assessed against scenario requirements and held-out examples of permitted and prohibited behaviour. These comparisons will measure omissions and unintended permissions, including failures involving agreed expert judgements.

For each proof obligation, the experiments will record whether it is solved by symbolic automation, requires an AI prover, or remains unresolved. Ablations will isolate the contributions of formalization and proof methods, with latency and cost reported by task, contract complexity and delegation depth.

Adversarial comparison with PC2-Bench

PC2-Bench will use persistent sandboxed services for procurement, booking, confidential document processing and delegated service chains. Benign and attacked variants will compare PC2 with undefended agents, prompt and monitor safeguards, and deterministic policy defences under matched tasks and comparable configuration effort.

Attacks will target counterparties, tool inputs, colluding delegates, expert judgements and settlement. Measurements will include prohibited actions, legitimate task completion, latency and cost. Held-out attack suites, external submissions and a contracted independent red team will provide complementary scrutiny; the Airlock team's own tests will be identified as self-evaluation.

The resulting feasibility map will report which requirements can be expressed, which proofs can be produced and which settings justify the cost. Failures and residual risks will be reported alongside successful cases. Evaluation runs throughout development and informs the scope of the contract language and tool library.

Paper and implementation

PC2 foundations paper

Proof-Carrying Contracts: Commitments AI Agents Cannot Break

The paper develops the mathematical model of contracts, execution and delegation, with proofs under stated assumptions.

The mechanization and code accompanying the PC2 paper are coming soon in the project repository. A demonstration will follow, with instructions for running an initial example and examining its contract and execution.

Demonstration · UpcomingGitHub repository
Implementation demonstration

An executable example of contracts, checked actions and delegation.

Upcoming
Mechanization and code

Mechanization and code accompanying the PC2 paper, with instructions for building and using them.

Explore the research positions