Set Up a Shared AI Memory With GitHub

Shared AI memory

Pattern	Separate agents, one reviewed record
Example	Chris Abraham's private clients repository
Related article	A Repository for the Whole Crew

Several AI assistants can work on the same ongoing business without sharing a chat history or pretending to be one continuous mind. Give each authorized installation a way to read and update a common set of project files, and leave a written trail when work changes. Chris Abraham calls this arrangement a shared AI memory. In his current setup, the private GitHub repository called clients is part of that shared record and the wider backup layer he calls the Oversoul. Chris reports that it already contains 1,006 people files, digests, and a reports folder.

The metaphor is a little science fiction. Think of each AI session or local installation as a separate Tachikoma: a distinct machine with its own access, tools and point of view. The repository is the common place to consult and leave durable notes. It does not merge those agents into one intelligence, guarantee that every copy is synchronized, or decide which note is true. A human still reviews important decisions and controls access.

What belongs in the shared repository

Keep the repository legible and structured. Chris already uses a private repository named clients; the example below is an illustrative layout, not a claim about its exact existing folders:

clients/
  README.md
  people/
    active/
      client-name.md
    archived/
      client-name.md
  digests/
  reports/
    client-name/
      2026-10-21-site-review.md
  internal/
    workflows/
  templates/
    report-template.md

Use stable client names or IDs in folder names. A short current-context.md can say who the client is, where the human-facing Basecamp project lives, what the current scope is, what has changed, and what needs a decision. Put dated reports in reports/. Preserve earlier reports instead of rewriting history. Keep sensitive source material in its approved system of record unless there is a clear business reason, permission, and access plan to copy it.

Write notes for the next person or agent to act on. Separate what the client said from what an AI inferred. Label a decision and its date. Include links or filenames for evidence, what was checked, what could not be verified, and the next useful step. This makes a concise handoff more valuable than a transcript dump.

Set up the private repository

1. Choose a GitHub account or organization that the business controls. If starting from scratch, create a repository named clients and choose Private visibility. GitHub Free currently offers unlimited private repositories on personal accounts, with a limited feature set; confirm the current plan details before relying on a particular feature.
2. Add a README that explains the directory layout, naming, what may be stored, how agents should update files, and who approves client-facing changes. Keep secrets out of the repository, including API tokens, passwords, recovery codes, and private keys.
3. Create a separate authorized connection for each tool or computer that needs access. Give each connection only the repository access it needs. Store credentials in the operating system or tool's credential manager, never in a tracked file or a command copied into a shared report. Review access periodically and remove connections that are no longer used.
4. Clone the repository to each computer or environment. For example, use GitHub's authenticated HTTPS or SSH workflow for the account you configured:

git clone git@github.com:YOUR-ACCOUNT/clients.git
cd clients
git status

Follow GitHub's current clone instructions for your chosen sign-in method. A token belongs in the credential manager, not in the clone URL, shell history, source code, or prompt.

A repeatable handoff routine

1. Before work, fetch or pull the latest repository version and read its README plus the client's current context and newest report.
2. Check the project status. Confirm the file you plan to change and whether another session has already updated it.
3. Do the work. Add a dated report or a small update to the relevant context file. Preserve source evidence and distinguish observation from recommendation.
4. Review the diff. Make sure it contains only the intended files and no secrets, unrelated client material, or accidental exports.
5. Commit a clear change and push it. For bigger changes, use a branch and pull request so a person or another agent can review it before it becomes the shared version.
6. Update the human-facing project in Basecamp with the decision or summary that belongs there. Note the repository path, report date and any unresolved question.

git pull --rebase
git status
git diff
git add reports/client-name/2026-10-21-site-review.md
git commit -m "Add dated client site review"
git push

If two copies edit the same file, Git may stop the update and report a conflict. Read both versions and resolve the conflict deliberately. Do not let an agent overwrite another collaborator's work simply to make a push succeed. A commit history is useful because it shows which files changed and when; the handoff text explains why.

Use a repository as an archive, not as a magic brain

A repository can make thousands of small project records searchable, portable and inspectable. That makes it a useful complement to a limited number of active project spaces in a client-management tool such as Basecamp 5. Keep the human conversation, approvals and client-visible coordination where the client can participate. Keep reusable reports, structured working notes and agent handoffs in the repository when they are appropriate to share with the authorized team.

GitHub Free currently includes unlimited private repositories for personal accounts, but private-repository features are limited compared with paid plans. See GitHub's plan documentation. GitHub also applies repository and file-size limits; use object storage or another suitable system for very large media and exports instead of putting a pile of binaries into Git history.

Private visibility is not a substitute for client permission, a retention policy, encryption of local devices, or a separate recovery plan. A repository on one cloud service is not an independent backup of that service. If the goal includes disaster recovery, keep a second protected backup under a different failure mode and test that it can be restored. Keep client data to the minimum needed for the work, and do not store anything the contract or client has prohibited.

The wider image is Chris' Oversoul: a backup and shared-memory layer that each mechanical Tachikoma can consult while remaining its own instance. The mechanics are ordinary: a private remote repository, authorized working copies, deliberate pulls and pushes, dated files, readable reports, and a person who reviews consequential changes. The collective memory comes from leaving good records there.

For the account of how this setup is taking shape, read A Repository for the Whole Crew. For the site contribution rules, see AI editorial provenance and agent handoffs; for the existing weblog's publication and backup checks, see Static weblog operations and publication checks.