# The Resource Pool: A Grant That Depletes, And The First Loss Data This Pivot Can Have

**version** v0.33.83
**date** 1 September 2026
**from** Human (project lead)
**to** Strategy, the RiskMandate team, the registry site

**type** Strategy brief — memo 11, and the series was called complete at ten

*Produced from a voice memo of 1 September 2026, carried verbatim below and then read against the corpus by the site agent. Everything in the transcript is the project lead's; everything under the reading is the site agent's and is labelled as such. **The series has now been called complete twice and grown twice** — announced as eight, closed at ten, and reopened here. The gate written at v0.33.82 for exactly this fired on doctrine 10 when this memo was filed, and §8 records what it caught.*

---

## What This Is

The second axis: **the memo observes that an insurance policy is fundamentally a buffer that permits variability, and applies that to what an agent consumes rather than to what it can reach — proposing a pool of resources, tokens as the first instance, underwritten for a population of agents rather than allocated per agent, on the reasoning that a spike in one execution out of a hundred is acceptable where the same spike across all hundred is not; the pool grants a licence to operate that holds while consumption stays inside it and is withdrawn when it does not, which makes stopping the agent something computed continuously and in advance rather than reacted to; and it generalises the shape — take an asset, define a scarcity of use, allow a buffer of activity around it, and distribute that usage across a number of players — noting that money is simply the instance of this everybody already recognises as insurance.** It is the first document of 1 September (cross-ref: v0.33.71–82, doctrine 01's aggregation problem, doctrine 07's operating licence, doctrine 08's missing primitive, GM-D78's collision). New contributions: **consumption as a second axis beside capability, the pool as the first real pooling mechanism in the pivot, and the first loss data the estate can actually obtain.**

## The Memo, Verbatim

*Transcribed by otter.ai; carried whole, exactly as received.*

> So, on the topic of insurance, and getting insurance for AI agents, and mapping it out, and answering the question: Can isn't what is insurable for an engine, and what is not. What one of the very interesting concepts here is the idea of distributing resources and the idea that ultimately, if you think about it, an insurance policy is a buffer, right? It's a buffer that allows a certain degree of variability, right? So, the analogy that I would like to use here is: take, for example, an AI agent that does a specific action that requires a number of tokens. So, could we have equivalent of an agent broker that, for a range of agents or a number of agents executions provides an equivalent of an agent, sorry, an insurance policy, which is going to offset some of the extremes up to a point. So, so the analogy here is that let's say that we have a number of agents that consume, on average, 20k, 30k tokens, right? But there are some cases where they need more, right? There are some cases that they need to be able to consume more, up to a certain amount, right? And the interesting point here is that it's not that we don't want that, but we don't want that done across the board. So it's kind of like it's okay to have one out of 100 to have a spike, but it's not okay to have 100 having the spike, and that's where I think the insurance concepts, especially the approach we're taking, and the architecture we're taking, and the and what's it called the the sort of the architecture, yeah, we're building, would actually be quite interesting because we, in this case, is let's say that we have equivalent of an insurance policy that underwrites a million tokens, right? So that means that an agent, you know, gets a policy that says if you operate under these premises, and if you do this, and if you do that, then you have a licence to operate, and that licence to operate then gives you this buffer when you need it, right? So in a way, we are offsetting. We're using the insurance ability to offset the you know the cost, but the logic would be that if you know suddenly over a period of time you run out of those tokens, i.e. that cost is to a certain point, then you don't have a licence to operate, and you have to stop. So, so what's interesting about this concept is that then it starts to solve a lot of interesting problems because it defines what the agent can do, defines the areas of operation that the agent has, it defines the the way to stop it, which becomes that mandate, it defines in a way the grant, which is the ability of the agent to generate 10s of tokens, and this is just that. So you can basically start looking at the resources that the agent will consume. You create a pool for them, and you say, as long as you're operating within this pool, you have a licence to operate. And if you don't, then you remove that licence because you have to pull the plug, right? And the cool thing of this is, you can do this beforehand. You can do this, you know, before anything happened, or as something happens, because now you're controlling almost the resources being used, and it's actually quite interesting because you could apply this to almost anything, right? Because what we're doing here is that we're creating an as we're taking an asset, we're defining a level of scarcity of use of that asset, and then we are allowing a certain buffer of activity around that asset to exist, and and then the. then, the yeah, and then and then the usage of that, you know, asset or resource gets gets basically distributed across a number of players. So, so you you know, of course, you can do this with financial things. You can say this is your budget, right? So then you can have a budget. So you could also do this with money, right? Which is fundamentally what insurance is. In basic insurance, is saying if you can cause a bunch of damage, here's the cover, right? And what we're applying is we're almost applying the insurance concept to usage to define a, you know, and view those side effects as assets to manage.

One probable transcription artefact, flagged rather than repaired: the opening *"Can isn't what is insurable for an engine"* is most likely **can we say what is insurable for an agent**, and *"the ability of the agent to generate 10s of tokens"* is **tens of thousands**, consistent with the 20–30k band named two sentences later. Neither repair changes the argument.

## The Reading — the site agent's, from here down

### 1 · Yes. And the opportunity is not the one the memo leads with

**The answer to the question asked is yes**, and I want to be precise about *where* the value is, because the memo names three things and they are not equally strong.

| The memo's claim | My reading |
|---|---|
| A pool bounds what an agent consumes, with a buffer for legitimate spikes | **Right, and buildable now** |
| The pool "defines in a way the grant" | **Wrong, and the error matters** — §3 |
| Applies to almost anything | **Right, inside a boundary the memo does not draw** — §7 |

But none of those is the largest thing here. **The pivot has been arguing about insurance for eleven memos with no loss data, no claim shape, and no pooling.** This memo supplies all three at once, in a currency that is not money, from meters that already exist and that nobody here has to build.

> **Eleven memos in, this is the first one that makes the estate's own claims testable rather than better argued.**

### 2 · Consumption is a second axis, and the corpus only had one

Everything in this corpus rates **capability**: what can the agent reach. The grant is discovered by measurement, the mandate bounds it, the delta between them is the insurable interest.

**Consumption is orthogonal to all of it.** Two placements with byte-identical grant trees can differ by two orders of magnitude in what they burn, and nothing the estate measures would see the difference.

And it introduces a kind of node the grant tree has never had:

> **A token budget is a grant that depletes.**

Every grant in this corpus is *static*. A credential reaching forty repositories reaches forty tomorrow; exercising it does not shrink it; `measure.py` discovers a floor that stays put. **A resource pool is consumed by its own exercise**, which means it has a *remaining* — a quantity no node in the existing tree has, and one that changes without anybody re-measuring.

That is a fourth primitive beside grant, mandate and fact, not a re-description of any of them.

### 3 · A budget bounds volume, never reach — and conflating them would be the memo's one real error

The memo says the pool *"defines what the agent can do... defines in a way the grant."* **It does not, and this is the correction the memo most needs.**

> **The cheapest catastrophic action is cheap.**

An agent with a million-token licence and read-write on a repository can destroy that repository for a few hundred tokens. A runaway loop that burns the entire pool may do no damage at all. So:

| | Expensive | Cheap |
|---|---|---|
| **Harmless** | A runaway summarisation loop — **the budget catches it** | Normal operation |
| **Catastrophic** | A long destructive session | `rm -rf`, one force-push, one visibility flip — **the budget is blind** |

**The budget catches the top-left and cannot see the bottom-right**, and the bottom-right is what the entire rest of this corpus exists to address. A pool is a *complement* to the grant–mandate delta, and reading it as a replacement would substitute a spend limit for a blast radius.

The honest statement of what it does: **a pool bounds how much an agent does. The mandate bounds what.** Both are needed and neither implies the other.

### 4 · The pool is the first mechanism here that does what insurance actually does

Everything so far — levels, gates, derivations — is **underwriting**. Assessment. That is one half of insurance and the pivot has never had the other half, because [doctrine 00](../insurance/what-this-is.html) removed the money and pooling appeared to go with it.

**It does not.** Pooling is variance absorption across a population, and money is only its commonest denomination.

> **A token pool is risk pooling in a currency that is not money** — so it needs no carrier, no capital and no authorisation, and it is still structurally the thing insurance does.

And the memo's own sentence is the underwriting problem stated exactly:

> *it's okay to have one out of 100 to have a spike, but it's not okay to have 100 having the spike*

**That is correlated risk, named in one line.** It is [doctrine 01 §5](../insurance/the-rating.html) — *micro risks do not add* — arriving with a concrete instance for the first time. The rule was recorded there as *"stated here as a rule and is **not implemented**."* Consumption is what would implement it: a per-placement time series, from which correlation between placements is directly computable.

**Agent spikes would correlate**, and for reasons the graph already models: a shared prompt template, a shared model version, a shared triggering event, a shared upstream failure that sends every agent into the same retry. A pool sized for one-in-a-hundred and hit by a hundred is a pool that fails on the day it is needed.

### 5 · This is the loss data the pivot does not have

[Doctrine 08](../insurance/the-world-model.html) records the gap plainly: the claim is *"a statement — `loss-event/v0`, still undrafted, and **the one primitive the whole pivot lacks**."*

**A budget overage is a loss event.** It is dated, quantified, attributable to a placement, and — the part that matters — **already recorded, by somebody else, for billing.**

| What a claim needs | Where it is |
|---|---|
| An event that happened | The overage |
| A quantity | Tokens, exact |
| A date | The meter's |
| An insured | The placement |
| An independent record | **The supplier's invoice** |

> **`loss-event/v0` can now be drafted against a real instance instead of an imagined one**, which is the difference between a schema and a guess.

The estate has said since memo 1 that no agent loss data exists anywhere. **That is true of financial loss and false of consumption**, and consumption is loss data in a currency the estate can observe without asking anybody's permission.

### 6 · Three things this unblocks that were stuck

**GM-D78's collision, resolved.** [Doctrine 10](../insurance/the-schemas-and-the-clocks.html) recorded that a usage-boxed policy *"needs an in-line counter, which this project is not"*, and I filed the collision as the finding. **The counter exists and somebody else already runs it**, because every token is metered for billing whether or not anybody insures anything. Reading a meter that exists for commercial reasons violates nothing: we are not in the line, we are reading the invoice.

**Doctrine 07's first mover, found.** [Doctrine 07 §7](../insurance/the-policy-as-a-statement.html): *"The hard part is not the mechanism, it is who checks first. The handshake needs a relying party with a reason to refuse, and no external platform has one today."*

> **The resource supplier has a reason to refuse: it is paying.**

That is the first natural first mover in eleven memos. Every other candidate relying party had to be argued into caring.

**And the tier is easier here than anywhere else.** [Doctrine 05](../insurance/not-in-line.html) established that this project can never itself be a boundary, and doctrine 07 found one only under a condition — a relying party genuinely independent of the requester. **A meter has a natural home outside the agent: the party that supplies the resource is by construction not the party consuming it.** Where the supplier enforces the limit, the agent cannot reach the accounting, and the tier is `boundary` without anybody arranging independence.

**With the condition stated**, because the tier is always a property of the relationship: a budget the agent tracks in its own config is a `setting`, and a warning email at 80% is an `expectation`. **Same policy, three tiers, decided entirely by who holds the meter.**

### 7 · The generalisation is right, and it has a boundary the memo does not draw

*You could apply this to almost anything* is correct, and the abstract shape the memo gives is good: **an asset, a defined scarcity of its use, a buffer of activity around it, and that usage distributed across players.**

Compute-seconds, API calls, egress bytes, storage, and — as the memo says — money, which is the instance everyone already calls insurance. But *almost anything* is the phrase that goes wrong at the fifth application, so:

> **The shape applies to a resource that is metered by somebody who is not the consumer, fungible, and depleting.** All three, or it is not a pool.

| | Tokens | Repository write access |
|---|---|---|
| Metered by a non-consumer | Yes — the supplier bills it | No |
| Fungible | Yes — one token is any token | **No.** Access to the release repository is not access to a scratch repository |
| Depleting | Yes | **No.** Using it does not consume it |

**Capability fails two of three**, which is why the grant tree needed different machinery, and why §3's separation is structural rather than fussy.

### 8 · The series was called complete twice, and the gate caught the second

The [audit](v0.33.82__audit-brief__the-eleven-readings-audited-against-their-transcripts.md) found doctrine 08 twice calling memo 8 the last of the series, and built a gate: only the highest-numbered memo may be called the last.

**Filing this memo fired it**, on doctrine 10's *"memo 10 — the last of the series"* — written by me, four releases ago, about a series I had just watched grow from eight.

> **The gate has now caught the same error in two documents written by two sessions, one of which had just finished writing the gate's own justification.**

The lesson is not that the series keeps growing. It is that **a document should not assert the future**, and *the last of the series* is an assertion about memos not yet recorded. Doctrine 10 now says what it can know — that it is the eleventh document, derived from memo 10 — and the gate stands.

### 9 · The hazards, which are sharper here than anywhere else in the pivot

**Classical moral hazard arrives, for the first time.** [Doctrine 02](../insurance/the-ecosystem-and-the-gate.html), as corrected at v0.33.82, says stage 1 escapes the payout channel of moral hazard because there is no payout. **A pool is a payout.** An agent covered by a buffer has less reason to be efficient, which is precisely what deductibles exist for — and the memo's own structure already contains one.

**Correlated exhaustion is a denial of service you perform on yourself.** If one runaway drains the pool, *every* member loses its licence, including the ninety-nine that behaved. That is [doctrine 06's](../insurance/the-broker-market.html) shared-fate problem with a much shorter fuse.

> **A pool without a per-member draw limit converts one misbehaving agent into an outage for all of them.**

Insurance solved this centuries ago and the vocabulary transfers exactly:

| Insurance | Here | The memo's own words |
|---|---|---|
| **Deductible / excess** | The agent's own budget, spent first | *on average, 20k, 30k tokens* |
| **Limit per occurrence** | Most any one agent may draw in one spike | *up to a certain amount* |
| **Aggregate limit** | The pool | *underwrites a million tokens* |
| **Attachment point** | Where the pool starts paying | *gives you this buffer when you need it* |

**The memo has described an excess-of-loss treaty**, which is a structure with three centuries of practice behind it — and the per-occurrence limit is the one component it does not name and the one that stops §9's outage.

**And the currency becomes worth gaming.** Stage 1's quasi-currency was points nobody wanted. **Tokens are a currency agents' operators actively want**, so if a better level buys a larger allocation, the incentive to declare favourably stops being theoretical. [Doctrine 00's](../insurance/what-this-is.html) *a level is never declared, only derived* stops being hygiene and becomes the control that holds the whole thing up — and the [two-channel rule](../insurance/the-rating.html) becomes an anti-fraud mechanism, the same upgrade GM-D73 made for non-disclosure.

### 10 · What this is not: rate limiting

Worth saying because it is the first objection anyone will raise. Every platform already caps consumption.

**A rate limit is a per-agent ceiling set by somebody who cannot distinguish a legitimate spike from a runaway** — so it is set low enough to be safe and therefore low enough to kill the one-in-a-hundred case the memo is explicitly protecting.

> **The pool is what a rate limit cannot be: permissive per agent and bounded in aggregate.** The buffer is the entire product.

## Decisions This Implies (proposed into change control)

| # | Decision | Status |
|---|---|---|
| GM-D86 | **Consumption is a second axis beside capability**, and a resource pool is a **fourth primitive** beside grant, mandate and fact — *a grant that depletes*, carrying a `remaining` no existing node has | Proposed |
| GM-D87 | **A pool bounds volume, never reach.** The cheapest catastrophic action is cheap; a budget catches the expensive-and-harmless case and is blind to the cheap-and-catastrophic one | Proposed — **corrects the memo**, which says the pool defines the grant |
| GM-D88 | **A token pool is risk pooling in a currency that is not money** — variance absorption across a population, needing no carrier, capital or authorisation. The first mechanism in this pivot that does what insurance does rather than what underwriting does | Proposed |
| GM-D89 | **Consumption is the loss data this estate can actually obtain.** A budget overage is dated, quantified, attributable and independently recorded, so `loss-event/v0` is drafted against a real instance | Proposed — **answers GM-D36's undrafted shape and doctrine 08's missing primitive** |
| GM-D90 | **The counter already exists, so GM-D78's collision dissolves.** Every token is metered for billing regardless; reading a meter somebody else runs for commercial reasons does not put this project in the line | Proposed — **resolves GM-D78** |
| GM-D91 | **The resource supplier is the first natural relying party**, because it is the one paying — the first candidate in eleven memos that did not have to be argued into caring | Proposed — answers doctrine 07 §7 |
| GM-D92 | **A metered budget is the only warranty that cannot fail the unknown way.** GM-D76's three failures are false, stale and unknown; a meter is authoritative and continuous, so `remaining > 0` fails one way only | Proposed |
| GM-D93 | **A pool without a per-occurrence limit converts one runaway into an outage for every member.** The structure is excess-of-loss: deductible, per-occurrence limit, aggregate — and the memo names three of the four | Proposed — **the missing component is the one that prevents shared-fate failure** |
| GM-D94 | **The shape generalises only to a resource that is metered by a non-consumer, fungible, and depleting.** Capability fails two of three | Proposed — bounds *you could apply this to almost anything* |
| GM-D95 | **A desirable currency makes *never declared, only derived* load-bearing.** Tokens are wanted in a way points are not, so the two-channel rule becomes an anti-fraud control | Proposed — the same upgrade GM-D73 made for non-disclosure |

## Open Questions, The Project Lead's

1. **Is the pool the MVP?** It competes with N23's world model and N24's survey, and it is the only one of the three that produces **data** rather than an explanation or an observation. It is also the only one that could be run against this estate's own consumption this week.
2. **What is the per-occurrence limit?** §9 says the structure needs one and the memo does not name it. It is the number that decides whether a pool degrades gracefully or fails all at once.
3. **Who holds the pool?** The memo says *agent broker*. Under GM-D91 the natural holder is the resource supplier; under [doctrine 06](../insurance/the-broker-market.html) it could be an execution broker; under [doctrine 05](../insurance/not-in-line.html) it is not us. **The answer decides whether this is a product, a schema, or a demonstration.**
4. **Does a licence withdrawal stop the agent, or refuse the next request?** The distinction is doctrine 03's tier question and it is unsettled — as is memo 10's still-open *voids, suspends, or downgrades*.

---

*CC BY 4.0. Sources: the project lead's voice memo of 1 September 2026, eleventh of the series (verbatim above); v0.33.71–82; doctrine 01, 02, 05, 06, 07, 08 and 10, each re-read for the quotations above rather than recalled. Everything below the transcript is the site agent's reading and says so — including §3, which corrects the memo, and §8, which records the gate firing on a document I wrote.*