Build around a clear agreement
The Agentic Agreements Protocol, or AAP, gives developers a way to connect exact terms, approvals and evidence around a task. An agreement can move beyond its original conversation or application while retaining the information needed for supported checks.
A useful integration starts with one question your application needs to answer: which proposal did the parties accept, may this agent perform this action, or what happened to an earlier request? These are related questions, but each needs its own evidence and authority.
Where an integration can help
| Role | What it contributes |
|---|---|
| Agreement interface | Helps people review terms, compare revisions and approve the exact version in the relevant role |
| Agent or service integration | Connects a task to an agreement and checks the owner's permission before the selected action |
| Delivery or payment connector | Talks to an actual service, retains the request's identity and supplies observations about its outcome |
| Evidence and review tool | Presents a file, observation or judgment with its origin and limits, so the agreed reviewer can assess it |
| Independent checking and preservation | Checks supported records and keeps the terms, evidence and trust information needed for later review |
The relationship between these parts matters. A valid signature authenticates particular data. Permission determines whether an actor may act. A payment observation answers a question about a payment. Combining their displays should preserve those distinctions.
Work with existing tools and payments
AAP can sit alongside an existing model, application, delivery service or payment provider. Basic portable agreements do not require a blockchain or a project token. A particular service can still have its own charges, credentials and custody requirements.
The available integration paths include local libraries and agent tool servers. MCP connects an AI application to tools; A2A supports exchanges between agents. A service can be configured to require acceptance of exact terms and current permission before carrying out a task. Its owner must choose the trusted identities, limits and executing service.
Commerce tools also connect selected checkout, payment-request, mandate and receipt formats to an agreement. The named formats include ACP, UCP, MPP, AP2 and x402. Support for a particular format does not establish compatibility with every provider that uses its name. A payment mandate, a submitted instruction and a confirmed payment remain separate records.
Capabilities to build on, with their boundaries
Current components support exact portable documents, owner review and signing, revisions, structured service agreements, evidence review and several dispute procedures. Other components support limited delegation, repeated services, privacy, offline carriage and an optional shared ledger. These are parts to select and connect, rather than one universal workflow.
The default agent interface offers a small entrance to a larger catalogue: start a task, find a capability, inspect its requirements and call the selected operation. Retrieve those requirements instead of inferring an interface from a short description.
Some agreement tools require the named parties' keys directly. A network permission cannot automatically substitute a representative's signature in every agreement format. Likewise, current service master agreements cover two parties; a wider organisational workflow needs explicit design and review.
A connector also needs an honest recovery model. If a reply disappears, investigate the original request before issuing a replacement. When the provider cannot establish what happened, preserve the uncertainty. A local log alone cannot guarantee that a physical action happens exactly once. Owner-selected tools retain the operating-system privileges granted to them; an agreement wrapper is not a general security sandbox.
A first useful small build
A proposed starting project is a viewer for one agreed job and its revision. Use a non-sensitive sample and keep delivery and payment outside the initial exercise.
Let two participants review the same terms and supply the required approvals. Export the agreement, reopen it in another process and show which exact terms and roles the supported checks cover. Then change the price or deliverable and request fresh approvals.
Keep both versions. The old signatures should still authenticate the old terms; they must not count as acceptance of the revision. A link to the earlier agreement does not reconstruct its missing contents, so retention is part of the exercise.
Finally, attach a sample delivery record and show what it establishes. A received file is not necessarily satisfactory work. The interface should make missing approval, missing evidence and a conflicting observation understandable to a person.
This creates a small, inspectable result. A next step could connect one owner-authorised service and test an interrupted request under that service's actual recovery rules. Each additional effect should have a clear owner and a measurable outcome.
Useful review and contribution opportunities
There is room for clearer agreement interfaces, narrowly scoped connectors, better explanations of evidence and stronger recovery exercises. Independent checking can test whether another implementation reaches the same result for an explicitly identified set of records. Testing should include changed content, wrong roles, stale information, missing dependencies and uncertain external outcomes where relevant.
Preservation and privacy also need practical review: can a recipient obtain the information it needs without unnecessary disclosure, and can an operator restore the records and signing history needed to continue correctly? Findings are most useful when they distinguish observed behaviour, expected behaviour and the assumptions required for the claim.
AAP remains a development preview. Existing tests and bounded independent checkers are useful evidence, while independent security review and qualification of the complete intended deployment remain outstanding.
Start a technical conversation
Describe the workflow, the systems you want to connect and the exact question the integration should answer. Identify who signs, who may execute an action, who holds any funds and what the outside service can report after a timeout.
Include the format or protocol you need to exchange, your intended runtime, representative non-sensitive inputs and the smallest result that would be useful. An integration discussion can then establish compatible rules, access, ownership and validation before expanding the scope.
Working reference implementation · Invited developer pilot · Implementation access is reviewed individually. Any trial, services or commercial terms require separate agreement.