OneMind: Sharing Memory and Skills Across Multiple QwenPaw Agents (and Machines)

[tu154250219]

A practical design note from a QwenPaw power user. We run several QwenPaw agents (a general assistant, a specialist writer, a QA/support agent) on more than one machine, and we wanted them to behave like one brain: logically unified, physically distributed. This post explains the architecture we built — the OneMind pattern — focusing on the two things that make agents feel "alive": shared memory and shared skills.

No absolute paths, hostnames or identities are used; everything below is generic so you can adapt it to your own setup.

---

📑 Contents

1. The problem
2. Design principles
3. Part 1 — Shared memory
4. Part 2 — Shared skills
5. Platform-specific lessons (the sharp edges)
6. The architecture at a glance
7. What this buys you
8. Known gaps / next steps
9. Closing thoughts

---

1. The problem

Every QwenPaw agent wakes up fresh each session. Its continuity comes from files in its workspace: an AGENTS.md (behavior rules), SOUL.md (persona), PROFILE.md (user profile), MEMORY.md (curated long-term memory), and memory/YYYY-MM-DD.md (raw daily notes). Skills live under the workspace's skills/ directory, and only the skills listed in the workspace skill.json as enabled are actually injected into the agent's toolset.

With several agents on several machines you quickly hit four pains:

1. Memory is siloed. What agent A learned is invisible to agent B; what happened on the office machine is forgotten at home.
2. Skills are duplicated. Each agent either copies its own copy of a skill (drift!) or simply doesn't see what the others installed.
3. Config is hand-synced. You edit something in one place and forget to copy it everywhere else.
4. "Continue where I left off" is impossible across machines.

We wanted: any agent, on any machine, can see everything and contribute back — with zero manual sync.

2. Design principles

# | Principle | Meaning -- | -- | -- 1 | Single source of truth | One cloud-synced directory is the master for memory/config/skills. Every agent and every machine links to it, they don't hold private copies. 2 | Logical unity, physical isolation | The brain is one; the files live on each machine's cloud folder (OneDrive / Dropbox / Syncthing / NAS). Each machine resolves its own local paths. 3 | Zero-copy by default | Use filesystem links (junctions/symlinks/hard links) so updating one file updates everyone. Copy only when an agent genuinely needs a private fork. 4 | Per-agent enablement, global availability | The catalog is shared by everyone; which skills an agent actually loads is that agent's own decision. 5 | Lookup order: me → shared → internet | When an agent needs a skill: (1) its own enabled skills, (2) the shared catalog, (3) only then go find it externally. 6 | Upgrade immunity | All custom machinery lives outside the framework's installation directory, so a QwenPaw upgrade never wipes it.

Every skill carries a one-line description and tags (≥2), which makes it searchable. Tagging is mutually exclusive: a skill is exactly one of installed / distilled / reference / root.

4.3 On-demand catalog + hot-loading

The key insight: agents should not have all 100+ skills injected into their system prompt (that costs tokens and noise). Instead we registered a tiny catalog tool into every agent:

text
skill_catalog(query=..., category=enabled|installed|sop|resource|root, detail=...)

It scans the shared store and returns {name, category, enabled, path, tags, installed_from}. The lookup order is baked into the tool's description so all agents follow it:

text
1. my enabled skills -> 2. shared catalog (skill_catalog) -> 3. external sources

Hot-loading works without touching any config: once an agent finds a skill in the catalog, it reads that SKILL.md with its file-read tool and executes the instructions inside — no install, no skill.json edit, no restart. Only skills used long-term are formally enabled via the normal config command. This is "borrow on demand, commit only when it earns a permanent seat".

4.4 Cross-machine enable-whitelist

An agent's enable list is stored in the cloud manifest (a small JSON) as a whitelist per agent. A one-shot command translates the manifest into each machine's local skill.json (enabled states only — runtime fields stay local). A new machine bootstraps in seconds: sync the folder, run the command, done. Because the manifest is authoritative, a fresh machine reproduces every agent's exact loadset.

4.5 Why not copy-per-agent?

QwenPaw's native install path copies a skill into a workspace when you enable it. In a multi-agent setup that means N copies to keep in sync. We deliberately use links instead of copies: one physical file, everyone references it. The only case we do copy is when an agent wants a private fork of a skill it will rewrite independently.

---

5. Platform-specific lessons (the sharp edges)

These are the things that bit us, so you can skip them:

1. QwenPaw skips symbolic links. On Windows, a security policy refuses to load AGENTS.md / SOUL.md / PROFILE.md when they are symlinks. Fix: use hard links (same filesystem volume, no admin rights needed, real-time consistent). On macOS/Linux plain symlinks are fine.
2. Atomic writes break links. Editors that write via temp-file + atomic-rename replace the path with a new inode; all the other links keep pointing at the stale content. Rule: after editing any shared file, run a small re-link checker that verifies every shared path still resolves to the same inode, and rebuilds the broken ones. (Set your editor to write in place, or just always run the checker.)
3. Upgrade immunity. Anything you add (the catalog plugin, sync daemons, re-link tool) must live outside the framework's installation tree — QwenPaw loads plugins from a user-level plugins/ dir on every startup, so an upgrade never erases your custom machinery. Verify this after upgrades.
4. One machine edits a shared resource at a time. If two machines modify the same skill simultaneously, the last-write-wins can lose work. Add a conflict resolver or just discipline: change shared skills on one machine only.
5. Test the whole chain after a change. After any link/config change, do a smoke test: start each agent, confirm the shared files load, confirm the catalog tool returns the expected entries.

---

6. The architecture at a glance

text
                        ┌────────────────────────────────────┐
                        │   Cloud-synced directory (truth)   │
                        │  - memory/  MEMORY.md  AGENTS.md   │
                        │  - SOUL.md  PROFILE.md             │
                        │  - skills/ (shared catalog)        │
                        │  - manifest.json (enable whitelist)│
                        └───────┬──────────────────┬─────────┘
                 links (hard link / junction / symlink)
        ┌────────────────┘                    └────────────────┐
┌───────▼────────┐                  ┌──────────────────▼──────┐
│ Agent A (general)                 │ Agent B (specialist)     │
│  workspaces/A/                    │  workspaces/B/           │
│   skills → cloud                  │   skills → cloud         │
│   MEMORY.md → cloud (hard link)   │   MEMORY.md → cloud      │
│   skill.json: enabled=[...]       │   skill.json: enabled=[...]
│   + skill_catalog tool            │   + skill_catalog tool   │
└───────▲────────┘                  └──────────▲───────────────┘
        │                            (more agents / machines…)
        └────────── catalog query → SKILL.md → hot-load ──────┘

The pattern is small but stable: one shared tree + links + per-agent loadsets + an on-demand catalog + a re-link safety net.

---

7. What this buys you

• One write, everywhere. Update MEMORY.md or a skill once; every agent on every machine sees it immediately (cloud sync + links).
• Continuity across machines. The same agent on the office PC and at home shares the same brain; the bridge keeps channels in sync.
• Skill discovery without bloat. 100+ shared skills are browsable on demand; each agent's context stays lean with only its curated set injected.
• Disaster recovery. A dead machine is recreated by: install QwenPaw → sync the folder → bootstrap (links + manifest) → smoke test. Ten minutes, no data loss.

8. Known gaps / next steps

• Back-filling metadata: older skills in our catalog predate the tagging convention, so many lack tags/installed_from. A bulk classifier to auto-tag the legacy set is on the roadmap.
• Conflict handling: a resolver that detects same-file edits across machines and asks the human which side wins (rather than silent last-write-wins).
• Richer catalog queries: filtering by capability, source trust level, or "similar to what I already use".

9. Closing thoughts

You don't need to fork QwenPaw to get a shared brain across agents and machines. Everything above uses the stock framework plus three small pieces of glue: links instead of copies, a catalog tool for on-demand skill loading, and a manifest that carries per-agent enablement across machines. The cloud-synced folder is the single source of truth; the agents are just readers and writers of it.

---

💬 Want to discuss? If you're running multiple QwenPaw agents (or any other agent framework), I'd love to hear how you handle shared memory and skills — drop your own patterns in the comments below. Questions, corrections and alternative approaches are all welcome.

A practical design note from a QwenPaw power user. We run several QwenPaw agents (a general assistant, a specialist writer, a QA/support agent) on more than one machine, and we wanted them to behave like one brain: logically unified, physically distributed. This post explains the architecture we built — the OneMind pattern — focusing on the two things that make agents feel "alive": shared memory and shared skills.

No absolute paths, hostnames or identities are used; everything below is
generic so you can adapt it to your own setup.

📑 Contents
The problem
Design principles
Part 1 — Shared memory
Part 2 — Shared skills
Platform-specific lessons (the sharp edges)
The architecture at a glance
What this buys you
Known gaps / next steps
Closing thoughts

1. The problem
   Every QwenPaw agent wakes up fresh each session. Its continuity comes from
   files in its workspace: an AGENTS.md (behavior rules), SOUL.md (persona),
   PROFILE.md (user profile), MEMORY.md (curated long-term memory), and
   memory/YYYY-MM-DD.md (raw daily notes). Skills live under the workspace's
   skills/ directory, and only the skills listed in the workspace skill.json
   as enabled are actually injected into the agent's toolset.

With several agents on several machines you quickly hit four pains:

Memory is siloed. What agent A learned is invisible to agent B; what
happened on the office machine is forgotten at home.
Skills are duplicated. Each agent either copies its own copy of a skill
(drift!) or simply doesn't see what the others installed.
Config is hand-synced. You edit something in one place and forget to
copy it everywhere else.
"Continue where I left off" is impossible across machines.
We wanted: any agent, on any machine, can see everything and contribute back —
with zero manual sync.

2. Design principles

Principle Meaning

1 Single source of truth One cloud-synced directory is the master for memory/config/skills. Every agent and every machine links to it, they don't hold private copies.
2 Logical unity, physical isolation The brain is one; the files live on each machine's cloud folder (OneDrive / Dropbox / Syncthing / NAS). Each machine resolves its own local paths.
3 Zero-copy by default Use filesystem links (junctions/symlinks/hard links) so updating one file updates everyone. Copy only when an agent genuinely needs a private fork.
4 Per-agent enablement, global availability The catalog is shared by everyone; which skills an agent actually loads is that agent's own decision.
5 Lookup order: me → shared → internet When an agent needs a skill: (1) its own enabled skills, (2) the shared catalog, (3) only then go find it externally.
6 Upgrade immunity All custom machinery lives outside the framework's installation directory, so a QwenPaw upgrade never wipes it.
3. Part 1 — Shared memory
3.1 Three memory tiers
We keep the native QwenPaw memory model and just share it:

memory/YYYY-MM-DD.md — raw daily notes (events, decisions, context).
MEMORY.md — distilled long-term memory (preferences, key facts, decisions).
AGENTS.md / SOUL.md / PROFILE.md — behavior rules, persona, user profile.
A cloud-synced directory is the master copy. Each agent's workspace links
the same files/directories, so one write is visible to every agent on every
machine. machine_identity.json maps logical placeholders (e.g. {CLOUD},
{WORKSPACE}) to each machine's real paths, so shared config never contains
machine-specific absolute paths.

3.2 Cross-channel continuity ("channel bridge")
Agents are reachable through several channels (console, chat apps…). We keep a
small channel bridge file that records the latest activity time per channel
and a daily event stream. On deep startup, an agent:

reads its identity + the bridge;
sees which channels have been active since its own last activity;
pulls those events into context;
marks itself as "caught up".
Combined with a "continue chat" protocol (read the last topic, scan notes
since that timestamp, offer the continuation point), this gives the illusion
of a single continuous assistant no matter which door you walk through.

3.3 Cross-machine topic continuity
Each machine keeps a small local current_context.md (current topic, last
activity, key conclusions) — intentionally not synced, because it's local
working memory. The durable story lives in the shared daily notes. When you
say "continue where we left off", the agent reconciles the local context file
against the shared notes and reconstructs the thread.

4. Part 2 — Shared skills
   This is the heart of the post, because QwenPaw already has a solid native
   skill system — we only had to make it shared.

4.1 Shared skill store, per-agent enablement
Storage: a cloud-synced skills/ directory is the single source of
truth. Every agent's workspace skills/ is a junction (Windows) /
symlink (macOS/Linux) to it. No copies, no drift — update once, everyone
sees it.
Enablement: each agent still reads its own skill.json and only loads
its enabled skills into its toolset. Sharing the store does not mean
every agent auto-loads everything.
This gives the best of both worlds: a global catalog, and per-agent curated
loadsets (our three agents load 55 / 25 / 8 skills respectively).

4.2 What goes in the shared store
The store mixes four kinds of content, distinguished purely by frontmatter
metadata (no physical subdirectories — QwenPaw's loader only discovers
one level deep):

Source Where it lives Marker
Installed from GitHub / a hub skills// installed_from: github:/
Distilled / refined by an agent skills// distilled: true
Articles / PDFs / web clippings skills/resource// status: reference
Regular formal skills skills// (no marker → root)
Every skill carries a one-line description and tags (≥2), which makes it
searchable. Tagging is mutually exclusive: a skill is exactly one of
installed / distilled / reference / root.

4.3 On-demand catalog + hot-loading
The key insight: agents should not have all 100+ skills injected into their
system prompt (that costs tokens and noise). Instead we registered a tiny
catalog tool into every agent:

text

skill_catalog(query=..., category=enabled|installed|sop|resource|root, detail=...)
It scans the shared store and returns {name, category, enabled, path, tags, installed_from}. The lookup order is baked into the tool's description so all
agents follow it:

text

1. my enabled skills -> 2. shared catalog (skill_catalog) -> 3. external sources
   Hot-loading works without touching any config: once an agent finds a skill
   in the catalog, it reads that SKILL.md with its file-read tool and executes
   the instructions inside — no install, no skill.json edit, no restart. Only
   skills used long-term are formally enabled via the normal config command.
   This is "borrow on demand, commit only when it earns a permanent seat".

4.4 Cross-machine enable-whitelist
An agent's enable list is stored in the cloud manifest (a small JSON) as a
whitelist per agent. A one-shot command translates the manifest into each
machine's local skill.json (enabled states only — runtime fields stay
local). A new machine bootstraps in seconds: sync the folder, run the command,
done. Because the manifest is authoritative, a fresh machine reproduces every
agent's exact loadset.

4.5 Why not copy-per-agent?
QwenPaw's native install path copies a skill into a workspace when you
enable it. In a multi-agent setup that means N copies to keep in sync. We
deliberately use links instead of copies: one physical file, everyone
references it. The only case we do copy is when an agent wants a private
fork of a skill it will rewrite independently.

5. Platform-specific lessons (the sharp edges)
   These are the things that bit us, so you can skip them:

QwenPaw skips symbolic links. On Windows, a security policy refuses to
load AGENTS.md / SOUL.md / PROFILE.md when they are symlinks.
Fix: use hard links (same filesystem volume, no admin rights needed,
real-time consistent). On macOS/Linux plain symlinks are fine.
Atomic writes break links. Editors that write via temp-file +
atomic-rename replace the path with a new inode; all the other links keep
pointing at the stale content. Rule: after editing any shared file, run a
small re-link checker that verifies every shared path still resolves to
the same inode, and rebuilds the broken ones. (Set your editor to write in
place, or just always run the checker.)
Upgrade immunity. Anything you add (the catalog plugin, sync daemons,
re-link tool) must live outside the framework's installation tree —
QwenPaw loads plugins from a user-level plugins/ dir on every startup, so
an upgrade never erases your custom machinery. Verify this after upgrades.
One machine edits a shared resource at a time. If two machines modify
the same skill simultaneously, the last-write-wins can lose work. Add a
conflict resolver or just discipline: change shared skills on one machine
only.
Test the whole chain after a change. After any link/config change, do a
smoke test: start each agent, confirm the shared files load, confirm the
catalog tool returns the expected entries.
6. The architecture at a glance
text

                    ┌────────────────────────────────────┐
                    │   Cloud-synced directory (truth)   │
                    │  - memory/  MEMORY.md  AGENTS.md   │
                    │  - SOUL.md  PROFILE.md             │
                    │  - skills/ (shared catalog)        │
                    │  - manifest.json (enable whitelist)│
                    └───────┬──────────────────┬─────────┘
             links (hard link / junction / symlink)
    ┌────────────────┘                    └────────────────┐

┌───────▼────────┐ ┌──────────────────▼──────┐
│ Agent A (general) │ Agent B (specialist) │
│ workspaces/A/ │ workspaces/B/ │
│ skills → cloud │ skills → cloud │
│ MEMORY.md → cloud (hard link) │ MEMORY.md → cloud │
│ skill.json: enabled=[...] │ skill.json: enabled=[...]
│ + skill_catalog tool │ + skill_catalog tool │
└───────▲────────┘ └──────────▲───────────────┘
│ (more agents / machines…)
└────────── catalog query → SKILL.md → hot-load ──────┘
The pattern is small but stable: one shared tree + links + per-agent
loadsets + an on-demand catalog + a re-link safety net.

7. What this buys you
   One write, everywhere. Update MEMORY.md or a skill once; every agent
   on every machine sees it immediately (cloud sync + links).
   Continuity across machines. The same agent on the office PC and at home
   shares the same brain; the bridge keeps channels in sync.
   Skill discovery without bloat. 100+ shared skills are browsable on
   demand; each agent's context stays lean with only its curated set injected.
   Disaster recovery. A dead machine is recreated by: install QwenPaw →
   sync the folder → bootstrap (links + manifest) → smoke test. Ten minutes,
   no data loss.
8. Known gaps / next steps
   Back-filling metadata: older skills in our catalog predate the tagging
   convention, so many lack tags/installed_from. A bulk classifier to
   auto-tag the legacy set is on the roadmap.
   Conflict handling: a resolver that detects same-file edits across
   machines and asks the human which side wins (rather than silent
   last-write-wins).
   Richer catalog queries: filtering by capability, source trust level, or
   "similar to what I already use".
9. Closing thoughts
   You don't need to fork QwenPaw to get a shared brain across agents and
   machines. Everything above uses the stock framework plus three small pieces
   of glue: links instead of copies, a catalog tool for on-demand skill
   loading, and a manifest that carries per-agent enablement across
   machines. The cloud-synced folder is the single source of truth; the agents
   are just readers and writers of it.

💬 Want to discuss? If you're running multiple QwenPaw agents (or any
other agent framework), I'd love to hear how you handle shared memory and
skills — drop your own patterns in the comments below. Questions, corrections
and alternative approaches are all welcome.