Coverage Cat is a YC S22 insurance brokerage that lets agents quote and bind umbrella policies through an API. The interesting part is not the product pitch. It is the infrastructure required when an agent can create legal obligations, handle sensitive financial data, and coordinate across multiple carrier APIs without leaking credentials or creating unauditable decisions.
Most agent demos retrieve information. Coverage Cat’s agent writes contracts. That changes the authorization model, the state management requirements, and the failure recovery strategy.
The Authorization Problem
An insurance agent needs to query carrier APIs to pull quotes, compare coverage limits, and bind policies. Each carrier has its own authentication scheme. Some use OAuth, some use API keys with IP allowlisting, and some require session tokens that expire after 15 minutes.
Coverage Cat solves this with a credential vault and a broker proxy layer:
- Credential vault: Stores carrier API keys, OAuth refresh tokens, and session state. The agent never sees raw credentials.
- Broker proxy: Wraps carrier APIs behind a unified interface. The agent calls
get_quote(carrier, policy_params)and the proxy handles authentication, retries, and rate limiting. - Scoped tokens: Each agent session gets a short-lived token that grants access to a specific user’s policy data. The token cannot be used to bind policies for other users or access the credential vault.
This is similar to how Plaid wraps bank APIs, but with the added constraint that the agent must be able to bind contracts, not just read data.
State Management Across Days
Umbrella insurance quotes require data from existing auto and home policies. A user might upload their current declarations page on Monday, get a quote on Tuesday, and bind the policy on Friday. The agent needs to maintain context across all three interactions.
Coverage Cat uses a conversation state machine with checkpoints:
- Intake: Collect user details, existing policies, and coverage preferences. Store in a structured state object.
- Quote: Call carrier APIs with the intake data. Cache quotes for 7 days (typical carrier validity window).
- Bind: Verify the quote is still valid, collect payment, and submit the bind request to the carrier.
Each checkpoint is stored in Postgres with a state hash. If the user returns after the quote expires, the agent detects the stale state and re-runs the quote step before proceeding to bind.
The state object includes:
{
"user_id": "usr_abc123",
"conversation_id": "conv_xyz789",
"stage": "quote_ready",
"intake": {
"existing_auto_policy": { "carrier": "Geico", "liability_limit": 250000 },
"existing_home_policy": { "carrier": "State Farm", "dwelling_limit": 500000 }
},
"quotes": [
{ "carrier": "Travelers", "premium": 320, "limit": 1000000, "expires_at": "2026-10-06T00:00:00Z" }
],
"selected_quote": "Travelers",
"checkpoint_hash": "sha256:abc..."
}If the agent crashes mid-conversation, it can resume from the last checkpoint without re-querying carriers or asking the user to re-upload documents.
Audit Trails for Compliance
Insurance brokers are required to log every quote, every bind, and every piece of advice given to a customer. If a user later disputes a policy or files a complaint with the state insurance commissioner, the brokerage must produce a complete audit trail.
Coverage Cat logs every agent action to an append-only audit table:
| Timestamp | User ID | Agent Action | Input | Output | Result |
|---|---|---|---|---|---|
| 2026-09-22 14:32:01 | usr_abc123 | get_quote | { carrier: “Travelers”, limit: 1000000 } | { premium: 320, expires_at: ”…” } | success |
| 2026-09-22 14:35:12 | usr_abc123 | bind_policy | { carrier: “Travelers”, quote_id: “q_xyz” } | { policy_number: “POL123” } | success |
| 2026-09-22 14:35:13 | usr_abc123 | send_confirmation | { email: “user@example.com” } | { message_id: “msg_abc” } | success |
The audit log is separate from the application database. It uses a different write key and is replicated to cold storage every hour. This prevents an agent bug or a compromised credential from tampering with the audit trail.
Each log entry includes the agent’s reasoning trace (if available) and the tool calls it made. If the agent misquotes a policy, the audit log shows which carrier API returned the bad data and which decision logic the agent used to select it.
Failure Modes and Rollback
When an agent binds a policy, it creates a legal obligation. If the bind request succeeds at the carrier but fails to record in Coverage Cat’s database, the user has coverage but no record of it. If the bind request fails at the carrier but succeeds in the database, the user thinks they have coverage but they do not.
Coverage Cat uses a two-phase commit pattern:
- Reserve: Call the carrier’s bind API and get a policy number. Do not finalize the policy yet.
- Record: Write the policy number to the database with status
pending. - Finalize: Call the carrier’s finalize API to activate the policy. Update the database status to
active.
If step 3 fails, the agent can retry the finalize call or roll back by canceling the reserved policy. If step 2 fails, the agent cancels the reservation and returns an error to the user.
Not all carriers support reservations. For those, Coverage Cat uses a compensating transaction: if the database write fails after a successful bind, the agent immediately calls the carrier’s cancel API and logs the incident for manual review.
Agent API Surface
Coverage Cat exposes its agent capabilities through an MCP server and an OpenAPI-compatible REST API. The MCP server is discoverable at /.well-known/mcp.json and includes tools for:
umbrella_consumer_prefill: Pre-fill a quote form with data from existing policies.get_quote: Fetch quotes from multiple carriers.compare_coverage: Compare two quotes side by side.bind_policy: Bind a selected quote and return the policy number.
Each tool requires a scoped token. The token is issued after the user authenticates with Coverage Cat and grants the agent permission to act on their behalf. The token includes claims for:
user_id: The user the agent is acting for.allowed_actions: A list of tools the agent can call (e.g.,["get_quote", "bind_policy"]).expiration: Token validity window (typically 1 hour).
The agent cannot escalate its privileges. If it tries to call a tool not in allowed_actions, the API returns a 403.
Observability and Debugging
Coverage Cat instruments every agent interaction with OpenTelemetry spans. Each span includes:
- The tool called
- The input parameters
- The carrier API response
- The agent’s decision logic (if using a reasoning model)
- The latency and error rate
Spans are exported to Honeycomb for real-time debugging. If a user reports a bad quote, the support team can search for the conversation ID and see the exact sequence of tool calls, carrier responses, and agent decisions that led to the quote.
The agent also emits custom metrics:
quote_latency_p99: 99th percentile latency for quote requests.bind_success_rate: Percentage of bind requests that succeed on the first try.carrier_error_rate: Percentage of carrier API calls that return errors.
These metrics feed into alerting rules. If bind_success_rate drops below 95%, the on-call engineer gets paged.
Deployment Shape
Coverage Cat runs on AWS with the following components:
- API Gateway: Routes agent requests to the appropriate backend service.
- Lambda functions: Handle tool calls (get_quote, bind_policy, etc.). Each function has a 30-second timeout and retries failed carrier API calls up to 3 times.
- RDS Postgres: Stores conversation state, audit logs, and policy records.
- S3: Stores uploaded documents (declarations pages, proof of prior coverage).
- SQS: Queues bind requests for asynchronous processing. If a carrier API is slow, the bind request goes into the queue and the agent polls for completion.
The credential vault is a separate service that runs in a private subnet with no internet access. It only accepts requests from the broker proxy layer and logs every credential access.
Trade-offs and Risks
| Dimension | Coverage Cat Approach | Trade-off |
|---|---|---|
| Authorization | Scoped tokens with short expiration | Requires token refresh logic in the agent |
| State management | Checkpointed state machine | Adds complexity but enables multi-day conversations |
| Audit logging | Append-only table with separate write key | Cannot delete or edit logs, even for GDPR requests |
| Failure recovery | Two-phase commit with compensating transactions | Not all carriers support reservations |
| Observability | Full OpenTelemetry instrumentation | High cardinality spans increase storage costs |
The biggest risk is a carrier API change that breaks the broker proxy. Coverage Cat mitigates this with integration tests that run against carrier sandbox environments every hour. If a test fails, the on-call engineer investigates before the change hits production.
Technical Verdict
Use Coverage Cat’s architecture when:
- Your agent creates legal or financial obligations (contracts, payments, trades).
- You need to maintain state across multiple user interactions spanning days or weeks.
- You must produce audit trails for compliance or dispute resolution.
- You integrate with third-party APIs that have different authentication schemes and reliability profiles.
Avoid this approach when:
- Your agent only retrieves information and does not modify state.
- You can tolerate eventual consistency and do not need strong transactional guarantees.
- You do not have regulatory requirements for audit logging.
- Your agent interactions are stateless and complete in a single request-response cycle.
The key insight is that financial agents need authorization primitives that go beyond API keys. Scoped tokens, checkpointed state, and two-phase commits are not optional. They are the minimum viable plumbing for agents that handle real money and legal liability.