Back accountable agent work.

We are inviting investors and strategic partners to help develop Agentic Agreements Protocol (AAP / Covenant): agreement infrastructure for people and organisations delegating work to AI agents.

Speak with the foundersBecome a design partner

The proposition is reusable agreement machinery across applications, with an MIT core and paid services that help organisations operate it reliably. Working reference software is available through reviewed access; market demand and production qualification still need to be established.

The problem

An assistant arranging a piece of work needs more than a supplier and a payment button. It must know what its owner authorised, which version the supplier accepted, what counts as delivery and what happens after an interruption or disagreement.

Those answers can be scattered across a conversation, a document, a provider account and a payment receipt. A replacement assistant may struggle to reconstruct the relationship. A lost reply can leave the buyer unsure whether a payment happened. A changed price may look like part of the old conversation even though nobody approved it.

AAP puts the relevant terms, approvals and events into a record that each party can retain and another compatible program can inspect. Its value would come from reducing the work and uncertainty involved in carrying agreements between systems.

What the protocol contributes

The protocol distinguishes accepting terms, granting permission, attempting an action and observing its result. That gives applications a common way to ask what has actually happened and what still needs approval.

It also preserves exact versions. A revised price needs the required fresh approval. Configured execution workflows retain the original request’s identity so they can investigate that attempt. A dispute procedure can be chosen before either party depends on it. Selected evidence can be shared without distributing the whole commercial record.

The basic agreement paths work without a blockchain or project token. Applications can choose their own signing arrangements, reviewers, payment services and custody. A shared ledger is an additional option when participants need one accepted account of scarce resources.

A proposed first adoption focus

A practical starting point is a small, clearly specified digital service: research, analysis or another deliverable that a buyer can review. The parties can begin with one request, compare proposals, agree the output and price, record delivery, and apply the chosen acceptance criteria.

A proposed pilot would start with familiar payment arrangements and a bounded scope. It would add automation only where the owner has approved the connection and its limits. An amendment, interrupted action or incomplete delivery would be part of the trial, because handling those cases is central to the proposition.

This focus could test whether AAP improves a complete working relationship without first requiring a public network or marketplace. Useful measures would include time spent clarifying terms, manual handoffs, unresolved states, recovery effort, willingness to repeat the workflow and willingness to pay for its operation. These are proposed measures, not reported results.

Open core and a services business

The selected commercial strategy keeps the core under the MIT licence. Organisations can use, modify and self-host it under those licence terms. Implementation access is currently reviewed individually; there is no public package-registry download. That leaves room for adoption through independent applications and operators.

Potential paid offerings include managed coordination and integration services, enterprise deployment and support, retained evidence and recovery services, and compatibility assessment. A customer would pay for an identified service with an explicit scope, price and operating responsibility. Assessment and official branding would require separate, clearly bounded terms; payment would not purchase a passing result.

There is no universal royalty or mandatory marketing badge for core use. The strategy also does not itself establish accepted customer contracts or a launched billing operation. The commercial question is whether operating these capabilities well solves a problem customers will pay to avoid managing themselves.

What could create value

If the approach succeeds, a reusable agreement format could reduce the cost of supporting another application or provider. Work invested in a permission check, delivery receipt or recovery procedure could serve several workflows. Customers could retain useful records when an application changes, making adoption easier to justify.

A services business could earn its place through reliable operation, useful integrations, clear controls and support. Repeated use could reveal which agreement patterns deserve simpler interfaces and stronger operational support. Contextual discovery and signed introductions might also help participants find suitable counterparties, subject to the trust choices each owner makes.

These are hypotheses to test. Open licensing permits competitors and forks. Portability gives customers an exit. Durable commercial value would therefore need to come from continued usefulness and execution, rather than exclusive possession of their agreement history.

Development stage and proposed milestones

Working components cover portable agreements, review and signing, limited delegation, service workflows, dispute procedures, privacy, offline exchange and connections to other software. Recorded tests include local journeys, interrupted operations and deliberately adverse inputs. Many demonstrations use synthetic parties and test balances; they are not evidence of independent customers or real payment activity.

A proposed next programme would have four gates:

  1. Demonstrate usefulness with real participants. Complete one bounded workflow, including a change or interruption, and record the effort and unresolved issues.
  2. Qualify that specific use. Obtain independent security review and exercise the actual signing, custody, payment connection, recovery and operating arrangements it requires.
  3. Show repeatable adoption. Reduce setup work, make responsibilities understandable, and establish whether participants want to use the workflow again.
  4. Validate a paid offer. Define service commitments, support costs, customer terms and pricing, then test whether the value supports a sustainable service.

A public production network, independent verification of the full ledger and broader testing with real operators remain outstanding. The proposed milestones should guide which capabilities to advance; they do not promise a launch date.

Risks that matter to the thesis

The first risk is demand: precise agreement records may be useful without being valuable enough to change behaviour or support a business. Pilots need to compare the experience with the participants' existing process.

Integration and trust are equally important. AAP cannot make an unreliable payment provider, dishonest reviewer or compromised owner host reliable merely by recording its statements. Automated checks have a defined scope, and physical or legal facts still require appropriate evidence and judgment.

There is also a focus risk. The project contains many capabilities, and a successful first product must make a small set of them easy to understand and operate. Commercial responsibilities, custody and governance need clear ownership. Independent review and controlled deployment should progress alongside usability, rather than being inferred from local tests.

Start a conversation

The useful investor conversation is about testing this adoption path, choosing milestones and building a sustainable business around an open protocol. Relevant experience may include enterprise software, open-source infrastructure, payments, agent applications or running services whose reliability matters to customers.

Include your investment focus, the problem you find most compelling, relevant operating experience and the evidence you would need to assess the next stage. Introductions to potential pilot participants or independent reviewers would also make the conversation more concrete.

Email the foundersExplore a pilotRead the complete guide