New Business Standards
Version: 0.1 (Draft for Comment)
Status: Working Draft. The first interaction standard.
Steward: Marrow (onmarrow.com), on behalf of the Agent-to-Agent (A2A) working group
Scope: The canonical flow by which an AI agent discovers, quotes, compares, and binds a new regulated insurance policy
This standard makes the New Business flow explicit and conformance-testable. It is line-of-business-agnostic: a LoB standard supplies the schema, enrichment, and distinctive rule; this standard supplies the order of operations, the preconditions, and the prohibitions that turn them into a safe transaction. It builds on the A2A Core Patterns Standard (behaviour) and the A2A Consent, Authority and Scopes Standard (what the agent is permitted to do), and implements action risk Classes 0 through 2. Comments to standards@onmarrow.com.
Normative language. "Must" and "must not" denote conformance requirements; "should" denotes a strong recommendation.
1. Position and scope
New Business is the reference interaction: discover, quote, compare, and bind a new policy. Mid-term adjustment, renewal, claims, and cancellation are separate interaction standards that reuse the machinery defined here. This standard does not restate behavioural rules (see Core Patterns) or authority mechanics (see Consent, Authority and Scopes); it composes them into a sequence and states the invariants that make a bind valid.
The flow is ten stages. Stages 1 through 5 are Class 0 to 1 (no commitment). Stages 6 through 8 are Class 2 (contract and money) and are gated by the bind precondition invariant in Section 4. Stages 9 and 10 complete and record. Audit (Stage 10) runs throughout, not only at the end.
2. The flow at a glance
Coral = contract & money (class 2) · grey = complete & record
| Stage | Name | Class | Authority / scopes | LoB hook |
|---|---|---|---|---|
| 1 | Intent and framing | 0 | none | - |
| 2 | Need and eligibility | 0 to 1 | process:personal-data (light) | LoB eligibility pre-checks |
| 3 | Risk capture and enrichment | 1 | process:personal-data, enrich:<source>, screen:medical | LoB schema and enrichment hooks |
| 4 | Quote | 1 | quote | LoB canonical request and response |
| 5 | Comparison and presentation | 1 | quote | LoB feature taxonomy and distinctive rule |
| 6 | Disclosure and acknowledgement | 1 to 2 | acknowledge:disclosures (gate) | LoB exclusions, warranties, signposts |
| 7 | Confirmation and authority | 2 | authenticated identity, bind:limit, pay:limit | LoB material-fact attestation |
| 8 | Bind and payment | 2 | bind, pay via delegated token | LoB carrier bind semantics |
| 9 | Fulfilment | 1 | none | LoB documents |
| 10 | Audit | cross-cutting | n/a | LoB evidentiary emphasis |
3. Stage detail
Stage 1: Intent and framing
Purpose. Establish the customer's goal and the basis of the interaction.
Required. Declare the basis as information, not advice, unless an advise scope is held and the conversation is flagged advised. Establish the consent scope for what follows.
Prohibited. Proceeding to personal-data capture without process:personal-data consent.
Stage 2: Need and eligibility
Purpose. Identify the line and run cheap eligibility pre-checks before spending effort. Required. Apply the LoB eligibility pre-checks (residency, age, in-appetite). Surface a known knock-out plainly. Prohibited. Quoting where a known eligibility knock-out applies without saying so.
Stage 3: Risk capture and enrichment
Purpose. Assemble the canonical request.
Required. Apply the LoB schema; populate via enrichment keyed off the canonical identifiers, holding the relevant enrich:<source> consent per source and screen:medical for special-category screening; present enriched and inferred material facts for attestation (assume-infer-confirm, Core Patterns 2.2).
Prohibited. Treating an enriched value as warranted; pulling a sensitive source without its explicit consent; relying on an unconfirmed material fact.
Stage 4: Quote
Purpose. Obtain prices from carriers. Required. Call the carrier(s) via the rail using the LoB canonical request. Represent zero quotes honestly as no appetite (Core Patterns 2.6). Prohibited. Fabricating, estimating, or recomputing a premium (Core Patterns 2.1).
Stage 5: Comparison and presentation
Purpose. Help the customer choose. Required. Order on a stated, customer-relevant basis and disclose it; compare like-for-like using the LoB feature taxonomy; apply the LoB distinctive rule (for example the pet policy-type rule, the home rebuild-cost rule, the travel adequacy and signposting checks). Prohibited. Undisclosed preferencing; presenting structurally different products as equivalent without making the trade-off explicit (Core Patterns 2.5).
Stage 6: Disclosure and acknowledgement
Purpose. Ensure the customer is informed before commitment.
Required. Surface the LoB exclusions, warranties and conditions, price and any credit terms and APR, and any mandatory signpost, and obtain acknowledgement in-conversation. This satisfies the acknowledge:disclosures gate.
Prohibited. Deferring a material disclosure to a document the customer has not opened (Core Patterns 2.4).
Stage 7: Confirmation and authority
Purpose. Final attestation and the authority check.
Required. Re-present the material facts for final attestation; verify the agent holds authenticated identity and bind:limit and pay:limit scopes covering this premium. Under Tier A, obtain a fresh human-present confirmation (step-up); under Tier B, verify the action falls within a valid pre-authorised Intent mandate and its cap.
Prohibited. Binding outside the granted authority, the cap, or the declared tier.
Stage 8: Bind and payment
Purpose. Create the policy and take payment. Required. Bind via the carrier; take payment through a delegated payment token (ACP delegate-payment or a network Agentic Token), never a raw card; disclose the credit agreement and APR where monthly. Prohibited. Binding before the Section 4 invariant is satisfied; any unauthorised spend.
Stage 9: Fulfilment
Purpose. Complete the customer's understanding and record. Required. Deliver the documents and a plain-language summary of what is covered, what is excluded, and what happens next.
Stage 10: Audit
Purpose. Evidence. Required. Record every stage continuously per Core Patterns 2.10 and the Consent and Authority audit requirements: each enriched-versus-attested fact, every disclosure and acknowledgement, the authority and mandates exercised, and the outcome.
4. The bind precondition invariant
A bind (Stage 8) must not occur unless all of the following hold. This is the single most important conformance requirement in the standard, and a conformant rail enforces it by refusing the bind otherwise.
- Authenticated identity: the user is authenticated as entitled to bind (Consent and Authority Section 6.1).
- Authority held: a
bind:limitscope covers the premium and apay:limitscope or delegated payment token covers the payment. - Disclosures acknowledged: the
acknowledge:disclosuresgate is satisfied for this specific quote (Stage 6). - Material facts attested: every material fact in the LoB schema has been attested, not merely enriched (Core Patterns 2.2).
- Distinctive rule satisfied: the LoB distinctive rule and any adequacy check have been applied and any warning surfaced (for example a home underinsurance gap, a travel cover-limit shortfall).
- Tier condition met: Tier A has a fresh human-present confirmation for this transaction; Tier B has a valid, in-cap, unexpired pre-authorisation.
If any condition fails, the agent must not bind and must either resolve the gap or hand over (Core Patterns 2.9).
5. Where the mandates are created
For surfaces that support agentic-commerce mandates, the flow creates them at defined points: a Tier B pre-authorisation (AP2 Intent mandate) exists before Stage 1; the specific quote selected at Stage 7 becomes the Cart mandate; the payment at Stage 8 is the Payment mandate, executed via delegated payment. The rail records the mandate references in the audit trail (Stage 10). Where a surface does not support mandates, the equivalent authority and confirmation are captured by the rail directly, and the invariant in Section 4 is unchanged.
6. Conformance checklist
A conformant New Business implementation satisfies, and a tester can assert, each of the following:
- Information-versus-advice basis is declared at Stage 1.
- No sensitive enrichment source is queried without its explicit per-source consent.
- No premium, exclusion, or eligibility fact is presented without carrier or source provenance.
- Comparison ordering basis is disclosed and the LoB distinctive rule is applied at Stage 5.
- The
acknowledge:disclosuresgate is recorded before any bind. - The Section 4 invariant is enforced at Stage 8, with the bind refused if any condition fails.
- The declared autonomy tier governs whether step-up or a pre-authorisation is used.
- The full flow is recorded with the enriched-versus-attested distinction and the mandates or authority exercised.
7. How a LoB standard plugs in
A LoB standard supplies: the eligibility pre-checks (Stage 2), the canonical schema and enrichment hooks (Stage 3), the canonical request and response (Stage 4), the feature taxonomy and distinctive rule (Stage 5), the exclusions, warranties, and signposts (Stage 6), the material-fact attestation set (Stage 7), the carrier bind semantics (Stage 8), the documents (Stage 9), and the evidentiary emphasis (Stage 10). The New Business flow is otherwise identical across lines. That separation is what lets a new line reach production by writing a schema and a distinctive rule, not a new transaction flow.
8. Open questions for comment
- How partial saves and resumption work when a flow spans multiple sessions, and how consent and authority persist across them.
- Whether Stage 5 comparison may span carriers in a single flow (parallel quoting) in the first conformance version, or is deferred.
- How the cooling-off cancellation right is surfaced at Stage 9 as part of fulfilment.
- The minimum content of the Stage 7 step-up confirmation, standardised across surfaces.
- Handling of a quote that expires between Stage 5 and Stage 8.
Published as an open standard. Marrow stewards the drafting but does not assert proprietary control over the interface; the compliance, enrichment, and audit implementations behind it are separate. Carriers, agent platforms, and regulators are invited to adopt, critique, and co-author future versions.