Explore a pilot with Covenant

The Agentic Agreements Protocol, or AAP, helps people and their agents keep a clear record of what they agreed, who approved it, what happened and what should happen if something goes wrong. A useful pilot would test whether that record makes one real relationship easier to manage.

The starting point is a specific piece of work: a report commissioned, a service ordered repeatedly, a permission granted or a handoff between teams. The question is whether the parties can understand the agreement, carry it between their systems and recover when a reply, approval or delivery goes missing.

The pilot shapes and process below are proposals for discussion. Scope, responsibilities, access, costs and timing would need to be agreed before work begins.

Who might find a pilot useful

A pilot could suit a business experimenting with assistants that commission work, a service provider handling repeated customer instructions, a publisher defining permitted uses of content, or a team operating with unreliable connectivity. It would also suit an integration team that wants to make approvals and evidence clearer around an existing service.

The strongest starting points have identifiable parties, a recurring source of uncertainty and a person responsible for resolving it. Someone should be able to explain how the work happens today and where a misunderstanding, missing approval or interrupted request causes effort or loss.

Four possible starting points

Commission one small piece of work

A buyer and a research provider could agree a report with a fixed scope, price, deadline and review process. The pilot would follow an initial proposal, a requested change, fresh approval and delivery. A human reviewer could judge quality while the software checks the exact document and the approvals attached to it.

The first exercise could use sample reports and test balances, or record an agreement alongside an existing invoicing process. A later payment connection would need its own agreed custody and recovery arrangements. The useful question is whether both parties can reconstruct the same job after an interruption.

Manage repeated services

A customer and supplier could agree shared terms for recurring work, then approve each individual instruction with its own scope, price and deadline. This could fit translation, research or routine technical services.

The pilot would test whether each new job stays within the agreed limits, whether changes are visible and whether retrying an interrupted instruction creates a duplicate allocation. The current master-agreement path is bilateral. Local allocation records track a budget within their supported environment; separate copies do not enforce one shared cap by themselves. The pilot would make that operating boundary explicit.

Carry a content permission between systems

A publisher and a buyer could record permission to use identified material for a particular purpose. They could carry the signed terms into another application and check that the material, permitted use and required approvals remain the same.

This would test clarity and portability: can a recipient distinguish the current permission from an earlier proposal, and can a reviewer find the relevant restrictions? The publisher would still need to establish its rights to grant the permission. A licensing record does not prevent copying or establish ownership merely by containing a name.

Keep a field handoff intelligible

Two teams with intermittent connectivity could exchange an exact work record and acknowledge receiving it. The initial exercise could use files and deliberately interrupted connections before considering particular devices or radio equipment.

The pilot would distinguish receipt of the package, acceptance of the terms and completion of the work. It would also test what happens when a device has authentic but older information. Current permission and shared funds can require fresh evidence that an isolated device cannot obtain. An initial scope should focus on records and bounded handoffs, with those uncertainties visible.

A proposed pilot process

1. Choose one relationship and establish a baseline. Describe the existing process, the people involved and the specific problem to improve. Agree what would count as useful evidence of improvement.
2. Select the rules and responsibilities. Identify the exact agreement format, signers, permissions, evidence, review procedure and recovery owner. Choose who keeps the records and which systems may perform actions.
3. Rehearse with controlled inputs. Walk through approval, amendment, delivery and one interruption or disagreement. Check that missing evidence remains visible and that an old approval cannot authorise changed terms.
4. Consider a limited trial. Proceed only if the rehearsal supports it and the participants approve the actual operating arrangements. Any use of live services, sensitive information or funds needs an explicitly agreed scope.
5. Review the result together. Compare the outcome with the baseline. Decide whether to continue, change the design or stop. Record the limitations alongside the useful results.

What a partner would bring

A partner would bring a workflow owner, access to the people who perform and review the work, and representative examples that can be used appropriately. A technical contact would help explain the existing tools, authentication and records available after an interruption.

The partner would also need to identify who can approve participation, who controls any signing keys or funds, and who can pause the trial. Where a judgment matters, a named reviewer is more useful than an assumption that the software will decide it automatically. The first discussion should establish what the partner can contribute and what additional implementation or review would be needed.

What would be measured

Measures should be agreed before the trial and compared with the existing process.

Success, failure and stopping

Success would mean meeting the agreed checks and providing enough practical benefit to justify the extra work. A successful demonstration of signatures alone would not establish that a business process has improved.

A pilot should pause if an action exceeds its authority, a repeated request creates an unintended duplicate, confidential material reaches an unintended recipient, or nobody can establish the state of funds or an external action. The participants should agree who can stop the trial and how unresolved work will be handled.

Repeated misunderstandings, excessive manual repair or benefits smaller than the integration cost are useful reasons to redesign or end a pilot.

Readiness and an initial enquiry

AAP is a development preview with working components and recorded development tests. Those components need to be selected and connected for a particular use. Independent security qualification and production operating arrangements remain outstanding; local demonstrations do not establish a launched public network or experience with real customers and funds.

An initial enquiry can be brief. Please describe the relationship, the problem today, the parties and decision-maker, the systems involved, the information or funds at stake, and the result you would want to measure. Include any constraints on connectivity, retention or human approval, and whether you are exploring a local demonstration or a limited real-world trial.

Working reference implementation · Invited developer pilot · Implementation access is reviewed individually. Any trial, services or commercial terms require separate agreement.