.ai

How the record works

The scheme

The mechanics under everything: four primitives, kinds that never change, identities that explain themselves, cards agents read instead of content, and a record that checks itself.

Four primitives: source, node, version, act

Everything stored is a source, a node, a version or an act. The last three borrow Git’s model as concepts: fixed snapshots, a moving pointer, an append-only chain.

  1. Source

    An input captured from outside — a paper, a page, a chat, a dataset.

    Identified by
    sha256 of its bytes
    Changes
    never
    In Git
    none — it stays outside

    Evidence must stay citable byte for byte, whatever we later write about it.

  2. Node

    A thing's permanent identity. One permanent kind, one current version.

    Identified by
    a minted, time-ordered identity
    Changes
    only its pointer — and only by an act
    In Git
    a branch

    Everyone refers to the node, so a new version never breaks a reference.

  3. Version

    A node's content at one moment, together with its card.

    Identified by
    sha256 of content and card together
    Changes
    never
    In Git
    a blob

    A pinned reference means exactly the bytes it meant, forever.

  4. Act

    The record of a change: what moved, from which version to which, who, when, why, on what grounds.

    Identified by
    a minted identity, chained to its parents by digest
    Changes
    never — append-only
    In Git
    a commit

    History is a chain anyone can verify, not a log anyone can edit.

One change, four primitivesAn act moves a node's pointer from version one to version two. Version one is kept. The act cites a source as its grounds and is chained to its parent act by digest.act · parentactnodev1 · sha256:3b1e…v2 · sha256:c8a0…source · sha256:9f2c…parentmovespoints togrounds
An act moves one pointer. Nothing it touches is rewritten — v1 stays retrievable by its digest.

Sources stand apart because outside evidence must stay citable byte for byte, whatever anyone later writes about it. The other three are Git’s ideas, separated: content that never changes, a name that points at the current content, and a causal history of every move.

Concurrent changes never overwrite each other. Two acts that move one node from the same version leave it with two causal heads: the node is contested, readers get one deterministic value plus a contested flag, and a merge act resolves it. Versions and acts append without coordination; only a node’s pointer is coordinated, per node or per namespace — never globally.

Git, mapped onto the scheme

The scheme borrows Git’s model, not Git’s commands. Every Git idea has a counterpart, and a few Git operations deliberately have none.

GitThe scheme
bloba version
treea view’s result — computed and pinned, never authored
commit and its parentsan act and its parent acts
branch / maina node’s pointer / its accepted line
other branchesdrafts and competing versions
mergeacceptance
tagapproved, accepted, released
fork / pull requestan agent’s isolated workspace / review before merge
log, blamea node’s history; the provenance of its parts
reverta correction, as a new act
unreachable objectsthe archive — never collected
squash, rebase, force-pushnothing. History is never rewritten.

Four classes of node

Authored content, the relations within it, the queries that list it, and one task’s working set. Each is a node, named, versioned and checked the same way.

  1. 01 · class

    Unit

    Anything referred to, graded, attacked or replaced on its own is a unit.

    Authored content — a document, or a part of one. A part is its own file.

    topcstmtquesnote

  2. 02 · class

    Edge

    A relation that can be wrong deserves an identity.

    A named relation stored as a node: from, to, why it holds, and its attributes.

    dpndgrndrltd

  3. 03 · class

    View

    If it lists things, it is computed.

    A declarative query over the graph. Its result is a real subgraph, pinned to what it showed.

    view

  4. 04 · class

    Context

    A task reads what it pinned, at the version it pinned.

    A task's working set: the question, plus a bounded list of nodes pinned to versions.

    ctxt

Granularity follows use, not formatting. If a paragraph is cited, contested or replaced on its own, it is its own unit in its own file — and a document is reassembled by a view. If it is only ever read as part of something larger, it stays inside it.

An agent’s attention is a declared, auditable object. It widens only by an act.

A kind is permanent. Nothing is promoted.

Every kind has a registered short code that leads each identity of that kind. A kind never changes: when a question is answered, the answer is a new node.

Unit

  • topc topic a subject that groups what sits beneath it
  • stmt statement one assertion: a decision, rule, definition or finding
  • ques question asked and not answered, with the options weighed
  • note note distilled research or an evidence survey

Edge

  • dpnd depends on relies on; critical caps the dependent's confidence
  • grnd grounded by rests on a source, at a stated locator
  • rltd related a typed association, such as proposed answer to

View

  • view view a saved query plus its rendering: list or document

Context

  • ctxt context a pinned working set for one task

Act

  • act act the record of a change

ques-…-r2m5bhbecomesstmt-…-r2m5bha kind never changes

stmt-…-p7d0sarelated · proposed answer toques-…-r2m5bhboth stay what they are

Permanence is what makes a reference type-checkable: a dependency on a stmt-… can be checked the way a compiler checks an argument, because the thing behind it is a statement for as long as it exists. A question that gets answered stays a question; the answer is a new statement, linked to it. So the record can always show both what was asked and what was decided.

Adding a kind is a content change, not a software release. A new kind is registered within the scheme and never brings its own mechanism.

Why codes, and when a kind is really a relation

A registered code makes every identity self-describing and prevents the classic collision of two record types sharing a prefix. The registry stays small by one rule: a would-be kind that differs from its neighbour only by a relation is a relation, not a kind.

Layers built on the scheme register their kinds the same way. The software lifecycle adds briefs, yields, waivers, leases and acceptances — each a registered code, none with a mechanism of its own.

An identity that explains itself

Kind, time, randomness, handle. Each part of a minted identity buys something specific — and no part of it is chosen by judgement.

stmt-01m4bnj7a2-1ec4ybkmh0-w4c9yg

  1. stmt

    What it is

    A registered code of three to five characters. A reference says what it points at before anyone opens it, and a reference can be type-checked like an argument.

    stmt = statement

  2. 01m4bnj7a2

    When it was minted

    48 bits of milliseconds. Identities sort by creation for free, and an auditor gets an append order to check. An identity never sorts before anything its minting act read.

    1791393078594 ms
    = 7 Oct 2026, 17:11:18 UTC

  3. 1ec4ybkmh0

    Why nobody coordinates

    With the handle, 80 random bits per millisecond. Tools mint anywhere, in parallel, for any number of agents, with no central counter to be down or to race on.

    280 ≈ 1.2 × 1024 per millisecond

  4. w4c9yg

    What you type

    The last six characters. A tool resolves a handle against context and returns the ambiguity set — never a guess.

    in prose: stmt-w4c9yg

Why six characters

HandleAmbiguous at 100,000 things
c9yg 4 chars9.1%
4c9yg 5 chars0.30%
w4c9yg 6 chars0.0093%
0w4c9yg 7 chars0.00029%
h0w4c9yg 8 chars0.0000091%

The chance that one handle matches at least one other among 100,000 identities. A tool resolves it against context, and returns every match rather than choosing one.

Crockford base32, lowercase

0123456789abcdefghijklmnopqrstuvwxyz

No i, l, o or u: an identity survives being read aloud and retyped. Lowercase only, so a case-insensitive filesystem can never fold two identities into one.

An example identity, decoded. Bars are ones, ticks are zeros.

Minting is always a tool act, so no agent can pick an identity that pre-empts another. Measured on AI agents: asked to name things independently, parallel agents collide, because their choices are correlated.

Why not a counter, a custom format or a meaningful name

A central counter would make uniqueness depend on one system being up, and would couple every parallel agent through it. A shortened custom format would be a parser, a specification and a bug class to own forever. ULID is a published standard; the scheme only changes how it is written — lowercase, in three segments, behind a kind code.

Meaningful identifiers are the mistake every mature system has learned to avoid. Library classifications that encoded meaning in numbers could not keep pace with knowledge; large knowledge bases learned never to reuse an identifier, and to turn merges into redirects. A merged or split node’s identity is archived and redirects. It is never reused.

Native names first

A thing that already has a unique, stable name keeps it. The scheme mints identities only for what it creates, so nothing has two answers to which thing this is.

A repository’s host/org/name, a package, a command, an MCP tool, a kind, a term — each already has a name that is unique within a stated namespace. Inventing a second name for any of them creates two answers to “which thing is this?”, and reconciling two answers never ends.

So the scheme refers to them by the name they have, qualified by its namespace, and mints only for the things it makes. Either way, every stored reference carries a digest of what it meant.

A unique, stable name is already an identity.

Versions are addressed by what they contain

A version’s identity is the digest of its content and card. A record never contains its own digest, and every reference pins the exact version it relied on.

Inside the digest

content + card sha256:c8a0…

Outside — in the act

who · when · why · what it replaced · what it relied on · the digest itself · any signature

A structure cannot contain its own hash — exactly why a Git object does not contain its own SHA. The digest is the address, computed by whoever holds the bytes. Facts about a version live in the act that made it; put inside the version, they would change the very digest they describe. A signature, likewise, lives outside what it signs.

Every relation and every act records the exact digests it relied on. So “what did this conclusion rest on?” always has an exact answer, and a later change to a premise is detectable rather than invisible.

Algorithms, canonical forms and sources

Digests are written with their algorithm (sha256:…), so an algorithm can be retired later without ambiguity. A source’s identity is the digest of its raw bytes; where it came from and when are metadata about it. The lifecycle layer specifies deterministic CBOR as the canonical form, so the same meaning always hashes the same.

Paths derive from identity, so nothing moves

A file’s location is computed from its identity alone: kind, then two levels of time. No topic ever appears in a path, so reorganizing knowledge never moves a file.

  1. stmt/kind codeone folder per kind
  2. 01m/time chars 1–3≈ 1.1 years · Aug 2026 – Sep 2027
  3. 4/time char 4≈ 12.4 days · 3 Oct 2026 – 15 Oct 2026
  4. stmt-01m4bnj7a2-1ec4ybkmh0-w4c9yg.mdthe full identitythe file always shows the current version
Versions
versions/sha256-hex no extension, so a note editor never mistakes one for a note
Sources
sources/sha256-hex the digest of the raw bytes
The path of the example identity, derived from the identity alone. Nothing in it is a topic.

Reorganizing knowledge is a change to views and relations, never a file move. A link keeps resolving however the knowledge is regrouped, because nothing about a thing’s subject, status or owner is encoded where it sits.

The identity’s time segment doubles as a free shard key.

The card: what an agent reads instead

Every version carries a short, flat, typed card whose text fields have word budgets. Agents navigate by cards and open content only for the task in hand.

An example card
id
stmt-01m4bnj7a2-1ec4ybkmh0-w4c9yg
title
Erasure completes within thirty days
5 / 10 words
summary
A verified erasure request removes the person's data from every store, backups included, within thirty days of verification.
18 / 30 words
level
1 of 0–3 · the reader it is written for
covers
  • which stores an erasure reaches 5/15
  • when the thirty-day limit starts 5/15
  • how backups are handled 4/15
3 / 7 items
excludes
  • how long data is kept before anyone asks 8/15
1 / 7 items
asserts — its contract
  • erasure completes within thirty days of verification 7/15
  • backups are included in every erasure 6/15
  • the limit starts when the request is verified 8/15
3 / 7 items
part_of
topc-…-t3k04t Data retention its one upward reference
rank
80 sparse order among siblings
sensitivity
0 public · of 0 public – 4 secret

Deliberately off the card

  • kindthe identity's prefix
  • who · when · whythe act that made the version
  • statederived from acts
  • pinsrecorded by the tool, in the act
  • confidence · gradesrecords made by others
  • children · backlinkscomputed by views
  • stalenesscomputed by views

Each is derived, or recorded elsewhere. A stored copy could disagree with its source — silently — and tools would believe the copy.

Measured on AI agents: accuracy degrades when what matters sits in the middle of a long context, and retrieval is rarely the bottleneck — reading is. What works for them is a small index read up front and navigation on demand, with titles and one-line summaries as the scent. A newcomer to a project meets the same limit: nobody reads everything before starting. Cards make that pattern mandatory for every agent, and the check makes it measurable.

Agents read cards, not content.

Why flat, typed and quoted

Cards are flat because nesting breaks ordinary Markdown tooling; Obsidian, for one, does not support nested properties. Every property name has one type everywhere, so a query never has to guess. Links are quoted, and live only in link fields, so a tool can find every reference without parsing prose. asserts is the card’s contract: the claims a dependent may rely on, and the part of a change that makes judgement climb.

References point up. Every list is a view.

A record holds only its own foreign keys. Children, backlinks and outlines are computed, never stored — so adding a leaf never rewrites a parent.

If a parent listed its children4 writes
rootaba1a2xnew

Every reference is pinned by digest, so each ancestor needs a new version — up to the root, for every leaf.

Children point up — the scheme1 write
viewrootaba1a2xnew

The new leaf holds its own part_of. No parent changes. The list of a1's children is a view, computed on demand.

Versions are immutable and references are pinned, so a parent that listed its children would cascade a new version up every ancestor for every change below it. The scheme turns that around. A unit holds one part_of; an edge holds its from and to; nothing lists what points at it.

A document, then, is its content plus a view: its parts find each other by part_of and order themselves by a sparse rank. “What does this contain?”, “what attacks this?” and “what was built on this?” are all queries.

Edges are nodes, and staleness is mechanical

A relation has its own identity, card and history; its act pins both ends. When a pinned version is superseded, a tool flags everything that relied on it.

A bare link can only exist or not. A relation stored as a node can say why it holds, be graded, be attacked (“this dependency is not real”), and be superseded — and the act that created it pinned the exact versions on both ends.

id        dpnd-…-e8f6tc
title     Retention rests on the erasure policy
critical  true           # the premise caps the dependent's confidence
from      stmt-…-p7d0sa  # events are retained for thirteen months
to        stmt-…-w4c9yg  # erasure completes within thirty days
pinned    sha256:a07d…   # by the act, not the card

When stmt-…-w4c9yg gets a new version, the edge’s pin no longer matches — and the flag travels:

  1. 01 act

    Superseded

    A premise gets a new version. Its old version is kept, by digest.

  2. 02 tool

    Mismatch

    Every edge, view and context that pinned the old digest no longer matches the current one.

  3. 03 tool

    Flagged

    Each of them is flagged stale — mechanically, at once, with nothing left to anyone's memory.

  4. 04 agent

    Assessed

    Did the meaning change? One declared answer, checked by a second agent.

    no impactrefinesextendscontradictsinvalidates

Only contract changes climb. A new title re-renders views; a change to asserts, covers, excludes or an edge asks for judgement upward. If a change touches nothing a parent quotes, a tool records no impact and stops without asking an agent. A change stops rising exactly where it stops mattering.

Edge kinds and their attributes
EdgeReads asAttribute
depends onthis relies on thatcritical
grounded bythis rests on that sourcelocator — where in the source
relatedthis bears on thatthe relation’s type
attacksthis challenges thattarget — premise, conclusion or inference
supportsthis argues for that—
definesthis fixes the meaning of that—
presentsthis rendering shows that versionlevel

The three attack targets are argumentation theory’s distinction between undermining, rebutting and undercutting. Staleness is mechanical for every edge; the assessment that follows is a judgement with exactly five declared answers.

Metadata on everything — including the metadata

A field is defined once, as its own document. Kinds reference the fields they use. The scheme’s own vocabulary is stored and governed exactly like its content.

Field defined oncetopcstmtquesdpndgrndrltd
title●●●●●●
summary●●●●●●
level●●●not usednot usednot used
part_of●●●not usednot usednot used
rank●●●not usednot usednot used
coversnot used●not usednot usednot usednot used
excludesnot used●not usednot usednot usednot used
assertsnot used●not usednot usednot usednot used
from · tonot usednot usednot used●●●
criticalnot usednot usednot used●not usednot used
locatornot usednot usednot usednot used●not used
Each field is defined once; each kind references the fields it uses. Usage shown for an example set of kinds.
A term, described — an example

statement

Alternate labels
assertion · proposition
Broader
unit
Definition
A unit that makes one assertion, small enough to be accepted, contested or replaced on its own.
Scope note
Use for one decision, rule, definition or finding that can stand on its own.
Exclusion note
Not for something asked and unanswered — record that as a question.

A field described inside every kind that uses it has as many definitions as there are kinds, and they drift. So the scheme defines each field once, as its own document — meaning, value type, value rules — and a kind references it, stating for that kind whether it is mandatory and whether it repeats. That is the split DCTAP and RDFS make. Kinds and fields are the meta-metadata, and they live in the same store, under the same rules, as everything else.

Terms follow SKOS and ANSI/NISO Z39.19, with definitions in the ISO 1087 form: name the broader concept, then what distinguishes this one. Alternate labels are what stop an agent missing something that already exists. The exclusion note — what a term is not for — is what stops an agent filing a question as a statement.

Three written forms. State is a fold.

Only manifests, events and blobs are ever written, and none of them changes. Status, facts, summaries and indexes are derived — so every past state is a query.

  1. a declaration

    Manifest

    what something is, or must become

    Could have been written before the thing occurred.

    briefspecificationclaimwaiver

  2. an observation

    Event

    this happened, at this time — references, never payloads

    Could not have been written before.

    run startedlease expiredtest finished

  3. opaque content

    Blob

    too large or noisy to reason over

    No rule may conclude anything from its bytes.

    transcriptbuild logtest outputtrace

state(T) = fold(every record written at or before T)

Anything that happens after a manifest is written is a separate record that refers to it — an acceptance, a defeat, a supersession, a retirement — never a field edited onto it. An unfinished record is a draft, its own kind, and becomes a manifest only by passing strict validation. There is no half-valid record. Nothing is overwritten. Everything is superseded. shows what that buys.

A system that greps its logs to make decisions has made its logs load-bearing without making them checkable. Here, anything in a blob must first be extracted into a structured event by a pinned, deterministic parser before any rule may use it.

Where each form lives: four layers, one truth
  1. Projections

    rebuildable

    Knowledge indexes, current-state caches, generated views, RDF and JSON-LD exports — fast lookup and interchange.

    • Authoritative Never. Delete any of it and rebuild it from the layers below.
    • Scale whatever is useful
    • Addressed by query
  2. Authored text

    Plain Markdown with flat frontmatter, tracked in Git: the artifacts people read as prose, and the definitions of every kind, field and relation.

    • Authoritative Yes — the normative layer.
    • Scale thousands
    • Addressed by identity and path
  3. Operational history

    Git objects reachable by custom refs, never checked out: activity events, run chains, leases, bundle manifests.

    • Authoritative Yes — for what happened.
    • Scale millions
    • Addressed by identity
  4. Evidence

    Content-addressed blobs: transcripts, logs, traces, test output, bundle contents. No rule may read their bytes directly.

    • Authoritative Yes — by digest.
    • Scale billions
    • Addressed by digest only

Code stays where it already lives. Repositories are highly organized by their own conventions; the scheme refers to them by pinned reference and never copies or reorganizes them. Finding is a query, never a directory walk.

The scheme checks itself

One check refuses broken records and prints the organization debt as a number that must never rise. The scheme’s own vocabulary passes the same check.

$ checkrefuses
  1. a node changed without an act
  2. an edited act — the hash chain breaks
  3. a version not stored, or not matching its digest
  4. a wrong path, or an unregistered kind
  5. a nested, unknown, missing or mistyped card field
  6. a card over its word budget
  7. a link outside a link field, or a link to nothing
  8. a part_of or depends-on cycle

0 problemsorganization debt · n

Organization debt over commits: it may stay level or fall, and never rises. Its target is zero.nevertarget 0
Organization debt, commit by commit · schematic Tracked documents outside the store with no card — content that card-first reading and search cannot reach. Printed on every check. It may hold or fall; it must never rise.

The rule of work: zero problems before every commit. Existing debt is reported, not refused — refusing it would block all work. The check prints it as a number on every run, and an inventory lists exactly where it is.

A rule without a mechanical check does not hold.

The scheme applies to itself. Its kinds, fields and terms are its own nodes, stored and checked exactly like the content they describe. Its specification is a rendered view of those nodes, regenerated and never edited by hand. Anything the scheme cannot apply to itself is not one of its rules.

Paying the debt down

Debt is paid down in three steps. Stop the growth: new content enters only through the scheme’s acts. Make every uncarded document discoverable, by capturing it as a source with a mechanically drafted card. Then migrate the backlog by running the scheme’s own organizing process over it — judged by an agent that did not write the proposal, and accepted by the owner in batches.

Why a number: organization that depends on anyone remembering to organize falls behind content, silently. A number printed on every check cannot grow unseen. Even large, well-run wikis that forbid category cycles accumulate hundreds of them.

Search every section

Commands

  1. zOverview: every section on this pageview
  2. themeSwitch light or darkui

Sections

  1. ixn.aiixn.ai
  2. The schemeThe scheme
  3. The lifecycleThe lifecycle
  4. Agents and trustAgents and trust
  5. NorthstarsNorthstars
  6. Work outgrew the way we organize itixn.ai
  7. Seven storiesSeven stories
  8. Artifacts, not documentsixn.ai
  9. MethodMethod
  10. Agents judge. Tools do the mechanics.ixn.ai
  11. Work goes out as a brief and comes back as evidenceixn.ai
  12. GlossaryGlossary
  13. Nothing is overwritten. Everything is superseded.ixn.ai
  14. Four layers, one truthixn.ai
  15. Big work becomes small, checkable tasksixn.ai
  16. Values, given teethixn.ai
  17. Try it: you are the agentixn.ai
  18. One word, one meaningGlossary
  19. Identity and historyGlossary
  20. Records and relationsGlossary
  21. Work and bundlesGlossary
  22. Trust and authorityGlossary
  23. Process and weightGlossary
  24. Roles and judgementGlossary
  25. Invent as little as possibleMethod
  26. Narrow briefs, drawn boundaries, written as they goMethod
  27. Every claim carries its gradeMethod
  28. The case against every sourceMethod
  29. Correct the record in publicMethod
  30. One decision at a time, losers keptMethod
  31. Let worked cases force the decisionsMethod
  32. Review loops that know when to stopMethod
  33. State the limits as limitsMethod
  34. Standing on shouldersMethod
  35. No folklore numbersMethod
  36. How work moves through the systemSeven stories
  37. The command that lied about successSeven stories
  38. The plan that was wrongSeven stories
  39. No end in sightSeven stories
  40. Rolled back in ninety secondsSeven stories
  41. The rules change mid-flightSeven stories
  42. Most of what arrives is never builtSeven stories
  43. Autonomy is earnedSeven stories
  44. One cycle, at every levelThe lifecycle
  45. Five rules govern the graphThe lifecycle
  46. Accepting the specification is the commitmentThe lifecycle
  47. Gate where a mistake becomes uncorrectableThe lifecycle
  48. Gates are enforced, never requestedThe lifecycle
  49. The issuer accepts; the owner accepts what branchesThe lifecycle
  50. Oversight and capability run beside the workThe lifecycle
  51. Consequence decides what; size decides how hardThe lifecycle
  52. Err smallThe lifecycle
  53. Decompose until every leaf passes four testsThe lifecycle
  54. A budget is a fuse, not a decisionThe lifecycle
  55. The record is the processThe lifecycle
  56. Twelve lines worth keepingSeven stories
  57. Four primitives: source, node, version, actThe scheme
  58. Four classes of nodeThe scheme
  59. A kind is permanent. Nothing is promoted.The scheme
  60. An identity that explains itselfThe scheme
  61. Native names firstThe scheme
  62. Versions are addressed by what they containThe scheme
  63. Paths derive from identity, so nothing movesThe scheme
  64. The card: what an agent reads insteadThe scheme
  65. References point up. Every list is a view.The scheme
  66. Edges are nodes, and staleness is mechanicalThe scheme
  67. Metadata on everything — including the metadataThe scheme
  68. Three written forms. State is a fold.The scheme
  69. The scheme checks itselfThe scheme
  70. The unwritten rules of good work, written downNorthstars
  71. Honest reasoningNorthstars
  72. Trust that survives inspectionNorthstars
  73. Attention to the unexplainedNorthstars
  74. Care for the readerNorthstars
  75. Continuity of attentionNorthstars
  76. The good path is the easy pathNorthstars
  77. The dignity of boundariesNorthstars
  78. Reverence for the irreversibleNorthstars
  79. Minds decide, tools doNorthstars
  80. Intent before effortNorthstars
  81. A record that only growsNorthstars
  82. One answer, one shapeNorthstars
  83. Every mechanism is a value given teethNorthstars
  84. The brief is a sealed contractAgents and trust
  85. Least privilege is absence, enforced three timesAgents and trust
  86. Narrow the task, widen the readingAgents and trust
  87. The run: containment, not trustAgents and trust
  88. One signed manifest, or nothingAgents and trust
  89. Evidence is what the harness sawAgents and trust
  90. Judgements are declared choicesAgents and trust
  91. Nothing checks its own workAgents and trust
  92. Authority is a token the agent never holdsAgents and trust
  93. Sign only what agents must not alterAgents and trust
  94. One owner, one lease, one fencing tokenAgents and trust
  95. Cut at wide dependencies, and own every joinAgents and trust
  96. Drift and done are derived, never declaredAgents and trust
tool · agent · owner — each voice is who acts ↑↓ move ↵ open esc close