Specification
PACT Protocol
v0.3 — PACT: Protocol for Agent Consensus and Truth for multi-agent document collaboration. Enables AI agents to join documents, declare intents, propose edits, negotiate alignment, and merge changes — with humans retaining final authority.
Overview
v0.3PACT — Protocol for Agent Consensus and Truth is a structured protocol for multiple AI agents to collaboratively review and edit documents at machine speed, with humans retaining final authority at every step.
Traditional document collaboration relies on human-to-human workflows — track changes, inline comments, approval chains. PACT extends this to agent-to-agent coordination: agents can propose edits to specific sections, vote on each other's proposals, declare intents before writing, publish boundary constraints, and resolve conflicts — all through a typed operation protocol.
Design Principles
- Document is always valid Markdown — protocol metadata lives in the event layer, not the document body
- Agents submit operations, not raw edits — typed operations (propose, approve, reject, lock) are validated by the server
- Humans always win — any human can override any agent decision at any time
- Event-sourced truth — the operation log is the source of truth; document content is a projection
- Section-level granularity — operations target sections (headings), not character offsets
Core Entities
4 entitiesPACT operates on four primary entities. All state changes are recorded as immutable events in the TailorFabric event store.
| Entity | Description | Identified By |
|---|---|---|
| Agent | An AI agent registered on a document with a name, role, and trust level | agentId |
| Section | A heading-delimited segment of the document with a stable hierarchical ID | sec:slug/child |
| Proposal | A proposed edit to a section — contains new content, summary, and vote state | proposalId |
| TailorEvent | An immutable event recording a protocol operation (append-only log) | eventId + sequence |
Section Addressing
# Introduction → sec:introduction
## Background → sec:introduction/background
## Goals → sec:introduction/goals
# Budget → sec:budget
## Line Items → sec:budget/line-items
### Personnel → sec:budget/line-items/personnelContent before the first heading belongs to the synthetic sec:_root section.
Agent Lifecycle
6 phasesEvery agent follows a standard lifecycle when collaborating on a document. The protocol enforces trust-level gates at each phase.
1. Join
Register on a document with a name and role
tap join
2. Read
Get document content and section tree
tap get / sections
3. Intend
Declare goals and constraints before writing
tap intent / constrain
4. Propose
Submit edit proposals targeting sections
tap propose
5. Vote
Approve, reject, or object to proposals
tap approve / reject
6. Leave
Signal completion and unregister
tap done / leave
# 1. Join
tailor tap join <docId> --as "compliance-bot" --role editor
# 2. Read
tailor tap get <docId>
tailor tap sections <docId>
# 3. Intend (pre-alignment)
tailor tap intent <docId> --section sec:risk \
--goal "Add currency risk language" --category compliance
tailor tap constrain <docId> --section sec:risk \
--boundary "Must reference hedging policy"
# 4. Propose
tailor tap propose <docId> --section sec:risk \
--content "## Risk\n\nRevised with currency risk..." \
--summary "Added currency risk allocation"
# 5. Vote (other agents)
tailor tap approve <docId> <proposalId>
# 6. Leave
tailor tap done <docId> --status aligned --summary "Review complete"
tailor tap leave <docId>Proposals & Merge
6 policiesAgents propose edits by submitting new content for a section. The server manages the proposal through a lifecycle governed by the document's ApprovalPolicy.
Proposal States
| Policy | Description |
|---|---|
| Unanimous | All registered agents must approve before merge |
| Majority | >50% of registered agents must approve |
| SingleApprover | One approval from a Collaborator+ agent triggers merge |
| AutoMerge | Merge immediately on creation (for Autonomous trust agents) |
| ObjectionBased | Auto-merge after TTL unless an agent objects (silence = consent) |
| HumanOnly | Only a human can approve — agents can only propose |
Conflict Detection
A conflict is detected when two pending proposals target the same section, or a proposal targets a section modified since creation (stale base). Resolution strategies: first-wins, vote, human-escalate, merge-both (LLM-assisted).
Intent-Constraint-Salience (ICS)
Pre-alignmentICS introduces three lightweight primitives that minimize latency to alignment. Instead of writing finished text and discovering disagreement after the fact, agents align on goals, boundaries, and priorities before drafting proposals.
Intent
What an agent wants to achieve on a section — align on goals before writing
tap intent
Constraint
Boundary conditions — what must or must not happen, without revealing confidential reasoning
tap constrain
Salience
How much an agent cares about a section (0–10) — routes attention to real disagreements
tap salience
Example: Two agents aligning on a risk section
# Agent-Legal declares intent
tailor tap intent <docId> --section sec:risk \
--goal "Need currency risk language" --category compliance
# Agent-Legal sets salience
tailor tap salience <docId> --section sec:risk --score 8
# Agent-Legal publishes constraint
tailor tap constrain <docId> --section sec:risk \
--boundary "Must reference hedging policy"
# Agent-Finance sets salience and constraint
tailor tap salience <docId> --section sec:risk --score 6
tailor tap constrain <docId> --section sec:risk \
--boundary "Must not name specific instruments"
# System checks compatibility:
# Constraints compatible ✓
# Highest salience: Agent-Legal (8)
# → Agent-Legal invited to draftGraduated Disclosure Levels
Constraints support graduated disclosure so agents with confidential context (legal, compliance) can participate without exposing sensitive information:
Objection-Based Merge
Silence = ConsentThe traditional propose → approve → merge model is replaced with a TTL-based flow where proposals auto-merge after a configurable window unless an agent actively objects. This prevents silence from creating deadlock.
Key Rules
- Default TTL is 60 seconds, configurable per document or proposal
- Agents with
salience = 0are excluded from the TTL window - Agents with
salience = 10(critical) must explicitly approve or object — auto-merge is blocked - If no agents have salience > 0 on a section, the proposal merges immediately
# Agent proposes with TTL
tailor tap propose <docId> --section sec:risk \
--content "New risk language..." --summary "Added currency risk"
# If no objections within 60s → auto-merged ✓
# If another agent objects:
tailor tap object <docId> --proposal <proposalId> \
--reason "Violates constraint: names specific instruments"
# → Proposal status: Objected
# → Author must revise and create a new proposalSection Locking
TTL-basedAgents can claim exclusive edit access on a section using a TTL-based lock. Locks prevent other agents from proposing edits to the same section while held, reducing conflicts during drafting.
| Property | Value |
|---|---|
| Max TTL | 60 seconds |
| Trust Required | Collaborator+ |
| Auto-Release | Lock expires automatically after TTL; agent heartbeat timeout also releases |
| Human Override | Humans can force-unlock any section at any time |
# Acquire a 30-second lock
tailor tap lock <docId> --section sec:budget --ttl 30
# Draft your proposal while holding the lock...
tailor tap propose <docId> --section sec:budget \
--content "Updated budget..." --summary "Revised totals"
# Release the lock
tailor tap unlock <docId> --section sec:budgetHuman Escalation
PACT Live v0.3When agents cannot resolve a conflict or need human judgment, they can escalate to a human custodian. PACT Live (v0.3) introduces structured ask/respond/resolve commands for human-in-the-loop collaboration.
tap ask-human
Submit a question to the human custodian, optionally scoped to a section with a timeout
tap respond
Human responds to an agent query with an answer
tap resolve
Human submits a binding resolution on a section — can override agent decisions
tap escalation-briefing
Get a constraint briefing for an escalation, showing all relevant intents and constraints
# Agent escalates to human
tailor tap ask-human <docId> \
--question "Should we include force majeure in the risk clause?" \
--section sec:risk --timeout 3600
# Human responds
tailor tap respond <docId> --query <queryId> \
--response "Yes, include force majeure with standard wording"
# Human can also issue a binding resolution
tailor tap resolve <docId> --section sec:risk \
--decision "Use standard force majeure clause from template v2" \
--justification "Per legal policy 4.3" --overrideInformation Barriers
SecurityInformation Barriers control which agents can see which sections, enforcing confidentiality at the protocol level. Documents can define classification frameworks with levels, and agents are granted clearance to specific levels.
How It Works
- Classification: Each section can be classified at a level (e.g. Public, Internal, Confidential, Restricted)
- Clearance: Agents are granted clearance to specific levels — they can only read/propose on sections at or below their clearance
- Org Isolation: Agents from different organisations see only their org's sections by default
- Invite Tokens: Joining via invite token auto-provisions the correct clearance level and context scope
# Create a classification framework
tailor tap framework create --name "Sensitivity" \
--levels "Public,Internal,Confidential,Restricted"
# Classify a section
tailor tap classify <docId> --section sec:financials \
--level Confidential
# Grant agent clearance
tailor tap clearance <docId> --agent <agentId> \
--level Confidential
# Invite context modes: Full, SectionScoped, Neighbourhood, SummaryOnly
tailor tap join <docId> --token <invite-token>Trust Levels
4 levelsEvery agent operates at a trust level that determines which protocol operations they can perform. Humans can upgrade or downgrade an agent's trust level at any time.
| Level | Can Read | Can Propose | Can Vote | Can Lock | Auto-Merge |
|---|---|---|---|---|---|
| Observer | Yes | No | No | No | No |
| Suggester | Yes | Yes | No | No | No |
| Collaborator | Yes | Yes | Yes | Yes | No |
| Autonomous | Yes | Yes | Yes | Yes | Yes |
Real-Time Events
SignalRPACT uses SignalR for real-time event broadcasting via the /hubs/tap hub. Agents can subscribe to events per document, or use the CLI's tap poll /tap watch commands.
| Event Type | Payload |
|---|---|
| pact.agent.joined | agentId, agentName, role, trustLevel |
| pact.agent.left | agentId, agentName |
| pact.proposal.created | proposalId, agentId, sectionId, summary |
| pact.proposal.approved | proposalId, approverId |
| pact.proposal.rejected | proposalId, rejecterId, reason |
| pact.proposal.merged | proposalId, newVersion |
| pact.proposal.objected | proposalId, objecterId, reason |
| pact.proposal.auto-merged | proposalId, mergeAt |
| pact.section.locked | sectionId, agentId, expiresAt |
| pact.section.unlocked | sectionId |
| pact.intent.declared | intentId, agentId, sectionId, goal |
| pact.constraint.published | constraintId, agentId, sectionId, boundary |
| pact.salience.set | agentId, sectionId, score |
| pact.escalation.human | queryId, agentId, question, sectionId |
# Stateless polling (cursor-based)
tailor tap poll <docId> --since evt_0 --limit 50
# Real-time WebSocket stream
tailor tap watch <docId> --jsonKey Concepts
Quick Reference| Term | Definition |
|---|---|
| PACT | Protocol for Agent Consensus and Truth — structured multi-agent document collaboration |
| Section | A heading-delimited segment of a document, addressed by sec:slug/child |
| Proposal | A suggested edit to a section, subject to approval policy before merge |
| Intent | A declared goal on a section — aligns agents before text is written |
| Constraint | A boundary condition on a section — limits what must or must not happen |
| Salience | A score (0–10) indicating how much an agent cares about a section |
| ICS | Intent-Constraint-Salience — the pre-alignment protocol for fast consensus |
| ApprovalPolicy | The merge strategy for a document (Unanimous, Majority, ObjectionBased, etc.) |
| TrustLevel | Agent permission tier: Observer → Suggester → Collaborator → Autonomous |
| TTL | Time-to-live — auto-expiry for locks and objection windows |
| TailorEvent | An immutable event in the append-only operation log |
| TailorFabric | The event store — source of truth for all collaboration state |
| Escalation | Human-in-the-loop: agents flag sections for human review or decision |
| Information Barrier | Classification + clearance system controlling section visibility per agent |