Developer reference, recorded 26 October 2026. For the short explanation, read Why Covenant. For current access, see what’s available.
Know what an agent agreed to, who authorised it and what remains owed.
Agentic Agreements Protocol (AAP), developed as Covenant, is an agreement and evidence layer for people and their agents. It is useful when obligations must survive a chat session, a model change, a supplier change or an interrupted request. Its practical contribution is the connection between exact terms, authority, delivery evidence, adopted payment observations and remaining duties.
Keep your tools; make the agreement inspectable.
Your chosen agent harness can coordinate conversation; MCP/A2A or another adopted interface can carry calls; a credential/execution service can control a particular effect. AAP supplies exact agreement records and the evidence/procedure links around that work. Each integration retains its own version, installation, trust and execution requirements.
This is a way to compose with existing infrastructure. It does not establish that every alternative lacks agreements, that any protocol depends on AAP, or that AAP is already superior in adoption, cost or security. An ordinary low-risk conversation may need less machinery; add the checks your actual consequence requires.
Five concrete design choices
- Exact assent across revisions. Selected profiles bind signatures to the adopted terms, context and role. A changed price or scope receives its own fingerprint and requires the approvals specified by the adopted profile. Old signatures cannot silently approve changed terms.
- The principal and the actual actor remain visible. An owner can delegate a scoped role without handing over its key. Representation carries the grant chain, role, context and time limits; current-authority assessment remains conditional on a separately adopted state source and clock.
- Records can leave their original application. Parties can carry terms, signatures, references and evidence to a declared verifier. Separate Python/Node readers exercise specific covered profiles; an unsupported profile must remain unsupported rather than be described as verified.
- Recovery preserves the original request. Adopted workflows retain exact identities and uncertainty rather than creating a new request after every lost reply. Tested local cases exercise restart, idempotent retry, partition/healing, disputes, partial awards and appeals under their declared assumptions.
- Complexity is optional and versioned. Start with one offer and acceptance. Add linked calloffs, milestones, guarantors, private disclosures, adopted proof mechanisms or ledger/courier carriers where needed. A new carrier or interface does not silently rewrite an old agreement's meaning.
These are implemented design choices with finite local evidence. They are not a guarantee of legal effect, real asset title, current global state, physical delivery or external payment.
Implementation status, with the evidence boundary attached
| Capability | Present evidence | What is still separate |
|---|---|---|
| Draft, negotiate, sign and reject changed terms | Runnable fixed synthetic examples and declared profile tests. The public browser demo uses its own existing printable-ASCII profile. | Actual owners, their exact scope and any real work/payment permissions. The browser exercise simulates both parties. |
| Delegated and multiparty agreement handoff | Owner-only CLI/SDK and portable approval/merge cases, including expiry, revoked grants and changed terms. | Adopted identity bindings, complete/current authority state and clock. Native GIVE is not automatically converted; child-party assent is not inferred. |
| Portable verification | Independent Python/Node common vectors and a separate represented-assent reader fragment. | The fragment is ASCII and dependency-free; it does not evaluate the legal grammar or provide full independent native replay. |
| Recovery and disputes | Actual local multi-process demo plus synthetic provider/owner tests for restart, partition/heal, receipts, partial awards and appeals. | Independent operators, real custody, externally appointed arbitrators and any court recognition or enforcement. |
| Privacy and proof composition | Declared encryption/disclosure profiles, proof envelopes and owner-adopted verifiers for supported statements. | Actual keys, recipients, witness/circuit/setup/verifier assumptions and deployment. A hash is not encryption; a signature is not external truth. |
| Intermittent carriers and optional ledger | Local courier/store-and-forward mechanisms and finite simulated/recovery checks. | Physical Bluetooth, radio, satellite/device operation and independently operated quorum/finality qualification. An isolated signature cannot guarantee exclusive spending. |
| New security work | Candidate / under review. Its exact profile, source, threat model and tests must accompany any release claim. | No new production-isolation, physical hardware, credential-protection, certification or independent-security guarantee is asserted by these pages. |
For invited reviewers, the recorded c89a212 qualification is a dated snapshot: 6,675 tests and 1,739 strict elements with declared Rust/TLA+ checks. The linked source and report require invited implementation access. Later licensing, UI and security work does not inherit that snapshot's claim automatically. Follow the actual release evidence and deployment acceptance.
Designed to keep useful meaning when technology changes
Small versioned records, explicit dependencies, independently checkable fingerprints and declared interpretation rules make migration inspectable. Owners can adopt a new connector or verification mechanism without pretending it was part of an earlier signature. The code still carries documented layering/dependency debt; this is a continuing engineering programme, not proof of indefinite survival.
Reusable procedures, saved exact templates and contextual discovery can help later participants start from useful work. Reuse creates a fresh proposal and requires explicit adoption. Popularity or reputation never supplies signing or execution authority. Real retention, network effects, savings and willingness to pay still require external measurement.
Commercial control with explicit interoperability rights
Covered project-controlled core distributions use restricted commercial licensing; earlier MIT grants, upstream licences and independently written implementations retain their own rights. Restricted source-available code is not OSI open source. A licence to our code is not an automatic royalty over every compatible record or protocol idea. The public docs and standalone browser example retain their separate MIT grants. Read the public licensing boundary; request the applicable licence and exact release/code scope with owner-reviewed implementation access.
Our commercial proposal funds a defined licence and support relationship. It does not automatically activate billing, require a token purchase or promise token appreciation. Proposed pricing and acquisition enquiries.