# Building Recourse.ai: A Parametric Insurance Prototype for the Age of Agentic AI

> Source: <https://dev.to/alfinohatta/building-recourseai-a-parametric-insurance-prototype-for-the-age-of-agentic-ai-1mdc>
> Published: 2026-07-18 09:49:19+00:00

Every enterprise I've talked to in the last year has the same story: AI agents are being deployed faster than risk and compliance teams can review them. Procurement moves in weeks, legal review moves in quarters, and the gap in between is where the real exposure lives.

Traditional Errors & Omissions (E&O) insurance was never designed for this pace. It assumes a world where risk changes slowly enough that an annual form and a broker phone call are sufficient to underwrite it. That assumption breaks down completely with autonomous systems. An agent can make thousands of decisions an hour, and a subtle failure mode (what people in this space call "silent AI" risk) can run for weeks before a human notices anything is wrong. By the time a claim gets filed under the old model, the damage has already compounded, and the insurer is reconstructing what happened from logs and depositions instead of live data.

I wanted to sit with a narrower, more concrete question: what would insurance look like if it were driven by live operational signals instead of static paperwork? Not as a thought experiment, but as something I could actually build and click through. That question turned into **Recourse.ai**, an Android prototype built with the Lloyd's Lab ecosystem in mind. It bridges AI operational telemetry with parametric insurance workflows, converting real-time agent behavior into instant, verifiable payouts whenever a pre-agreed safety threshold gets crossed.

This post walks through what the app does, why I made the architectural choices I made, where I deliberately cut corners as a prototype, and what I'd change before anyone put real money behind it.

Parametric insurance isn't a new idea. It's used heavily in areas like crop insurance and catastrophe bonds, where a payout is triggered automatically once a measurable condition is met (rainfall below X millimeters, wind speed above Y knots), rather than requiring a lengthy claims investigation to establish fault and damages.

Recourse applies that same logic to AI operations. Instead of rainfall or wind speed, the triggering condition is something like "agent error rate exceeds a defined threshold for a defined window" or "an agent takes an action outside its approved guardrails." Once that condition is met and verified against the policy's rules, the payout process starts automatically. No adjuster has to reconstruct what happened weeks later. The telemetry data that triggered the payout *is* the evidence.

This matters because it changes the incentive structure on both sides. Insurers can price risk based on live signals rather than guesswork, and the organizations being insured have a direct incentive to invest in better guardrails, because better guardrails literally lower their premiums and reduce their exposure to slow claims.

At its core, the app turns AI operational risk into something measurable and insurable. It does this through three connected capabilities:

**Quantifying risk.** Every monitored AI agent gets a "Guardrail Maturity Score," calculated from its live behavior rather than a self-reported checklist filled out once and forgotten. The score reflects things like how often an agent operates within its defined boundaries, how it responds to anomalous inputs, and how frequently human intervention is required.

**Automating payouts.** When a defined threshold is breached (say, an agent's error rate crosses a contractually agreed limit, or a kill-switch is triggered), the parametric rules engine verifies the condition against the policy and initiates a payout. In the prototype, this is modeled to clear in under 48 hours, a dramatic contrast to the 90-plus days typical of traditional E&O claims.

**Benchmarking performance.** For finance leaders, the app surfaces real-time ROI and efficiency metrics, showing how the cost of automation compares against traditional benchmarks and how much has been recovered through the insurance layer itself.

Rather than build a generic dashboard and hope it was useful to everyone, I anchored the whole app around four personas who would actually interact with a product like this:

| Persona | Primary objective | Key feature used |
|---|---|---|
| CFO / COO | ROI and financial stability | Executive metric grid (recovered funds, efficiency gains) |
| Head of AI | Operational reliability | Agent telemetry and automatic safety kill switches |
| General Counsel | Governance and audit | Region-specific compliance audits (EU AI Act, DIFC) |
| Broker | Capacity distribution | Capacity monitoring and parametric policy management |

Every screen in the app maps back to one of these people's actual job. The login flow is persona-driven, so a CFO signing in sees financial recovery numbers front and center, while a Head of AI signing in lands on agent-level telemetry. The incident deep-dive view is written for General Counsel, with estimated financial exposure and jurisdictional legal context laid out clearly enough to drop into a board memo. And the policy triggers screen exists mainly for brokers, showing the rules engine logic in a way that's transparent rather than a black box.

This persona-first approach shaped a lot of small decisions that might otherwise seem arbitrary, like why the executive entry screen is built for instant boardroom demonstrations rather than a typical consumer onboarding flow. The app isn't trying to be sticky or habit-forming. It's trying to be legible to a specific decision maker in under thirty seconds.

I went with a decoupled **MVVM (Model-View-ViewModel) architecture** on Android. The main reason was separation of concerns: I wanted the UI layer to stay dumb and testable, while all the payout logic and business rules lived somewhere I could reason about independently of any particular screen.

In practice, that means Activities and their Adapters handle rendering and user input, ViewModels hold UI state as `StateFlow`

, and Repositories own the job of fetching and shaping data, whether that data comes from a live database or a fallback source. Business logic, including the payout engine itself, sits behind the Repository layer so it isn't entangled with any specific view.

The more interesting design problem was the data layer. Live demos are unforgiving. A dropped database connection mid-pitch, in front of a room full of underwriters or CFOs, kills credibility instantly, regardless of how good the actual product is. So instead of assuming a database connection would always be available, I built the repository layer to support two paths:

That fallback logic lives in a custom `DatabaseHelper`

class. Critically, the ViewModels above it don't need to know or care which path actually served the data. They just receive a domain object and update state accordingly. This kept the resiliency logic contained in one place instead of scattered as defensive `try/catch`

blocks across every screen.

Here's the request lifecycle when a user opens an incident, which illustrates how the fallback fits into the normal flow rather than being a special case bolted on afterward:

``` php
User selects an incident
  -> View requests detail(incidentId) from ViewModel
    -> ViewModel asks Repository for telemetry and thresholds
      -> Repository queries MySQL (JOIN across agents/policies tables)
        -> if connected: return the ResultSet
        -> if not connected: fall back to mock strategic data
    -> Repository returns a single domain object either way
  -> ViewModel updates UI state
-> View renders the risk report and claim status
```

Kotlin Coroutines and `StateFlow`

handle the asynchronous plumbing end to end. That combination kept the UI layer free of nested callbacks and made loading, success, and error states straightforward to represent and test, since each state is just a value the ViewModel emits rather than a chain of listener callbacks.

It would be easy to dismiss the mock data fallback as a shortcut for pitching investors, and honestly, part of its purpose is exactly that. But it also reflects something real about how these systems need to behave in production. An insurance workflow tool that goes dark the moment a database connection blips is not a tool anyone will trust with time-sensitive payout logic. Building the resiliency pattern in from day one, even in a prototype, forced me to think about failure modes early rather than treating them as an afterthought once something breaks in front of a real user.

`isVisible`

) to keep the codebase concise and idiomatic rather than fighting Java-style verbosity.To make the parametric trigger verification concrete, it helps to walk through the full sequence rather than just describing it in prose. When a user selects an incident from the dashboard, the View asks the ViewModel for detail on that specific incident ID. The ViewModel, in turn, asks the Repository to fetch both the telemetry data and the relevant policy thresholds. The Repository issues a SQL query that joins across the agents and policies tables in MySQL.

If the database connection is healthy, the query returns a ResultSet that gets mapped into a domain object. If the connection isn't available, the Repository silently falls back to loading the equivalent mock data, constructed to be realistic enough that a viewer can't tell the difference during a demo. Either way, the ViewModel receives a single, consistent domain object, updates the UI state, and the View renders the risk report along with the current claim status.

The point of walking through this in detail is that the fallback isn't a separate code path that diverges from the "real" one. It's integrated at the point where data enters the system, which means every downstream consumer of that data behaves identically regardless of where the data actually came from.

A few principles guided the security and compliance design, even at prototype stage:

**Data minimization.** The telemetry layer only captures agent metadata and financial amounts, deliberately avoiding personally identifiable information wherever possible. This wasn't an afterthought bolted on before a compliance review. It was a constraint from the first schema design, because the whole pitch of the product depends on being trustworthy with sensitive operational data.

**Deterministic, inspectable rules.** The parametric verification logic is intentionally deterministic. Given the same telemetry and the same policy thresholds, it produces the same payout decision every time. This matters because the entire value proposition of parametric insurance collapses if the trigger logic feels like a black box. If a General Counsel can't explain to a board why a payout did or didn't happen, the product hasn't actually solved the trust problem it set out to solve.

**Local resiliency, with an asterisk.** In a production environment, direct JDBC access from the client app would be replaced with an authenticated REST API. Using JDBC directly in the prototype was a deliberate trade-off for demo performance and development speed, not a decision I'd defend for a real deployment handling real policyholder data.

I licensed the project under the GNU Affero General Public License v3.0 rather than a more permissive option like MIT or Apache 2.0, and this wasn't a default choice made without thinking about it.

The core argument for parametric insurance in this space is that claims shouldn't be a black box. If that's the actual thesis of the product, then the rules engine deciding who gets paid and when should be inspectable by the people affected by it, not locked away inside a proprietary hosted service that nobody outside the company can audit. AGPL specifically closes the loophole that plain GPL leaves open: if someone takes this code, modifies it, and runs it as a hosted service without redistributing the source, standard GPL wouldn't require them to share those changes. AGPL does. That felt directly aligned with what the project is trying to prove, rather than an incidental legal detail.

I want to be upfront about the parts of this that are deliberately prototype-grade, because a technical write-up that only talks about what worked isn't very useful to anyone else building something similar.

The direct JDBC connection from the client is the biggest one. It's fine for a controlled demo running against a database I control, but it would be a serious liability in production. Any real version of this needs an authenticated REST or GraphQL API sitting between the client and the database, with proper access control and rate limiting.

The compliance engine is currently rules-based and hardcoded per jurisdiction. That works for three regions in a demo, but it doesn't scale. A production version would need to externalize that logic into a proper policy engine, something more like a rules-as-configuration system, so that adding a new jurisdiction doesn't mean shipping a new app build.

The mock data, while high fidelity, is still fabricated. Before any real underwriting decisions get made on top of this, the telemetry ingestion pipeline needs to be validated against actual agent logging formats from real deployments, which vary a lot more than a clean mock dataset suggests.

And finally, the "Guardrail Maturity Score" as implemented is a reasonable first pass at quantifying agent behavior, but it hasn't been validated against actual loss data. Turning it into something an actuary would sign off on requires a much longer feedback loop between the score and real claims history, which by definition doesn't exist yet for a category this new.

A few things stood out to me while working on this that I think generalize beyond this specific project.

Building resiliency in early, even for a prototype, pays off. The Local Mode fallback started as a way to survive flaky demo wifi, but it ended up shaping how I thought about the whole data layer, and it's a pattern I'd default to again for anything that needs to be presented live.

Designing around named personas rather than generic user stories made a surprising number of small UI decisions obvious that would otherwise have required guesswork. Once I knew a CFO was the one looking at a given screen, questions like "what number goes at the top" answered themselves.

And choosing a license is a design decision, not an administrative one. AGPL wasn't the "safe" default choice for a project hoping to attract commercial interest, but it was the choice that actually matched what the product claims to stand for.

Recourse is explicitly positioned as a first-mover bet in the agentic AI insurance space, and the roadmap reflects that ambition in stages. The near-term plan is a beachhead in D2C retail, operating inside regulatory sandboxes like MAS and ADGM where the compliance burden of a full launch is lower. From there, the path runs toward securing A-rated capacity and formalizing a broker channel, since parametric insurance at scale needs real underwriting capacity behind it, not just clever software. The longer-term pivot is toward white-labeled, embedded platform distribution, so the parametric rules engine could eventually sit inside other companies' products rather than only existing as a standalone app.

None of that is guaranteed, and a lot of it depends on things outside the codebase, like regulatory appetite and actual underwriting partnerships. But having a working prototype that a CFO, a Head of AI, and a General Counsel can each click through and immediately understand is a meaningfully different starting point than a slide deck.

If you want to look at the actual implementation, including the mock data layer, the compliance engine logic, and the full MVVM structure, the source is on GitHub: [github.com/alfinohatta/recourse](https://github.com/alfinohatta/recourse)