Intent and Constraint Evolution Protocol (ICEP) is an open coordination-plane protocol that defines how multiple agents evolve a shared world-state through intents, constraints, evidence, simulation, and arbitration.
ICEP addresses a fundamental problem in multi-agent systems:
When many agents act in parallel, coordination must be state-based and constraint-driven, not conversation-driven.
Agent systems can now propose changes faster than humans can coordinate them. Traditional workflows rely on tickets, branches, and reviews to serialize work. That model breaks down when:
- Multiple agents operate on the same system at the same time
- Intent conflicts are discovered too late
- Communication replaces verifiable coordination
ICEP replaces conversation-centric coordination with explicit state evolution.
ICEP is:
- A protocol, not a product
- A coordination plane, not a workflow
- A world-state evolution model, not a messaging format
ICEP defines:
- How agents declare intents
- How constraints are applied and verified
- How simulations produce evidence
- How an arbiter selects an accepted future
ICEP is not:
- An agent communication protocol
- A human authority or governance model
- A CI/CD replacement
- A consensus or voting system
- A productivity tool
For details, see non-goals.md.
ICEP introduces a small set of agent-native primitives:
- World-State Graph
- Intent Declaration
- Constraint / Invariant
- Evidence
- Simulation (Counterfactual)
- Parallel Futures
- Arbiter
- Accepted State
These terms are defined in terminology.md.
ICEP is built on the following principles:
- State before communication
- Constraints are system physics
- Parallel futures over serialized branches
- Verification over negotiation
- Deterministic arbitration
Any implementation that violates these principles is not ICEP-compliant.
ICEP defines a minimal set of protocol primitives:
- DECLARE (Intent)
- CONSTRAIN (Invariant binding)
- EVIDENCE (Proof and simulation results)
- SIMULATE (Counterfactual evaluation)
- ARBITRATE (Conflict resolution)
- ACCEPT (Selected world-state transition)
ICEP-compliant systems MUST enforce a lifecycle similar to:
DRAFT -> DECLARED -> SIMULATED -> EVALUATED -> ACCEPTED | REJECTED
ICEP ends at ACCEPTED. Materialization of changes is out of scope and is typically governed by an authority protocol such as AAP.
ICEP and AAP are complementary:
- AAP governs who is allowed to authorize transitions
- ICEP governs how transitions are evaluated and selected
ICEP assumes intent legitimacy is enforced by an authority protocol such as AAP.
See the AAP specification in ../AAP (canonical) or
https://github.com/tokligence/AAP.
ICEP is an open protocol.
- This repository hosts the specification
- Tokligence acts as the initial steward
- Protocol changes are proposed via RFCs
ICEP intentionally separates specification from implementation.
Reference implementations MAY be hosted in separate repositories.
Early reference tooling is available at:
- RFC-0001: Intent and Constraint Evolution Protocol (ICEP)
- RFC-0002: Intent Declaration
- RFC-0003: Constraints and Evidence
- RFC-0004: Arbitration and Conflict Resolution
- RFC-0005: Event Log
- RFC-0006: HTTP+JSON Transport Profile
Canonical JSON schemas live in schemas/:
schemas/common.jsonschemas/intent.jsonschemas/constraint.jsonschemas/world_state.jsonschemas/evidence.jsonschemas/arbitration.jsonschemas/event.json
Examples are in examples/.
Validate example payloads against the schemas:
python scripts/validate_examples.py
Requires the jsonschema package.
- Current Status: Draft
- Initial RFC: RFC-0001
- License: Apache 2.0
ICEP evolves through clarity, not velocity.
Before contributing:
- Read
terminology.md - Read
non-goals.md - Understand the constraint model
Contributions that dilute the evolution model will not be accepted.
ICEP does not attempt to make agents communicate better.
It ensures that as agent execution scales, shared systems evolve through constraints, evidence, and arbitration rather than conversation.