three boundaries, three questions

K-12 asks what must surround one bounded agent episode: its memory, tools, ledger, capabilities, randomness, quota, policy, locale and identity. Its specification states seven laws, including audit before mutation and capability validation. Its own idempotency note limits “exactly once” language to a configured retry horizon.

G-9 asks how many episodes can coordinate without losing types, order or replayability. A graph is more than nodes on a screen: edges have input and output contracts, joins declare what counts as complete, and a scheduler cannot execute behavior absent from the graph description.

M-7 asks what changes when agents act for different organizations. Discovery, attestation, contracting, metering, settlement, dispute and reputation become explicit ports. The spec is a research and design artifact, not evidence of a live clearing market.

The August 2025 preprint consolidates the trio. The later Lean files formalize parts of it; the March 2026 retrospective is unusually candid about what compiles, what is proved and what remains a sorry or an axiom statement. The rendered books cover the same territory at far greater length and remain private while being revised.

start with one act

Suppose an agent is asked to correct a customer record. What identity does it act under? Which record may it read? Which fields may it change? How much can it spend or retry? How will anyone reconstruct the attempt afterward? These are the K-12 questions. A prompt can describe the job, but the boundary has to live in the runtime. Otherwise a sensible answer can still produce an unauthorized act.

An episode needs a trace before mutation because an audit trail assembled after the fact cannot tell you which permission existed at the time. It needs an idempotency rule because a retry is normal in distributed work. It needs a quota because a bounded instruction can still loop or fan out. And it needs a way to stop when the input falls outside the original contract. The point is not to make every act ceremonial. It is to let routine acts proceed without an owner standing over them, while making the boundary visible when something unusual happens.

coordination changes the unit of failure

Now imagine one agent collects evidence, another drafts a decision, and a third applies it. The safety of each episode does not guarantee the safety of the chain. The drafter may see stale evidence. A join may fire before the needed approval arrives. A scheduler may retry a step after the external system accepted the previous call. G-9 puts types on the graph’s inputs, outputs and joins so the sequence is inspectable.

This is where pretty diagrams can mislead. A line between boxes says little about what the downstream actor is allowed to infer. It matters whether an upstream result is a proposal, an accepted decision, or an observation from outside the company. If the edge carries only text, the downstream agent has to guess. A typed edge can make that distinction part of execution.

exchange adds institutions

M-7 begins when the actors no longer share an owner. One company can offer a capability; another can buy it. They need an offer, attested identity, a contract, a meter, a settlement rule, a dispute path and some way to update trust. A successful API response proves none of those by itself. The buyer can receive a technically valid artifact that violates the service promise. The seller can perform useful work that the buyer never authorized. Both cases need an account of what was agreed and what happened.

K-12, G-9 and M-7 are best read as changes in boundary, not as three brand names for one stack. If a single act fails, repair its local contract. If many acts drift, inspect the graph. If two organizations disagree, inspect the agreement and the evidence attached to it. That diagnostic is more useful than adding another coordinator to every problem.

The papers and specifications go much deeper than this page. They also differ in maturity. Read the contracts for the questions they force you to ask; inspect the formal files if the exact scope of a theorem matters to your design.

what to do with the contracts

These boundaries are useful during architecture review even if a team never adopts the named kernels. Draw one recent failure on three lines. On the first, list the actor’s identity, tools, permissions, budget and stopping rule. On the second, draw the actors and the typed thing each passes onward. On the third, name every outside organization and the agreement by which it participates.

A surprising number of “model failures” are actually missing entries on one of those lines. An agent had the right answer but the wrong permission. A graph passed a draft where the next node expected an approval. A vendor delivered an output with no shared rule for acceptance. Better reasoning might make these failures less frequent, but it cannot define an absent contract.

The contracts can also show where less machinery is enough. If one person and one bounded agent can close the episode with a clear receipt, a graph kernel may add no value. If the work never crosses a company boundary, market settlement is irrelevant. The point of the trilogy is to expose the boundary as it changes, so design effort follows the actual risk.