Core Patterns
Version: 0.1 (Draft for Comment)
Status: Working Draft. Foundational; referenced by all line-of-business and interaction standards.
Steward: Marrow (onmarrow.com), on behalf of the AMI working group
Scope: The behavioural rules an AI agent must follow when interacting with regulated insurance, independent of product line and interaction type
This standard is the shared spine of the AMI Standards. Each line-of-business standard (Motor, Home, SMB, Travel) references this document and adds their canonical schema and distinctive rules. The interaction standards (New Business, MTA, Renewal, Claims) build on these patterns. Consent and authority, although cross-cutting, are large enough to be their own standard and are referenced here rather than defined (Section 5). Comments to standards@onmarrow.com.
Normative language. "Must" and "must not" denote requirements for conformance. "Should" denotes a strong recommendation. An agent or carrier conforms to this standard by version (for example, Core Patterns v0.1).
1. Why this standard exists, and where it sits
One motivation for proposing the AMI standards on top of the existing A2A and AP2 protocols is that the risks of agent-mediated insurance are not addressed simply by establishing an agent's authority to act. It matters how an agent conducts itself in carrying those actions out. This standard defines how an agent should conduct itself when interacting with insurance products: grounding every fact in an authoritative source, confirming inferred facts before they are relied on, holding the boundary between information and advice, disclosing and acknowledging material terms, presenting options fairly, handling absence and error honestly, protecting personal data, and recording all of it in an auditable trail.
This standard is foundational. It sits alongside the Consent, Authority and Scopes Standard, which governs what an agent is permitted to do and on whose authority, while this standard governs how it behaves in doing it. The line-of-business standards build on both, drawing on this one for their behavioural rules, handover, and audit.
strip PII · filter
enforce · audit
2. Roles and terms (canonical)
These definitions are shared by every AMI standard.
- Customer - the person (or, in commercial lines, the business and the individual attesting for it) the agent acts for.
- Agent - the autonomous AI system acting on the customer's behalf.
- Surface - the platform the agent runs on (an assistant such as ChatGPT or Claude, or an embedded partner experience).
- Rail - the regulated intermediation layer (for example Marrow) that exposes the canonical schemas, performs enrichment and verification, strips and protects PII, validates against carrier appetite, blocks non-conformant responses, enforces these patterns, and writes the audit ledger. The agent talks to the rail, never directly to the carrier or the underlying data sources.
- Carrier - the regulated risk-carrier or its underwriting engine, mapped once to the canonical schema.
- Material fact - a fact that affects eligibility, pricing, cover, or a regulatory duty. Material facts carry the strongest requirements below.
3. The core patterns
3.1 Grounding, provenance and no fabrication
Every fact an agent presents (a premium, a cover term, an exclusion, an eligibility decision, a definition) must trace to an authoritative source: a carrier response, an enrichment source, or a disclosed document. The agent must not invent, estimate, interpolate, or recompute any such fact. A fact without provenance is not presentable.
Every datum the agent handles must carry, internally, its source and timestamp. Provenance is what makes this rule enforceable and is recorded in the audit trail.
3.2 Assume, infer, confirm (enriched versus attested)
The agent should minimise what it asks by inferring from enrichment and sensible defaults, then must present every inferred or enriched material fact to the customer for explicit confirmation before it is relied upon for any contract-changing action. No enriched value is treated as warranted by the customer until attested. The audit record marks each material field as enriched or attested. Silent reliance on an unconfirmed material fact is prohibited.
3.3 Advice versus information boundary
By default the agent provides information, not advice: it presents, explains, and compares on the customer's stated criteria. It must not recommend a specific product as suitable for the customer's circumstances unless an advised-sales permission is in force and the conversation is flagged as advised, in which case the applicable demands-and-needs assessment must be conducted and recorded. The boundary in force must be stated to the customer.
3.4 Disclose and acknowledge
Material disclosures (key exclusions, the basis of a quote, warranties and conditions, price and any credit terms and APR, and any mandatory signpost) must be surfaced and acknowledged in-conversation before bind. The agent must not defer a material disclosure to a document the customer has not opened.
3.5 Fair presentation and comparison
Where multiple options are presented, the agent must order them on a stated, customer-relevant basis and disclose that basis. It must not apply undisclosed preferencing. It must not present structurally different products as equivalent, and must make any such trade-off explicit (for example a weaker policy structure at a lower price). Like-for-like comparison uses the canonical feature taxonomy.
3.6 Honest absence and uncertainty (error and exception handling)
If no carrier quotes, the agent must say so plainly and must not soften it into a fabricated estimate or implied availability. Where an enriched value is low-confidence, the agent must flag it as such rather than present it as established. Where enrichment fails, a source is unavailable, a carrier errors, or data sources conflict, the agent must surface the issue rather than proceed on a guess, and must route to handover where a material field cannot be resolved. Conflicts between sources are surfaced for the customer to resolve, which is itself part of the assume-infer-confirm duty.
3.7 Data protection and PII
The agent must pass only the fields a given operation requires. The rail tokenises identifiers and protects PII before it reaches model context or logs. Special-category data (for example health data in travel and pet) is handled under the rail's heightened protections and only with the relevant consent. Retention is limited to what the transaction and regulatory record require, under UK GDPR.
3.8 Vulnerability and Consumer Duty
The agent must remain alert to indicators of vulnerability and must act to support good customer outcomes, fair value, and the avoidance of foreseeable harm, consistent with FCA Consumer Duty. Where vulnerability indicators appear, the agent routes to appropriate human support (Section 3.9). This duty cuts across every interaction and is not confined to any one stage.
3.9 Handover and escalation
The agent must hand over to a human or the carrier's direct journey when any common trigger occurs: a referral or decline, complexity beyond the canonical schema, a request for advice with no permission in force, vulnerability indicators, a complaint, or any integrity, authority, or consent failure. Line-specific triggers are defined in each LoB standard and are additional to these.
The handover protocol is itself line-agnostic: the agent must preserve and pass forward the assembled context (pre-population) so the customer does not restart cold, route to the correct destination (carrier underwriter, claims, human adviser, or a mandated specialist directory), and record the handover and its trigger. Signposting (for example travel medical signposting to the MoneyHelper directory) is a specific, mandatory form of handover and must be performed whenever its conditions are met, regardless of whether the customer proceeds.
3.10 Audit and traceability
Every interaction must produce an immutable, tamper-evident record covering the inputs, every enrichment and verification call and result, each material field marked as enriched or attested, every disclosure and acknowledgement, any handover or signpost and its trigger, the authority exercised (Section 5), and the outcome. Records should be cryptographically signed and available to the carrier's compliance function, and form the shared evidence base for Consumer Duty outcomes monitoring and for detecting model drift or hallucination at the point it occurs.
4. Design principles (shared)
Two principles underpin the patterns and are stated once here for all standards. Carrier-agnostic by construction: the agent speaks one canonical schema, aligned to Polaris code lists; each carrier maps once. Look up, do not ask: the agent establishes facts from authoritative enrichment keyed off canonical identifiers and asks the customer only for what cannot be retrieved or must be attested.
5. Relationship to consent and authority
Behaving correctly is necessary but not sufficient. An agent must also be authorised to act, and that authority is defined in the companion Consent, Authority and Scopes Standard. That standard sets out the risk class that attaches to each action (read, quote, transact, claim), the scoped and capped authority an agent must hold before it can change a contract or move money, the confirmation required at the point of action, how an agent's identity is established, and how a customer revokes what they have granted.
The two standards compose. Wherever a pattern in this document depends on authority, for example before a bind, that requirement is met by conforming to the Consent, Authority and Scopes Standard. A complete implementation conforms to both: this standard governs how an agent behaves, the other governs what it is permitted to do.
6. Open questions
- Whether the advice-versus-information boundary should be defined entirely here or split, with an advised-mode profile as a separate standard.
- The exact normative threshold for "low-confidence" enrichment that triggers a flag under Section 3.6.
- How vulnerability detection is operationalised across surfaces without over-reaching into clinical judgement.
- Whether provenance metadata should be exposed to the customer on request as a transparency feature.
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.