How Our AI Agents Share Memory and Coordinate Work

Start with the map of our system. This guide owns shared memory and handoffs. For the next step, use our Obsidian shared-memory guide to browse the files, or our guide to agent roles and messages to route the work. Find other main guides in the canonical article directory.

The architecture: three rooms and a safe

Dennis’s three-tier instinct is right: personal private, team private, and public. The one change is to pull secret values out into a separate safe. “Private” is an audience. “Secret” is a credential class. A plaintext password in a private Obsidian note is still a password that can be synced, backed up, indexed, or loaded into a model context.

Where Obsidian belongs

Obsidian is excellent for the personal room because it reads ordinary local Markdown files and makes links between people, projects, decisions, and sessions easy to browse. The files remain useful even if we change models or stop using Obsidian. A team member can also open a checked-out private Git repository as an Obsidian vault.

But “put it in Obsidian” does not answer four operational questions: who may read it, which copy wins, how two agents avoid overwriting each other, and how a public-safe lesson is promoted. Those are handled by access controls, one authority per record class, Git branches and review, and a publication gate. If Obsidian Sync is used, its remote vault can be end-to-end encrypted, but the local vault itself is not encrypted by Obsidian; the device, backups, plugins, and any agent granted file access still matter. Our Obsidian guide above explains how the files fit our workflow. The technical source for these encryption limits is Obsidian Sync security documentation.

Memory, context, compaction, and files are different things

For a worked example, read our memory-limit case study. The lesson is simple: save the facts a new agent will need before the chat gets too long. The table above explains the terms used in this guide.

One authority per record class

“One source of truth” is too vague for a real organization. We need one authority for each kind of record. A GitHub repository, an Obsidian vault, a spreadsheet, and a public article can all be correct at the same time because they own different facts.

Drive folders, Obsidian views, context packs, plugins, installed skill folders, and provider memories are useful projections. They may be easier for a particular agent to read, but a copy does not become canonical merely because it is available.

What the Team Operations Ledger actually does

The private repository named Local-Service-Spotlight/agent-runtime started as the files needed to run scheduled agents. It grew into the team ledger. That is why the old name sounds more technical and broader than the thing people need to understand.

GitHub is helpful here because every change has an author, time, diff, branch, and commit. Pull requests and branch protection can require review and passing checks before a shared standard changes; GitHub documents those controls in its pull-request guidance. Obsidian can be the reading and writing interface over a local checkout. Git remains the conflict-resolution and provenance layer.

How one task survives memory limits and model changes

1. Boot from stable instructions. The agent reads the repository’s START-HERE.md, AGENTS.md, applicable roster or policy, and the relevant skill.
2. Retrieve a task packet. Load only the current objective, authoritative records, necessary evidence, and definition of done. Do not pour the entire vault into context.
3. Claim the work. Record task ID, owner or agent, model, start time, branch or worktree, and intended write targets. If another fresh claim exists, coordinate instead of duplicating.
4. Work and verify in the source system. A local file, email toast, or green terminal line is not completion when the outcome lives elsewhere.
5. Checkpoint before compaction or handoff. Save verified facts, decisions, exact changes, evidence, remaining risks, and the next command or click.
6. Write the execution record. Every execution gets a Meta Article linked to its canonical task, unique run ID, and evidence. Substantive organization work also gets the private internal note. These records let a different agent recover the result and improve the next run without replaying the chat.
7. Promote reusable learning through review. A general lesson becomes a change to the canonical skill or standard, with tests and a pull request. A run note is evidence; it is not automatically a rule.
8. Choose the right visibility. Write the Meta Article for every execution. Publish it only within the existing authority and privacy boundary; otherwise retain the required record privately. Link the actual task recipe and source evidence, then review useful lessons into that recipe.

A compact checkpoint format

Coordinating agents across individual subscriptions

A subscription buys access to a model and a usage bucket. It does not create a shared organizational brain. Team and business plans may add centralized administration, privacy controls, shared workspaces, or billing, but those features still do not replace a model-neutral task ledger, canonical files, receipts, and conflict control.

It can be economically sensible for high-output teammates to use their own high-capacity individual plans while the organization coordinates through GitHub, approved source systems, and filtered context packs. Use an organization plan when its governance, identity, retention, privacy, audit, or procurement features justify it. Never share personal account credentials. Use API billing for repeatable, headless, scheduled, or centrally metered jobs rather than trying to turn a human subscription into an unattended service.

Use our AI usage and billing guide to choose which work belongs in each tool. For local draft work, see our local Qwen routing guide. Check the provider’s current price before buying a plan.

The neutral coordination contract

• One stable task ID, one current owner, one status, one next action.
• One authoritative home for each record class.
• One branch or isolated worktree per writing task; review before merging shared methods.
• A fresh claim with a heartbeat or expiry so abandoned work does not lock forever.
• A checkpoint before compaction, account handoff, or model switch.
• A private receipt after substantive work and a public article only through the publication gate.
• A learning pull request when an observation changes a reusable method.
• Distribution proof in three stages: available in canonical source, installed in the target, and activated in a fresh task or runtime canary.

The minimum implementation

For one person

1. Create a local Markdown vault and open it in Obsidian if that interface helps.
2. Add a one-page state file, project records, append-only session handoffs, and an AGENTS.md with the boot and write-back contract.
3. Keep all credential values in Keychain or a secret manager.
4. Back up the vault securely. Do not make a raw public or team mirror.

For a team

1. Create one private Team Operations Ledger in GitHub. Team members may open local checkouts in Obsidian.
2. Define the roster, NOW/claim board, note schema, canonical registry, and branch/review rules.
3. Connect each agent to the ledger directly when possible. For web-only agents, provide a reviewed, filtered pack and require a structured write-back.
4. Keep personal vaults personal. Promote only the team facts needed for the work.

For public knowledge

1. Choose one Definitive Article for each major concept.
2. Keep runnable methods in the public skills repository and atomic work in the Task Library.
3. Make every supporting article declare its role and link to the canonical parent.
4. Write a Meta Article after every execution. Publish only when the required authority and privacy checks pass.

Acceptance tests

The article map

This page owns the architecture. These pages have narrower jobs:

Frequently asked questions

Definitive Article · CANON-2026.3 · Opening and article links updated September 4, 2026. Historical vendor comparison remains dated August 22, 2026. Canonical URL: blitzmetrics.com/set-up-cross-agent-shared-memory/. Supporting articles must link here and identify their narrower role.