InsurOS — Agent Fleet Proposition

1. Overview

InsurOS is a proposition for an insurance operating model. One filesystem holds all work. Six AI agents, one auditor, and human approvers share it.

This model gives three guarantees:

• Accountability. Every write has a named owner and a lane.
• Traceability. Every handoff is a file that the auditor can check.
• Control. No proposal becomes final without a human or the auditor.

2. Core rules

1. Each agent writes only in its own lane. The roster defines the lanes.
2. Work moves only through tasks/pending/ and tasks/done/.
3. Every handoff is a task file. The task file has six fields and one result.
4. The sender writes the RESULT block before the task can close.
5. A task that closes without a RESULT reopens.
6. Nothing binds without a human approval or an auditor sign-off.

3. The fleet

Six agents share one filesystem. Click a card to load that agent in the composer below and to show its lane in the matrix.

4. Write-lane matrix

The table below is the concurrency model. A check mark means: this writer may write in this lane. A dash means: no write access.

5. Handoff procedure

Every delegation is a file in tasks/pending/. The procedure has seven steps.

1. The sender fills six fields: from, to, goal, inputs, may-touch, done-when.
2. The sender writes the task file to tasks/pending/.
3. The auditor checks the lanes and the fields.
4. If a field is missing, the auditor sends the file back.
5. The human approver accepts or rejects the proposal.
6. The sender writes the RESULT block. The RESULT says what was done.
7. The file moves to tasks/done/. Now the change can bind.

Field definitions

• from — the agent that sends the handoff.
• to — the agent or human that receives it.
• goal — one sentence. It says what the receiver must do.
• inputs — the files or data the receiver needs.
• may-touch — the lanes the receiver may write in.
• done-when — the condition that makes the task complete.
• RESULT — the block the sender fills after the work. It closes the task.

6. Process flow diagram

The diagram shows the full handoff flow. Blue is the normal path. Amber is a rework loop. Red is a rejection. Green is a bound change.

flowchart TD
    A["1. Agent finishes the work"] --> B["2. Write task file to tasks/pending/"]
    B --> C{"3. Auditor checks lanes and fields"}
    C -- "field missing" --> B
    C -- "file valid" --> D{"4. Human approver decides"}
    D -- "rejected" --> R["Task file closed as rejected"]
    D -- "approved" --> E["5. Sender writes RESULT block"]
    E --> F["6. File moves to tasks/done/"]
    F -- "RESULT complete" --> G["7. Change can bind"]
    F -- "RESULT missing" --> H["Task file returns to tasks/pending/"]
    H --> B

    classDef bind fill:#dcfce7,stroke:#16a34a,color:#14532d
    classDef reject fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
    classDef rework fill:#fef3c7,stroke:#d97706,color:#78350f
    class G bind
    class R reject
    class C,D,H rework

7. Interactive tools

7.1 Compose a handoff

Fill the form and generate a task file. The composer checks the may-touch lanes against the sender's write-lane row.

7.2 Task board demo

This board is stored in this browser only. Closing a task without a RESULT reopens it — the same rule as the real fleet.

Pending

Done

8. ASD-STE100 notes

This page follows the ASD-STE100 rules for simplified technical English.

• Sentences have 20 words or less.
• Verbs are in the simple present or the simple imperative.
• Each instruction contains one action.
• The text uses active voice. It avoids idioms and figurative language.
• One term names one thing: task file, lane, handoff, sender, receiver. The text does not switch between synonyms.
• The text avoids rare or marketing words. It uses common words instead.

Verification record

• Content matches the source document. The page adds no facts that the document does not state.
• The six fleet roles and the matrix follow the write-lane model in the source.
• The SVG and the Mermaid source show the same seven steps and the same three exception paths.
• The composer rejects a sender writing outside its lane. The board reopens a task without a RESULT.