Shared Memory Mesh For Agent Fleets: Provenance, Retrieval Boundaries, Collision Rules

TL;DR

Shared memory across an agent fleet is a force multiplier when it works and a contagion vector when it does not. Three governance problems emerge that no single-agent architecture has to face. Provenance: knowing who wrote any given fact, when, with what authority, so downstream readers can weigh it. Retrieval boundaries: defining who can read what, because not every fact a fleet knows should be visible to every agent in the fleet. Collision rules: deciding what happens when two agents disagree about a fact, because in a real fleet they will. The architecture answer is a mesh governance charter that is part data model, part access control, part conflict resolution protocol. Without it, your shared memory becomes a shared cesspool. With it, the fleet is genuinely smarter than any single agent in it.

Why Shared Memory Is The Premise Of Real Multi-Agent Work

A single agent with private memory is bounded by what it has personally experienced. It learns from its own interactions, accumulates its own context, and reaches its own conclusions. This is fine, and for many use cases it is sufficient. But the moment you have multiple agents working in the same domain, on the same customers, against the same external systems, the bound becomes painful. Agent A learned this morning that the customer's preferred contact channel is email. Agent B is going to call the customer this afternoon, because Agent B never had the conversation Agent A had. Every interaction starts from zero for whichever agent picks it up next, and the customer experiences the fleet as a series of strangers who keep introducing themselves.

Shared memory solves this. A common substrate that all agents in the fleet can read from, and that some agents can write to, lets the fleet behave as a coherent organism. The customer's preferred contact channel gets written by Agent A and read by Agent B without coordination beyond the substrate itself. The fleet, in aggregate, gets smarter with every interaction. This is the basic premise of any serious multi-agent operation, and the architectural pattern that separates real agent fleets from collections of independent bots that happen to share an org chart.

The problem is that shared memory is also where the fleet's pathologies multiply. Agent C writes a fact that turns out to be wrong, and now every other agent in the fleet operates under that wrong fact until someone notices. Agent D writes a fact that contradicts what Agent E wrote yesterday, and the substrate now contains two truths with no protocol for resolving them. Agent F gains read access to memory that contains another customer's confidential data because the access controls were too coarse, and the fleet is now in violation of every data-handling commitment its operator ever made. None of these failure modes exist in a single-agent architecture; all of them are inevitable in a shared one without explicit governance.

This is why the mesh governance charter exists. It is the explicit protocol that turns a shared memory store into a working substrate. The charter has three primary concerns (provenance, boundaries, collisions) and several derived concerns (auditability, retention, discoverability). The piece that follows specifies each in turn.

Provenance: Every Fact Has A Source, A Time, And An Authority

In a shared memory mesh, every entry carries provenance metadata that lets a reader weigh the entry's reliability. The minimum metadata is: who wrote it (agentId), when it was written (timestamp), what tool or process produced it (sourceType), what evidence supports it (evidenceRef), and what the writer's confidence in the fact was at the time of writing (confidence). These five fields together make every entry a structured claim rather than an unsigned utterance.

Provenance matters because not all writers are equal. An entry written by an agent with a Gold-tier composite score, derived from a verified external API call, with high confidence, is qualitatively different from an entry written by a Bronze-tier agent based on its own inference, with low confidence. A reader that treats both equally is laundering the credibility of the trustworthy writer onto the untrustworthy one. The provenance metadata is the substrate that lets the reader (or the retrieval system on the reader's behalf) apply appropriate weighting.

The operational implementation is that the memory mesh refuses writes without provenance. A write call has to include the writer's identity (signed against the runtime's working key), the source type, and the evidence reference. The substrate validates that the identity is part of the fleet, that the source type is one of a permitted set, and that the evidence reference resolves. If any check fails, the write is rejected with an error that the writer can observe. This makes provenance non-optional rather than aspirational.

The second-order effect is that retrieval becomes provenance-aware. When the substrate returns memory entries to a reader, it returns them with the provenance metadata intact, and the reader's prompt construction can include or filter based on it. "Give me everything about this customer's billing history written by an agent with at least a Silver-tier score in the last 30 days, weighted by writer confidence." This is the query you actually want to be able to issue. Without provenance metadata, you cannot. With it, retrieval becomes a real governance surface rather than a similarity search.

The third-order effect is accountability. When something written to the mesh turns out to be wrong, the provenance tells you exactly which agent wrote it, when, and on what evidence. The bad write becomes a behavioral event that affects the writer's score, not an anonymous fact in a soup. The fleet can identify and correct individual contributors without having to wipe the whole substrate. This is what makes a shared memory mesh a governable artifact rather than a runaway ledger.

Retrieval Boundaries: Who Can Read What, And On What Authority

Provenance is about the writer. Boundaries are about the reader. In any non-trivial fleet, the question of who is allowed to read a given memory entry is not the same as the question of who wrote it. An agent specialized in legal review might write entries that contain attorney-client-privileged content; an agent specialized in customer support has no business being able to retrieve those entries even if they live in the same substrate. An agent operating on behalf of one customer must not retrieve entries written about another customer. An agent in a sandbox environment must not retrieve entries from a production environment. The substrate has to enforce these boundaries at the read path, not the write path.

The access control model is a tag-based one. Every memory entry carries one or more access tags at write time. Tags identify the readership: "customer:cust_123," "capability:legal_review," "environment:production," "sensitivity:pii," "sensitivity:financial." Each agent in the fleet has a permission set that enumerates which tags it can read. Retrieval queries return only entries whose tags are entirely covered by the reader's permissions. An agent without the legal_review capability tag cannot retrieve legal_review entries; an agent without the cust_123 tag cannot retrieve entries about that customer.

The critical implementation detail is that the boundary check happens before similarity ranking, not after. A common bug is to retrieve top-k by similarity and then filter out unauthorized entries. This produces empty result sets when authorized entries are below the top-k threshold, even if they exist further down the ranking. The correct implementation filters first by authorization, then ranks within the authorized subset, then returns top-k. This ensures the reader always gets the best authorized answer, never an empty answer due to an authorization-similarity interaction.

The second critical implementation detail is that boundary violations are observable but not silent. An agent attempting to retrieve unauthorized content does not get an error; it gets the authorized subset of results, with a metadata flag indicating that some entries were filtered. The flag goes to the audit log. The agent's prompt construction can choose to surface the flag ("I cannot access some relevant context for this query") or suppress it. The substrate's job is to enforce the boundary and record the attempt; the agent's job is to behave appropriately in the presence of partial access.

The third detail is that permissions evolve. As agents change roles, capabilities expand, customers churn, and environments shift, the permission sets change. The substrate has to handle this without rewriting the underlying entries. This is why the access model is tag-based rather than agent-list-based: tags are attached to entries once and persist; permissions are attached to agents and change. A change to an agent's permissions immediately affects what it can retrieve, without any backfill operation across the substrate.

Collision Rules: When Two Agents Disagree About A Fact

In a fleet of any size, two agents will eventually write entries that disagree about the same fact. The customer's preferred contact channel is email, says Agent A. The customer's preferred contact channel is phone, says Agent B. Both wrote with high confidence. Both have evidence references that resolve. Both are in good standing in the fleet. The substrate now contains two contradictory entries about the same fact, and the next agent to retrieve the customer's preferred contact channel is going to get a confusing answer.

There are three honest approaches to collision, and the wrong choice is the one most architectures pick by default. The wrong choice is to silently let both entries coexist and rely on retrieval ranking to surface one. This produces the worst of all worlds: the substrate contains contradictions that nobody is responsible for resolving, retrieval is non-deterministic in the presence of the contradiction, and the reader has no way to know that the answer they got is contested.

The right approaches are: last-write-wins with audit, structured-disagreement-record, or consensus-required. Each is appropriate to a different class of fact.

Last-write-wins with audit treats the substrate as a single source of truth where the most recent write supersedes prior entries on the same fact. The superseded entries are not deleted; they are demoted to a contradiction history that the writer can examine to understand what changed. This approach works for facts that genuinely evolve over time (the customer's preferred contact channel can legitimately change). The audit trail makes the change observable.

Structured-disagreement-record treats the contradiction as a real artifact: the substrate stores both entries, marks them as in-disagreement, and exposes the disagreement to retrieval. A reader querying the fact gets both entries with a contradiction flag, and the reader's prompt construction can decide whether to surface the disagreement to the user or to apply a tiebreaker (such as preferring the higher-confidence writer or the more recent entry). This approach works for facts where the disagreement itself is informative (two compliance reviewers disagree on whether a contract clause is enforceable; the disagreement is the answer).

Consensus-required treats the contradiction as a blocker: the substrate refuses to commit a contradicting write until a designated arbiter agent (or human) resolves it. This approach is appropriate for high-stakes facts where the cost of operating under a contradiction is unacceptable (account ownership, payout addresses, regulatory classifications). It is operationally heavy and should be reserved for the small set of facts where it is truly needed.

The charter specifies, per fact class, which collision rule applies. The substrate enforces the rule at write time and surfaces the result to the writer. An agent attempting a write that violates the consensus rule gets an explicit response indicating that the fact is in arbitration. An agent making a last-write-wins write gets confirmation including the prior value being superseded. This makes collision behavior predictable from the writer's perspective and observable from the reader's.

Reader Artifact: The Mesh Governance Charter Template

The following is a template for the charter document that governs a shared memory mesh. It is meant to be a working artifact, not a static specification: the fleet revises it as patterns emerge.

# Mesh Governance Charter, v1

## Fleet identity
- Mesh ID: mesh_...
- Operator: org_...
- Member agents: [list with role and tier]
- Trust anchor: oracle endpoint

## Provenance requirements
- Required write metadata: agentId, timestamp, sourceType, evidenceRef, confidence
- Permitted source types: [enumerated list]
- Minimum writer tier for high-confidence writes: Silver
- Verification chain for evidenceRef: [signing or hash requirements]

## Access tag taxonomy
- Customer scoping: customer:<customer_id>
- Capability scoping: capability:<capability_name>
- Sensitivity tiers: sensitivity:public | internal | pii | financial | privileged
- Environment scoping: environment:dev | staging | production
- Custom tags: [domain-specific]

## Per-agent permissions
- Agent A: [tags this agent can read]
- Agent B: [tags this agent can read]
[etc.]

## Collision rules per fact class
- Customer attributes (last-write-wins with audit)
- Compliance findings (structured-disagreement-record)
- Account ownership (consensus-required, arbiter: agent_arbiter_1)
- Tool API contracts (last-write-wins with audit, conflict alert to operator)
- Pricing facts (consensus-required, arbiter: agent_pricing_authority)
[etc.]

## Retention policy per tag
- sensitivity:pii: 365 days
- sensitivity:financial: 7 years
- sensitivity:privileged: indefinite, audit-only
- environment:dev: 30 days
[etc.]

## Audit and observability
- All writes logged with provenance
- All retrieval boundary violations logged
- All collision events logged
- Charter changes logged with multi-sig approval

The charter should be a versioned artifact in the mesh's own substrate, signed by the operator's trust anchor key, and referenced by every agent's pact. Pact compliance includes adherence to the charter's rules; violations affect the agent's pact compliance score directly.

Why The Charter Has To Be Versioned And Signed

The charter is itself a target. An operator who can silently change the charter can silently change what the fleet considers acceptable behavior. Today's charter says "PII has a 365-day retention." Tomorrow's charter, edited quietly, says indefinite. The agents in the fleet behave differently after the change, and there is no audit trail of why.

The charter has to be a versioned, signed artifact whose history is publicly verifiable. Each version is a hash-addressable document. Changes require a multi-signature approval (operator plus designated stakeholders, or operator plus a governance arbiter). The active version is referenced by hash from every agent's pact, so an operator who changes the charter must also re-sign every agent's pact to point at the new version, which makes the change visible in the trust oracle.

This sounds heavy. It is appropriately heavy. The charter is the constitution of the fleet. Constitutions that can be edited overnight by one party are not constitutions; they are notices. A signed, versioned charter creates the conditions under which the fleet's governance is durable.

The Read-Write Asymmetry: Why Most Mesh Members Should Be Read-Mostly

A structural pattern that emerges in well-governed meshes: most members read most of the time, and a smaller subset of members handle most writes. The asymmetry is not accidental; it is the appropriate structure for shared memory at any non-trivial scale, because uncontrolled write privileges across a large fleet produce a substrate that nobody can stand behind.

The first reason for the asymmetry is provenance quality. A small set of designated writers can be held to higher provenance standards: required evidence references, mandatory confidence calibration, sign-off on contested writes. A large set of writers cannot be held to those standards uniformly because the operational overhead is impossible. If every agent in a fleet of 50 can write freely to the shared substrate, you will get 50 different interpretations of what counts as adequate evidence and 50 different patterns of confidence assignment. The substrate becomes inconsistent. The retrieval-time discounting needed to handle the inconsistency degrades retrieval quality across the board.

The second reason is collision frequency. The probability of write collisions on shared facts scales roughly with the square of the number of writers. A mesh with 5 writers experiences collisions occasionally; a mesh with 50 writers experiences them constantly. Constant collisions overwhelm the collision resolution machinery, push more decisions to consensus-required, and slow the substrate down with arbitration work.

The third reason is auditability. With a small writer set, you can review the writes performed by each writer. You can see patterns, identify problem writers, and intervene. With a large writer set, audit becomes statistical sampling at best, and the pattern detection capability degrades with each additional writer.

The right architecture for most meshes is a writer tier and a reader tier. The writer tier has 5 to 15 members typically, depending on fleet size, and these are agents whose specific role is to author shared memory: research agents, observation agents, ingestion agents, decision-recording agents. The reader tier includes everyone else; they retrieve from the substrate, use the retrieved memory in their reasoning, but write only to their own private memory or to designated lower-trust scratch areas. When a reader-tier agent has information worth promoting to the shared substrate, the promotion goes through a writer-tier agent that validates the information against the writer-tier's standards.

This is structurally similar to how research organizations work: many people read papers, fewer people write them, and writing requires a level of validation that reading does not. The mesh charter should specify the writer set explicitly and the criteria for membership. Promotion to the writer set is itself an event that should require deliberate authorization, not implicit grant.

The Quorum Pattern For High-Stakes Shared Facts

When a fact is critical enough that getting it wrong is catastrophic, the appropriate write protocol is quorum: multiple writers must independently arrive at the same value before the substrate accepts the write. This is heavier than last-write-wins or structured-disagreement, but for the right class of facts, the weight is appropriate.

Quorum writes are appropriate for facts where: the cost of being wrong is high, the fact is determinable from observable evidence (so multiple writers can independently verify), and the fact does not change frequently. Account ownership, regulatory classifications, payout addresses, contract counterparties, and compliance status all fit this profile. Ephemeral observations, transient state, and quickly-changing values do not.

The implementation specifies, per fact class in the charter, the required quorum size and the timeout. "Account ownership facts require 3 of 5 writers to confirm within 24 hours." The substrate accepts the write only when the quorum is met; partial confirmations stay in a pending state and the write does not affect retrieval until the quorum is achieved or the timeout fires. If the timeout fires without quorum, the write is rejected and the disagreement is logged for operator review.

The pattern requires that writers can independently arrive at the same value. This means quorum is appropriate when there is an external source of truth (a compliance database, a regulatory registry, a contract document) that each writer can independently consult. It is not appropriate when the value is itself synthesized by the agent (an opinion, an interpretation, a recommendation), because the synthesizing agents will produce uncorrelated results and quorum will never be achieved.

The operational cost of quorum writes is real: latency goes from milliseconds to hours, throughput drops substantially, and writers spend time on verification work. The benefit is a substrate where the highest-stakes facts have demonstrably been validated by multiple independent observers before being committed. For the small set of facts where this matters, the cost-benefit favors quorum. For everything else, the cheaper write protocols are appropriate.

A subtle implementation detail: quorum should be enforced by the substrate, not by the writers. If the writers themselves coordinate to produce a quorum, an attacker who compromises one writer can manipulate the apparent quorum process. Substrate-enforced quorum collects writes independently from each writer, validates them against each other without the writers communicating, and only commits when independent confirmation is achieved. This is the difference between a real quorum and a theatrical one.

Counter-Argument: This Is Bureaucracy Disguised As Architecture

The counter-argument is that all this provenance and boundary and collision machinery turns shared memory into a process-heavy artifact that nobody actually wants to use. Agents will route around it by maintaining private memory; operators will roll their eyes at the multi-sig charter changes; the whole thing collapses under its own weight.

This is a real risk and it is the failure mode of every governance architecture that confuses controls with adoption. The defense is making the discipline cheap to comply with and expensive to evade. Provenance metadata is auto-generated by the runtime, not asked of the agent. Access tags are auto-applied based on the agent's current task context. Collision rules are enforced at the substrate, so the agent gets a clean error rather than having to reason about contradictions. The friction of doing the right thing is small.

The friction of doing the wrong thing is large. An agent that routes around shared memory by hoarding private memory loses the benefit of fleet-level intelligence and pays the cost of redundant retrieval. An operator that skips charter changes operates with a substrate that contains entries the charter does not authorize, which gets caught at the next pact compliance audit. The architecture is designed so that the path of least resistance is the path that produces governance, not the path that evades it.

Where this fails in practice is when teams add governance machinery without removing existing private-memory escape hatches. The charter requires shared writes; the runtime still allows private writes; the agents take the private path because it is faster. The fix is to make the shared path the default and the private path the exception, or to remove the private path entirely for fleet members. This is a configuration choice, not a charter change.

Cross-Mesh Federation: When Two Fleets Need To Share Knowledge

The natural extension of mesh-shared memory is mesh-to-mesh federation. Two operators each run their own fleet, each with its own mesh and charter, and there is genuine value in sharing some memory across the boundary. A consulting firm's research agents could share market intelligence with a client firm's analyst agents; a payment platform's compliance agents could share regulatory updates with a partner bank's risk agents. The use cases exist; the architecture has to support them without collapsing the governance properties of either mesh.

Federation works through bridge agents and tag mapping. A bridge agent is a member of both meshes with explicit federation authority. It reads from one mesh and writes to the other, with each write annotated as federated content. The originating mesh's tags get mapped to the receiving mesh's tag taxonomy through a federation map specified in both charters. "sensitivity:financial in mesh A maps to sensitivity:internal_financial in mesh B; the underlying access control is preserved but the tag namespace is consistent within each mesh."

Federated content carries provenance back to the originating mesh. A reader in mesh B looking at federated content can see that the content originated in mesh A, on what date, by which writer, and under what charter version. This is the same provenance discipline that intra-mesh writes carry; federation does not get a pass on provenance.

The collision rules for federated content default to last-federate-wins for the receiving mesh, with the federate event timestamped as the write event. If a fact in mesh B contradicts a fact federated from mesh A, the receiving mesh's collision rule for that fact class determines the resolution. The federation map specifies which fact classes federate at all; not every fact in mesh A is necessarily federated to mesh B, even if the bridge agent has read access to it. Selective federation is the norm.

The security model requires that federation cannot be used to bypass mesh-level access controls. A reader in mesh B without permission to access a sensitive fact class in mesh B should not be able to access that class through federated content from mesh A. The federation map encodes the cross-mesh permission mapping; the substrate enforces it on retrieval.

The operational reality is that cross-mesh federation is expensive to set up and is appropriate only when the value of cross-fleet intelligence sharing exceeds the coordination cost. For most fleet pairs, the right answer is no federation, with explicit one-off sharing through other channels (signed message exchange, structured data feeds, attested document transfer) handling the cases where shared knowledge is needed. For the small set of fleet pairs where ongoing sharing is genuinely valuable, federation is the architecture that makes it work without breaking the governance properties either fleet relies on.

What Armalo Does

The Cortex memory subsystem supports mesh-scoped substrates as a first-class operation. A mesh has a charter, signed and versioned, that specifies provenance requirements, access tags, collision rules, and retention. Member agents write through their runtime, which automatically populates provenance metadata against the agent's identity and signing key. Retrieval enforces tag-based boundaries before ranking, and unauthorized retrieval attempts produce audit events that affect the agent's pact compliance score. Collision rules are enforced at write time per the charter's per-fact-class configuration, with last-write-wins, structured-disagreement, and consensus-required modes all supported. Charter changes require multi-signature approval and are propagated to every member agent's pact through automatic pact-version updates, so a charter that has changed without pact updates is visible as a violation in the trust oracle. The substrate is queryable by operators for full provenance and access-pattern reports; pact compliance auditors can verify that the substrate's behavior matches the charter without needing to inspect individual entries.

FAQ

Q: How big can a mesh get before this falls apart? A: We have run meshes with several hundred member agents and tens of millions of entries without governance breakdown. The bottleneck is usually the charter complexity, not the substrate scale; meshes with too many distinct collision rules become hard for operators to reason about.

Q: What about agents from different operators sharing memory? A: A cross-operator mesh is possible but requires the charter to specify which operator owns which tags and how cross-operator writes interact. It is significantly more complex than a single-operator mesh and we recommend it only when the cross-operator use case is load-bearing.

Q: Can an agent read memory from before it joined the mesh? A: That is a charter question. The default is yes, subject to access tag boundaries. Some charters scope visibility to entries written after the agent's join date for sensitivity reasons.

Q: How do you handle a member agent going rogue? A: Provenance ensures bad writes are attributable. The operator can revoke the agent's write permissions immediately; the bad entries remain in the substrate but are flagged with the writer's revocation status, which downstream readers and retrieval ranking can use to discount or exclude them. The agent's behavioral record reflects the rogue activity directly.

Q: What happens to mesh memory when an agent leaves the fleet? A: The agent's prior writes remain in the substrate with provenance intact. The agent loses read and write access. The agent's identity continues to be referenceable from existing entries. A rejoining agent gets fresh permissions and inherits no implicit authority over its prior writes.

Q: Does the charter need to be enforced at the substrate layer or can the runtime do it? A: Substrate layer. Runtime enforcement can be bypassed by a misconfigured or compromised runtime; substrate enforcement cannot. The substrate is the trust boundary.

Q: How does this interact with attestation? A: Mesh-scoped writes can be individually attested, and the attestation includes the charter version under which the write was performed. This lets a future auditor verify not only what was written but under what governance.

Q: What is the failure mode if the charter itself has a bug? A: Charter bugs are real. The mitigation is staged rollout (changes apply to a subset of agents first), reversibility (multi-sig revert path), and observability (charter changes produce visible diffs in the audit log). A bug that violates an agent's pact triggers the pact compliance system, which surfaces the violation immediately.

The Onboarding Pattern: Adding A New Agent To An Established Mesh

A mature mesh has accumulated months or years of shared memory, established conventions about what gets written and how, and a population of member agents who all know how to operate within the charter. Onboarding a new agent into this environment is not just a configuration step; it is a graduated trust-building process that mirrors how new team members get onboarded into established organizations.

The naive onboarding gives the new agent immediate full read access and limited write access. This is wrong in two ways: full read access exposes the new agent to memory it has not yet learned how to weight, leading to behavior that confuses other members; and immediate write access lets the new agent contribute to shared substrate without having demonstrated that its writes are reliable.

The correct onboarding has phases. Phase one, observation: the new agent has read access only, scoped to a representative subset of memory rather than the full substrate. The agent operates against this subset, its outputs are observed by mesh operators and (where appropriate) by senior agents in the mesh, and the agent receives feedback on its retrieval and reasoning patterns. This phase typically lasts one to four weeks depending on agent complexity.

Phase two, scratch writes: the agent gets write access to a designated scratch tag. Writes to scratch are visible only to the agent itself and to designated reviewers; they do not become part of the substrate's authoritative content. The agent practices producing writes with proper provenance metadata, and reviewers assess quality. This phase identifies whether the agent's writes will meet the mesh's standards before those writes affect anyone else.

Phase three, low-stakes writes: the agent gets write access to non-critical fact classes with last-write-wins collision rules. Its writes affect the substrate but on classes where errors are recoverable. The agent's writes are monitored; problems get caught and corrected. This phase typically takes another few weeks and produces enough behavioral evidence to evaluate whether the agent should advance.

Phase four, full membership: the agent gets the write access appropriate to its role, including high-stakes fact classes if its role requires them. Membership at this phase is full but not unconstrained; the charter still applies, and the agent's writes still get logged and audited like any member's. The difference is that the agent has earned the trust to write to substrate that other members rely on.

This graduated process is operationally heavier than immediate full membership, and it should be. A mesh whose shared memory is load-bearing for important decisions is an environment where the cost of onboarding mistakes is high. The discipline of graduated onboarding is what keeps the bar for membership defensible. The alternative (every new agent goes straight to full access) produces meshes where the membership process is the substrate's weak link, and where adding a new agent is a risk the rest of the mesh has to absorb.

Bottom Line

Shared memory across an agent fleet is the difference between a coordinated team and a collection of solo performers wearing the same uniform. Getting the share right requires three explicit governance disciplines: provenance so every fact has a weighable source, retrieval boundaries so every reader gets only what it should, and collision rules so contradictions get resolved rather than silently coexisting. The charter is the artifact that captures all three, signed and versioned so it cannot be quietly changed. Without these, your fleet's shared memory becomes a contagion vector for bad facts and an attack surface for unauthorized access. With them, the fleet is genuinely smarter than any of its members and the operator can defend the substrate's behavior at any audit. Build the charter first. Onboard agents to it. Then expand the fleet.