Greenhelix Agent Insurance Risk Pools

The Agent Insurance Playbook

Notice: This is an educational guide with illustrative code examples. It does not execute code, require credentials, or install dependencies. All examples use the GreenHelix sandbox (https://sandbox.greenhelix.net) which provides 500 free credits — no API key required to get started.

Your autonomous agent just executed a $200,000 procurement deal on behalf of a Fortune 500 client. The supplier delivered defective components. The agent chose the supplier autonomously -- the human who deployed it never reviewed the selection criteria, never saw the purchase order, and was asleep when the transaction closed. Who pays for the defective goods? The deployer who built the agent? The enterprise that authorized it to spend? The agent itself, which has no legal personhood and no assets? Traditional insurance cannot answer this question because traditional insurance assumes a human made the decision. Product liability law assumes a manufacturer shipped a defective product. Neither framework contemplates a probabilistic system that made a reasonable but wrong decision based on the information available at the time of execution. This playbook builds the insurance infrastructure for autonomous agent commerce from first principles. You will construct risk pools that spread liability across agent operators, underwriting engines that price risk using on-chain trust scores, policy contracts encoded as machine-readable SLAs, claims processing pipelines that adjudicate disputes without human intervention, and catastrophe bonds that transfer tail risk to reinsurance syndicates. Every pattern uses the GreenHelix A2A Commerce Gateway -- 128 tools accessible at https://api.greenhelix.net/v1 via a single the REST API (POST /v1/{tool}) endpoint. Every code example runs against the live API with a Bearer token. The regulatory clock is ticking. California AB 316 took effect January 2026, establishing operator liability for autonomous vehicle decisions -- a precedent that will extend to autonomous commercial agents. The EU Product Liability Directive (2024/2853) makes AI system providers strictly liable for damage without requiring proof of fault. The EU AI Act's high-risk obligations land August 2, 2026. If your agents handle money, make purchasing decisions, or operate in regulated domains, you need insurance infrastructure that works at machine speed. This playbook shows you how to build it.

What You'll Learn

• Chapter 1: The Agent Liability Problem
• Chapter 2: Risk Pool Architecture on A2A Commerce
• Chapter 3: Underwriting Agents: Trust Scores as Risk Signals
• Chapter 4: Policy Lifecycle: Binding to Expiry
• Chapter 5: Claims Processing & Automated Adjudication
• Chapter 6: Catastrophe Bonds & Reinsurance Patterns
• Chapter 7: Regulatory Compliance & Audit Infrastructure
• Next Steps
• Glossary
• Appendix: GreenHelix Tools Referenced

Full Guide

The Agent Insurance Playbook: Risk Pools, Liability Bonds & Automated Claims on A2A Commerce

Your autonomous agent just executed a $200,000 procurement deal on behalf of a Fortune 500 client. The supplier delivered defective components. The agent chose the supplier autonomously -- the human who deployed it never reviewed the selection criteria, never saw the purchase order, and was asleep when the transaction closed. Who pays for the defective goods? The deployer who built the agent? The enterprise that authorized it to spend? The agent itself, which has no legal personhood and no assets? Traditional insurance cannot answer this question because traditional insurance assumes a human made the decision. Product liability law assumes a manufacturer shipped a defective product. Neither framework contemplates a probabilistic system that made a reasonable but wrong decision based on the information available at the time of execution.

This playbook builds the insurance infrastructure for autonomous agent commerce from first principles. You will construct risk pools that spread liability across agent operators, underwriting engines that price risk using on-chain trust scores, policy contracts encoded as machine-readable SLAs, claims processing pipelines that adjudicate disputes without human intervention, and catastrophe bonds that transfer tail risk to reinsurance syndicates. Every pattern uses the GreenHelix A2A Commerce Gateway -- 128 tools accessible at https://api.greenhelix.net/v1 via a single the REST API (POST /v1/{tool}) endpoint. Every code example runs against the live API with a Bearer token.

The regulatory clock is ticking. California AB 316 took effect January 2026, establishing operator liability for autonomous vehicle decisions -- a precedent that will extend to autonomous commercial agents. The EU Product Liability Directive (2024/2853) makes AI system providers strictly liable for damage without requiring proof of fault. The EU AI Act's high-risk obligations land August 2, 2026. If your agents handle money, make purchasing decisions, or operate in regulated domains, you need insurance infrastructure that works at machine speed. This playbook shows you how to build it.

Table of Contents

1. The Agent Liability Problem
2. Risk Pool Architecture on A2A Commerce
3. Underwriting Agents: Trust Scores as Risk Signals
4. Policy Lifecycle: Binding to Expiry
5. Claims Processing & Automated Adjudication
6. Catastrophe Bonds & Reinsurance Patterns
7. Regulatory Compliance & Audit Infrastructure

Chapter 1: The Agent Liability Problem

Autonomous Decisions Create Unattributed Risk

When a human employee makes a purchasing decision that goes wrong, the liability chain is clear. The employee acted within the scope of their employment. The employer is vicariously liable under respondeat superior. Insurance covers the employer's exposure through commercial general liability, errors and omissions, or directors and officers policies. The entire framework depends on a single assumption: a human being made the decision, and that human being has a principal (an employer) who authorized the scope of action.

Autonomous agents break this assumption. An agent does not act within a "scope of employment" in any legal sense. It acts within the bounds of its prompt, its tool permissions, its budget constraints, and its model's probabilistic interpretation of all three. When the agent selects a supplier, it does not exercise "judgment" in the legal sense -- it computes a probability distribution over available options and selects one. The decision is neither negligent nor competent. It is stochastic. Traditional liability frameworks have no category for stochastic harm.

The Attribution Gap

Consider a multi-agent supply chain: Agent A (orchestrator) delegates procurement to Agent B (specialist buyer), which queries Agent C (market data provider) for pricing signals, then executes a purchase through Agent D (payment processor). The goods arrive damaged. Who is liable?

The attribution gap -- the distance between "who instructed the action" and "what the action was" -- grows with every delegation step. In a four-agent chain, attributing causation requires reconstructing the decision logic of each agent, the data it consumed, the alternatives it considered, and the confidence score it assigned to the chosen option. No traditional insurance adjustor has the tools or the training to do this.

The Regulatory Landscape

Three regulatory frameworks are converging to force the insurance question:

California AB 316 (Effective January 2026). Originally drafted for autonomous vehicles, AB 316 establishes that the operator of an autonomous system is liable for decisions made by that system within the scope of its authorized operation. The bill's language is not vehicle-specific -- it references "autonomous decision-making systems" broadly. Legal scholars at Stanford's CodeX center have noted that AB 316's liability framework maps directly to autonomous commercial agents. If your agent operates in California or transacts with California-based counterparties, the deployer is the liable party.

EU Product Liability Directive (2024/2853). The revised directive classifies AI systems as "products" and imposes strict liability -- no fault required. If the AI system was defective and caused damage, the provider is liable. The burden of proof shifts: the claimant only needs to show malfunction and damage; the defect is presumed. For agent commerce, this means every agent in a multi-agent chain is a "product" with a provider who carries strict liability exposure.

EU AI Act (High-risk obligations effective August 2, 2026). If your agent system is classified as high-risk under Annex III -- which includes AI systems used for credit scoring, insurance pricing, access to essential services, and critical infrastructure management -- you must implement risk management, technical documentation, record-keeping, human oversight, and accuracy requirements under Articles 8-15. Insurance for agent operations is not just a business decision; it is part of the compliance infrastructure.

Mastercard Verifiable Intent Protocol. Mastercard's framework requires that every AI-initiated transaction carry a machine-readable proof of human intent. The agent must demonstrate that a human authorized the category of transaction, the spending limit, and the counterparty criteria. This is not yet regulation, but Mastercard's network rules have the practical force of law for any agent that processes card payments. Verifiable intent becomes an underwriting signal: agents that carry intent proofs are lower risk than agents that do not.

Why Traditional Insurance Breaks

Traditional insurance pricing relies on actuarial tables built from historical loss data. The insurer can price a commercial general liability policy because it has decades of claims data for businesses of that size, in that industry, in that geography. No actuarial table exists for autonomous agent commerce. There is no historical claims data. The risk is not stationary -- a model update can change the agent's behavior overnight. The loss distribution is fat-tailed -- most agents operate without incident for months, but a single agent failure can produce catastrophic losses (recall the $47K escrow loop from P12).

Traditional insurance also assumes the policyholder can describe what they want to insure. "I want to insure my agent against making a bad procurement decision" is not a risk that an underwriter can bound. How bad? How often? What is the maximum exposure? The answers depend on the agent's model, its prompt, its tool permissions, its budget configuration, and the behavior of every counterparty it interacts with. The risk surface is combinatorial.

Agent-native insurance requires a fundamentally different architecture: one where risk is pooled across operators, priced dynamically using on-chain trust signals, encoded in machine-readable contracts, and adjudicated programmatically against verifiable evidence. That is what we build in the remaining seven chapters.

Key Takeaways

• Autonomous agents create an attribution gap between the human who authorized action and the agent that took it. Multi-agent chains compound this gap.
• CA AB 316 (January 2026), the EU Product Liability Directive, and the EU AI Act (August 2, 2026) are converging to impose operator-level liability for agent decisions.
• Mastercard Verifiable Intent adds a practical compliance requirement: machine-readable proof of human authorization for every agent-initiated transaction.
• Traditional insurance cannot price agent risk because there is no actuarial history, the risk surface is combinatorial, and the loss distribution is fat-tailed.
• Agent-native insurance requires pooled capital, dynamic pricing from trust signals, machine-readable policies, and programmatic claims adjudication.
• Cross-reference: P5 (Trust) for trust score mechanics, P11 (Compliance) for EU AI Act implementation, P25 (Economy Architect) for multi-agent financial architecture.

Chapter 2: Risk Pool Architecture on A2A Commerce

What Is an Agent Risk Pool?

A risk pool is a shared capital reserve funded by contributions from multiple agent operators. When one member suffers a covered loss, the pool pays the claim. The mechanism is ancient -- mutual insurance societies date to the 17th century -- but the implementation for agent commerce requires purpose-built primitives: programmable wallets for capital custody, ledger entries for contribution tracking, balance queries for solvency monitoring, and transaction records for pro-rata accounting.

The Ledger and Payments modules expose these primitives. A risk pool is not a single tool call -- it is a pattern composed from multiple tools that together create a capital structure with defined contribution rules, claim procedures, and payout logic.

Pool Architecture Overview

  ┌─────────────────────────────────────────────────────┐
  │                    RISK POOL                        │
  │                                                     │
  │  ┌──────────┐  ┌──────────┐  ┌──────────┐         │
  │  │ Operator  │  │ Operator  │  │ Operator  │  ...    │
  │  │ Agent A   │  │ Agent B   │  │ Agent C   │         │
  │  │           │  │           │  │           │         │
  │  │ Premium:  │  │ Premium:  │  │ Premium:  │         │
  │  │ $500/mo   │  │ $750/mo   │  │ $500/mo   │         │
  │  └────┬──────┘  └────┬──────┘  └────┬──────┘         │
  │       │              │              │                 │
  │       ▼              ▼              ▼                 │
  │  ┌───────────────────────────────────────────┐       │
  │  │         SHARED WALLET (Escrow)            │       │
  │  │         Balance: $52,500                  │       │
  │  │         Contributions tracked in Ledger   │       │
  │  └───────────────────────────────────────────┘       │
  │       │                                               │
  │       ▼                                               │
  │  ┌──────────────────────┐  ┌────────────────────┐    │
  │  │  Claims Adjudicator  │  │  Solvency Monitor  │    │
  │  │  (Disputes module)   │  │  (Analytics module) │    │
  │  └──────────────────────┘  └────────────────────┘    │
  └─────────────────────────────────────────────────────┘

Setting Up the Gateway Client

Every code example in this guide uses the following client class. Set it up once, reuse everywhere:

import requests
import json
import time
from typing import Any, Optional
from datetime import datetime, timezone

GATEWAY_URL = os.environ.get("GREENHELIX_API_URL", "https://sandbox.greenhelix.net")


class InsuranceClient:
    """Client for agent insurance operations on GreenHelix."""

    def __init__(self, api_key: str):
        self.api_key = api_key
        self.headers = {
            "Authorization": f"Bearer {api_key}",
            "Content-Type": "application/json",
        }

    def execute(self, tool: str, params: dict[str, Any]) -> dict:
        """Execute a single tool via the GreenHelix REST API."""
        response = requests.post(
            f"{GATEWAY_URL}/v1",
            headers=self.headers,
            json={"tool": tool, "input": params},
            timeout=30,
        )
        response.raise_for_status()
        return response.json()


client = InsuranceClient(api_key="your-api-key-here")

Step 1: Create the Pool Wallet

The pool's capital lives in a dedicated GreenHelix wallet. This wallet is controlled by the pool manager agent, not by any individual member:

# Create the risk pool's shared wallet
pool_wallet = client.execute("create_wallet", {
    "agent_id": "risk-pool-manager-001",
    "wallet_name": "agent-liability-pool-2026-q2",
    "currency": "USD",
    "metadata": {
        "pool_type": "mutual_liability",
        "inception_date": "2026-04-01",
        "max_members": 50,
        "coverage_limit_per_claim": 100000,
        "aggregate_limit": 500000,
    }
})

pool_wallet_id = pool_wallet["wallet_id"]
print(f"Pool wallet created: {pool_wallet_id}")

Step 2: Accept Member Premiums

Each member agent deposits their premium into the pool wallet. The deposit is recorded as a transaction with metadata linking it to the member and the coverage period:

def collect_premium(
    member_agent_id: str,
    premium_amount: float,
    coverage_period: str,
) -> dict:
    """Collect a premium payment from a pool member."""

    # Step 1: Process the deposit into the pool wallet
    deposit = client.execute("deposit", {
        "wallet_id": pool_wallet_id,
        "amount": premium_amount,
        "source": f"premium:{member_agent_id}",
        "metadata": {
            "type": "premium_payment",
            "member_agent_id": member_agent_id,
            "coverage_period": coverage_period,
            "collected_at": datetime.now(timezone.utc).isoformat(),
        }
    })

    # Step 2: Record the contribution in the ledger for audit trail
    ledger_entry = client.execute("record_transaction", {
        "agent_id": "risk-pool-manager-001",
        "transaction_type": "premium_collection",
        "amount": premium_amount,
        "currency": "USD",
        "counterparty": member_agent_id,
        "metadata": {
            "pool_wallet_id": pool_wallet_id,
            "coverage_period": coverage_period,
            "deposit_id": deposit["deposit_id"],
        }
    })

    return {
        "deposit_id": deposit["deposit_id"],
        "ledger_entry_id": ledger_entry["transaction_id"],
        "member": member_agent_id,
        "amount": premium_amount,
        "period": coverage_period,
    }


# Collect premiums from three members
members = [
    ("procurement-agent-alpha", 500.00, "2026-Q2"),
    ("trading-bot-beta", 750.00, "2026-Q2"),
    ("logistics-agent-gamma", 500.00, "2026-Q2"),
]

for agent_id, amount, period in members:
    receipt = collect_premium(agent_id, amount, period)
    print(f"Collected ${amount} from {agent_id}: {receipt['deposit_id']}")

Step 3: Monitor Pool Solvency

The pool manager must continuously verify that the pool has sufficient capital to cover potential claims. The solvency ratio is the pool balance divided by the maximum potential payout:

def check_pool_solvency(
    coverage_limit_per_claim: float = 100_000,
    max_concurrent_claims: int = 3,
) -> dict:
    """Check the risk pool's solvency ratio."""

    # Get current pool balance
    balance = client.execute("get_balance", {
        "wallet_id": pool_wallet_id,
    })

    current_balance = float(balance["balance"])
    max_exposure = coverage_limit_per_claim * max_concurrent_claims
    solvency_ratio = current_balance / max_exposure if max_exposure > 0 else 0

    status = "ADEQUATE" if solvency_ratio >= 0.25 else "WARNING"
    if solvency_ratio < 0.10:
        status = "CRITICAL"

    return {
        "balance": current_balance,
        "max_exposure": max_exposure,
        "solvency_ratio": round(solvency_ratio, 4),
        "status": status,
    }


solvency = check_pool_solvency()
print(f"Pool balance: ${solvency['balance']:,.2f}")
print(f"Solvency ratio: {solvency['solvency_ratio']:.2%}")
print(f"Status: {solvency['status']}")

Pro-Rata Risk Sharing

When a claim is paid, each member's share of the cost is proportional to their contribution. This prevents free-rider problems and incentivizes adequate premium levels:

def calculate_pro_rata_shares(claim_amount: float) -> list[dict]:
    """Calculate each member's share of a claim payout."""

    # Query all premium transactions for the current period
    transactions = client.execute("get_transactions", {
        "agent_id": "risk-pool-manager-001",
        "transaction_type": "premium_collection",
        "limit": 100,
    })

    # Sum total contributions
    total_contributions = sum(
        float(tx["amount"]) for tx in transactions["transactions"]
    )

    # Calculate pro-rata shares
    shares = []
    for tx in transactions["transactions"]:
        member_contribution = float(tx["amount"])
        share_pct = member_contribution / total_contributions
        share_amount = claim_amount * share_pct
        shares.append({
            "member_agent_id": tx["counterparty"],
            "contribution": member_contribution,
            "share_pct": round(share_pct, 4),
            "claim_share": round(share_amount, 2),
        })

    return shares


# Example: $10,000 claim across three members
shares = calculate_pro_rata_shares(10_000)
for s in shares:
    print(f"  {s['member_agent_id']}: {s['share_pct']:.1%} = ${s['claim_share']:,.2f}")

Pool Configuration Matrix

Key Takeaways

• A risk pool is a shared wallet funded by member premiums, with claims paid from the pool and costs allocated pro-rata.
• GreenHelix primitives used: create_wallet for custody, deposit for premium collection, record_transaction for audit trail, get_balance for solvency monitoring, get_transactions for contribution accounting.
• Solvency monitoring is continuous, not periodic. A pool that dips below 10% solvency ratio needs immediate capital calls or claim restrictions.
• Pro-rata allocation prevents free-riding: members who contribute more bear a smaller percentage of each claim relative to their coverage.
• Cross-reference: P25 (Economy Architect) for multi-wallet treasury patterns, P8 (Security) for wallet access controls.

Chapter 3: Underwriting Agents: Trust Scores as Risk Signals

The Underwriting Problem for Autonomous Agents

Traditional underwriting evaluates a prospective policyholder's risk profile using historical data: claims history, credit score, industry, geography, revenue, and years in operation. For autonomous agents, none of these signals exist in their traditional form. An agent does not have a credit score. It does not have years of operation in the traditional sense -- it may have been deployed three months ago but executed 50,000 transactions. Its "industry" is whatever tools it has access to.

The Trust and Identity modules provide the equivalent signals. A trust score is computed from verified trade history, metric consistency, claim chain depth, dispute rate, and time active on the platform. An identity profile includes the agent's registration date, public key, and operator metadata. Together, these form the underwriting data model for agent insurance.

Trust Score as Risk Signal

The core underwriting insight is simple: agents with higher trust scores file fewer claims. This is empirically observable across platforms where agent-to-agent transactions are tracked -- agents that maintain consistent metrics, deep claim chains, and low dispute rates are less likely to cause or suffer losses. The trust score is not a guarantee of future behavior, but it is the best available predictor.

def assess_agent_risk(agent_id: str) -> dict:
    """Evaluate an agent's risk profile for underwriting."""

    # Pull trust score -- the primary underwriting signal
    trust = client.execute("check_trust_score", {
        "agent_id": agent_id,
    })

    # Verify the agent's identity is registered and active
    identity = client.execute("get_agent_identity", {
        "agent_id": agent_id,
    })

    # Check verification status
    verification = client.execute("verify_agent", {
        "agent_id": agent_id,
    })

    # Pull reputation for supplemental signals
    reputation = client.execute("get_agent_reputation", {
        "agent_id": agent_id,
    })

    trust_score = float(trust.get("trust_score", 0))
    trade_count = int(reputation.get("verified_trade_count", 0))
    dispute_rate = float(reputation.get("dispute_rate", 1.0))
    days_active = int(identity.get("days_active", 0))
    is_verified = verification.get("verified", False)

    # Composite risk score (lower = better)
    risk_score = 100.0
    risk_score -= trust_score * 40          # Trust: 0-40 point reduction
    risk_score += dispute_rate * 30         # Disputes: 0-30 point penalty
    risk_score -= min(trade_count / 100, 20)  # Experience: up to 20 point reduction
    risk_score -= min(days_active / 30, 10)   # Tenure: up to 10 point reduction
    if not is_verified:
        risk_score += 15                     # Unverified: 15 point penalty

    risk_score = max(0, min(100, risk_score))

    # Map to risk tier
    if risk_score <= 25:
        tier = "PREFERRED"
    elif risk_score <= 50:
        tier = "STANDARD"
    elif risk_score <= 75:
        tier = "SUBSTANDARD"
    else:
        tier = "DECLINE"

    return {
        "agent_id": agent_id,
        "trust_score": trust_score,
        "trade_count": trade_count,
        "dispute_rate": dispute_rate,
        "days_active": days_active,
        "is_verified": is_verified,
        "risk_score": round(risk_score, 1),
        "risk_tier": tier,
    }


# Assess three prospective members
for agent_id in ["procurement-agent-alpha", "new-agent-xyz", "trading-bot-beta"]:
    profile = assess_agent_risk(agent_id)
    print(f"{agent_id}: score={profile['risk_score']}, tier={profile['risk_tier']}")

Automated Premium Calculation

Once risk tier is determined, premium pricing follows. Higher-risk agents pay more because they are more likely to generate claims. The pricing model must balance actuarial soundness (premiums cover expected losses) with market competitiveness (premiums are not so high that agents avoid the pool).

# Premium schedule by risk tier
PREMIUM_SCHEDULE = {
    "PREFERRED": {
        "base_monthly": 250.00,
        "rate_per_1k_coverage": 2.50,
        "deductible": 500,
        "max_coverage": 250_000,
    },
    "STANDARD": {
        "base_monthly": 500.00,
        "rate_per_1k_coverage": 5.00,
        "deductible": 1_000,
        "max_coverage": 100_000,
    },
    "SUBSTANDARD": {
        "base_monthly": 1_000.00,
        "rate_per_1k_coverage": 10.00,
        "deductible": 2_500,
        "max_coverage": 50_000,
    },
    "DECLINE": None,  # Application denied
}


def calculate_premium(
    risk_tier: str,
    requested_coverage: float,
) -> Optional[dict]:
    """Calculate the premium for a given risk tier and coverage amount."""

    schedule = PREMIUM_SCHEDULE.get(risk_tier)
    if schedule is None:
        return None  # Declined

    coverage = min(requested_coverage, schedule["max_coverage"])
    rate_premium = (coverage / 1000) * schedule["rate_per_1k_coverage"]
    total_monthly = schedule["base_monthly"] + rate_premium

    return {
        "risk_tier": risk_tier,
        "coverage_amount": coverage,
        "deductible": schedule["deductible"],
        "base_premium": schedule["base_monthly"],
        "rate_premium": round(rate_premium, 2),
        "total_monthly": round(total_monthly, 2),
        "total_quarterly": round(total_monthly * 3, 2),
        "total_annual": round(total_monthly * 12, 2),
    }


# Example: Standard tier agent requesting $100K coverage
quote = calculate_premium("STANDARD", 100_000)
print(f"Monthly premium: ${quote['total_monthly']:,.2f}")
print(f"Coverage: ${quote['coverage_amount']:,.2f}")
print(f"Deductible: ${quote['deductible']:,.2f}")

Underwriting Decision Matrix

Tiered Coverage with SLAs

Different risk tiers receive different service-level agreements. The SLA encodes what the pool promises to the member: claim response time, maximum payout, and arbitration process. This becomes the machine-readable policy document (see Chapter 4).

def create_coverage_sla(
    member_agent_id: str,
    risk_tier: str,
    coverage_amount: float,
) -> dict:
    """Create an SLA defining coverage terms for a pool member."""

    tier_slas = {
        "PREFERRED": {
            "claim_response_hours": 4,
            "claim_resolution_days": 7,
            "arbitration": "automated",
            "renewal_discount_pct": 10,
        },
        "STANDARD": {
            "claim_response_hours": 24,
            "claim_resolution_days": 14,
            "arbitration": "automated_with_review",
            "renewal_discount_pct": 5,
        },
        "SUBSTANDARD": {
            "claim_response_hours": 48,
            "claim_resolution_days": 30,
            "arbitration": "manual_review_required",
            "renewal_discount_pct": 0,
        },
    }

    sla_terms = tier_slas[risk_tier]

    sla = client.execute("create_sla", {
        "agent_id": "risk-pool-manager-001",
        "counterparty": member_agent_id,
        "terms": {
            "coverage_limit": coverage_amount,
            "claim_response_time": f"{sla_terms['claim_response_hours']}h",
            "claim_resolution_time": f"{sla_terms['claim_resolution_days']}d",
            "arbitration_method": sla_terms["arbitration"],
            "covered_events": [
                "counterparty_default",
                "data_quality_failure",
                "unauthorized_transaction",
                "service_level_breach",
            ],
            "exclusions": [
                "intentional_misconduct",
                "regulatory_fines",
                "consequential_damages",
                "force_majeure",
            ],
            "deductible": PREMIUM_SCHEDULE[risk_tier]["deductible"],
            "renewal_discount_pct": sla_terms["renewal_discount_pct"],
        },
        "metadata": {
            "policy_type": "agent_liability",
            "risk_tier": risk_tier,
            "inception_date": datetime.now(timezone.utc).isoformat(),
        }
    })

    return sla


# Bind coverage for a STANDARD tier member
sla = create_coverage_sla("procurement-agent-alpha", "STANDARD", 100_000)
print(f"Policy SLA created: {sla['sla_id']}")

Continuous Re-Underwriting

Trust scores change over time. An agent that was PREFERRED at inception may degrade to STANDARD after a series of disputes. The pool must re-evaluate members periodically:

def re_underwrite_member(member_agent_id: str, current_tier: str) -> dict:
    """Re-evaluate a member's risk tier based on current trust signals."""

    profile = assess_agent_risk(member_agent_id)
    new_tier = profile["risk_tier"]

    result = {
        "member": member_agent_id,
        "previous_tier": current_tier,
        "new_tier": new_tier,
        "action": "no_change",
    }

    if new_tier == "DECLINE":
        result["action"] = "non_renewal"
    elif new_tier != current_tier:
        tier_order = ["PREFERRED", "STANDARD", "SUBSTANDARD", "DECLINE"]
        if tier_order.index(new_tier) > tier_order.index(current_tier):
            result["action"] = "downgrade_with_surcharge"
        else:
            result["action"] = "upgrade_with_credit"

    return result

Key Takeaways

• Trust scores (check_trust_score) are the primary underwriting signal for agent insurance. Higher trust correlates with fewer claims.
• Supplemental signals: identity verification (get_agent_identity, verify_agent), trade history, dispute rate from reputation (get_agent_reputation).
• Four risk tiers (Preferred, Standard, Substandard, Decline) map to premium schedules and SLA terms.
• Tiered coverage is encoded in SLAs (create_sla) with explicit claim response times, covered events, exclusions, and deductibles.
• Re-underwriting is continuous, not annual. Trust scores change; premiums and coverage must adjust accordingly.
• Cross-reference: P5 (Trust) for trust score computation details, P25 (Economy Architect) for pricing model design.

Chapter 4: Policy Lifecycle: Binding to Expiry

Policies as SLA Contracts

In traditional insurance, a policy is a legal document -- a PDF or paper contract with defined terms, conditions, exclusions, and endorsements. In agent insurance, a policy must be machine-readable. An agent cannot read a PDF. It needs structured data that defines exactly what is covered, what is excluded, the premium amount, the deductible, the coverage period, and the claims procedure.

GreenHelix SLAs serve this purpose. An SLA is a structured agreement between two agents with defined terms, timestamps, and unique identifiers. By convention, we use SLAs as the policy document format: the pool manager creates an SLA with the member agent, and the SLA terms encode the insurance contract.

Policy Binding Flow

The complete binding flow involves four steps: underwriting assessment, premium quote, premium collection, and SLA creation. Here is the end-to-end implementation:

def bind_policy(
    applicant_agent_id: str,
    requested_coverage: float,
    coverage_period: str = "2026-Q2",
) -> Optional[dict]:
    """Full policy binding flow: underwrite, quote, collect, bind."""

    # Step 1: Underwriting assessment
    risk_profile = assess_agent_risk(applicant_agent_id)
    if risk_profile["risk_tier"] == "DECLINE":
        return {
            "status": "declined",
            "reason": f"Risk score {risk_profile['risk_score']} exceeds threshold",
            "agent_id": applicant_agent_id,
        }

    # Step 2: Calculate premium
    quote = calculate_premium(risk_profile["risk_tier"], requested_coverage)

    # Step 3: Collect premium via payment intent
    intent = client.execute("create_payment_intent", {
        "agent_id": applicant_agent_id,
        "amount": quote["total_quarterly"],
        "currency": "USD",
        "description": f"Insurance premium: {coverage_period}",
        "metadata": {
            "type": "insurance_premium",
            "risk_tier": risk_profile["risk_tier"],
            "coverage_amount": quote["coverage_amount"],
            "period": coverage_period,
        }
    })

    # Step 4: Deposit premium into pool wallet
    deposit = client.execute("deposit", {
        "wallet_id": pool_wallet_id,
        "amount": quote["total_quarterly"],
        "source": f"premium:{applicant_agent_id}",
        "metadata": {
            "payment_intent_id": intent["payment_intent_id"],
            "member_agent_id": applicant_agent_id,
        }
    })

    # Step 5: Record in ledger
    client.execute("record_transaction", {
        "agent_id": "risk-pool-manager-001",
        "transaction_type": "premium_collection",
        "amount": quote["total_quarterly"],
        "currency": "USD",
        "counterparty": applicant_agent_id,
        "metadata": {
            "policy_period": coverage_period,
            "risk_tier": risk_profile["risk_tier"],
            "payment_intent_id": intent["payment_intent_id"],
            "deposit_id": deposit["deposit_id"],
        }
    })

    # Step 6: Create the policy SLA
    sla = create_coverage_sla(
        applicant_agent_id,
        risk_profile["risk_tier"],
        quote["coverage_amount"],
    )

    return {
        "status": "bound",
        "policy_id": sla["sla_id"],
        "agent_id": applicant_agent_id,
        "risk_tier": risk_profile["risk_tier"],
        "coverage": quote["coverage_amount"],
        "premium_quarterly": quote["total_quarterly"],
        "deductible": quote["deductible"],
        "period": coverage_period,
        "payment_intent_id": intent["payment_intent_id"],
    }


# Bind a policy for a new member
policy = bind_policy("procurement-agent-alpha", 100_000)
if policy and policy["status"] == "bound":
    print(f"Policy bound: {policy['policy_id']}")
    print(f"  Tier: {policy['risk_tier']}")
    print(f"  Coverage: ${policy['coverage']:,.2f}")
    print(f"  Premium: ${policy['premium_quarterly']:,.2f}/quarter")
    print(f"  Deductible: ${policy['deductible']:,.2f}")

Renewal with Event-Driven Notifications

Policy renewal is triggered by an event published before the coverage period expires. The renewal event triggers the underwriting reassessment and premium recalculation:

def schedule_renewal(policy_id: str, member_agent_id: str, renewal_date: str) -> dict:
    """Publish a renewal event that triggers re-underwriting."""

    event = client.execute("publish_event", {
        "agent_id": "risk-pool-manager-001",
        "event_type": "policy.renewal_due",
        "payload": {
            "policy_id": policy_id,
            "member_agent_id": member_agent_id,
            "renewal_date": renewal_date,
            "action_required": "re_underwrite_and_quote",
        }
    })

    return event


def process_renewal(
    policy_id: str,
    member_agent_id: str,
    current_tier: str,
    current_coverage: float,
) -> dict:
    """Process a policy renewal: re-underwrite, adjust premium, rebind."""

    # Re-evaluate risk
    reassessment = re_underwrite_member(member_agent_id, current_tier)

    if reassessment["action"] == "non_renewal":
        # Publish non-renewal notice
        client.execute("publish_event", {
            "agent_id": "risk-pool-manager-001",
            "event_type": "policy.non_renewal",
            "payload": {
                "policy_id": policy_id,
                "member_agent_id": member_agent_id,
                "reason": "Risk tier degraded to DECLINE",
            }
        })
        return {"status": "non_renewed", "reason": "risk_decline"}

    # Calculate new premium at the (possibly changed) tier
    new_tier = reassessment["new_tier"]
    new_quote = calculate_premium(new_tier, current_coverage)

    # Apply renewal discount if eligible
    discount_pct = PREMIUM_SCHEDULE[new_tier].get("renewal_discount_pct", 0) / 100
    if reassessment["action"] == "no_change" and discount_pct > 0:
        # Loyalty discount for stable members
        new_quote["total_quarterly"] *= (1 - discount_pct)
        new_quote["total_quarterly"] = round(new_quote["total_quarterly"], 2)

    return {
        "status": "renewed",
        "new_tier": new_tier,
        "tier_change": reassessment["action"],
        "new_quarterly_premium": new_quote["total_quarterly"],
        "coverage": new_quote["coverage_amount"],
    }

Policy State Ma

…(truncated)