Implementing the standards
This version: 2026-09-01
Status: Working draft.
Licence: CC BY 4.0 (text). Schemas, when published, under Apache 2.0.
Conventions: RFC 2119 keywords and addressed roles
Steward: Marrow (onmarrow.com), on behalf of the Agent Mediated Insurance (AMI) working group
Scope: A summary of what adoption involves for each of the three roles the standards address
This page is the short version, for someone deciding what adoption actually involves. It adds no requirements. Every requirement lives in the standard that owns it, and the links below point to it.
What a carrier does
- Map its products to the canonical schema for each line it wants to transact, once per line. Everything behind that boundary, including risk appetite and pricing logic, stays with the carrier: the standards define the interface, not the underwriting.
- Expose the operations the New Business flow needs: the eligibility pre-checks at Stage 2, quote at Stage 4, bind and payment at Stage 8, and the documents at Stage 9.
- Supply the material the line-of-business standard requires: the feature taxonomy for like-for-like comparison, the exclusions, warranties and signposts to be disclosed, the material-fact attestation set, and its own bind semantics.
- Declare the version it conforms to, and whether it restricts a product to Tier A (per-transaction human confirmation) rather than allowing Tier B delegated authority.
- Expose its underwriting outcome honestly enough for the agent to present it, including referral, rating, exclusion and decline.
What an agent does
- Declare the versions it conforms to, Core Patterns vN and Consent, Authority and Scopes vN, and the autonomy tier it operates at.
- Present a verifiable agent identity for every Class 2 and Class 3 action, and hold the specific scopes each action requires rather than a general grant.
- Follow the behavioural rules: ground every material fact, confirm what was inferred, hold the information-versus-advice boundary, disclose and acknowledge before bind, and hand over on the defined triggers.
- Log conformance: the interaction, the material fields marked enriched or attested, the disclosures and acknowledgements, the authority exercised, and any handover and its trigger.
- Where the surface supports layer-driven elicitation, use it for any interaction carrying a material fact or a required disclosure, rather than constructing the question set itself.
What the intermediation layer does
- Expose the canonical schemas to the agent and speak to carriers and data sources on its behalf, so the agent never talks to either directly.
- Perform enrichment and verification, protect and tokenise personal data before it reaches model context or logs, and validate against carrier appetite.
- Enforce the bind precondition invariant, refusing the bind when any condition fails, and refuse to exercise
bindwhile the disclosure gate is unsatisfied. - Record every grant, exercise, step-up confirmation, pre-authorisation and revocation in the audit ledger, with mandate references and the identity of the agent that acted.
- Provide the hosted confirmation surface where the consumer surface cannot carry an insurance bind or a premium payment in the conversation, and specify the required content of that confirmation.
What publishes with the next version
The machine-readable artefacts are not published yet. Planned for the next version, under the Apache License 2.0:
- The canonical JSON Schemas for each line's request and response.
- Tool definitions for the New Business operations, bound to MCP.
- The conformance-log format, so that a conformance claim can be evidenced in a common shape.
- The discovery document, at a well-known path, following the pattern the agentic-commerce protocols use.
Until they exist, an implementation conforms against the prose, and a conformance claim is a declaration an implementer makes about its own implementation. See each standard's "How to conform" section for what to declare and what a tester can assert.