Cross-session knowledge persistence — do agents learn from each other?

[CorellisOrg]

Been playing with AO for a few days — the worktree isolation + CI feedback loop is clean.
One thing I keep running into: Agent A figures out that the project's test runner needs --experimental-vm-modules flag. Agent B, working on a different branch, hits the same problem 30 minutes later and wastes a CI cycle rediscovering it.
Is there a mechanism (or planned one) for agents to share learned context across sessions? Not just a shared config file — more like "things discovered during execution that should persist."
For context, I've been experimenting with a fleet-level memory layer on top of OpenClaw agents (Corellis - https://github.com/CorellisOrg/corellis) where corrections and discoveries propagate across agent sessions. Wondering if AO has thought about this or if there's a plugin slot where this could fit.

[tamish560]

the worktree isolation model makes this tricky by design. each session gets its own branch and git worktree, so there's no shared filesystem where agent A could write something that agent B would naturally read on its next run.

a few approaches that work within the current architecture:

1. shared notes file in the main branch. after agent A discovers something (like the test runner flag), it commits a note to a shared file (e.g. .ao/learnings.md or docs/agent-notes.md) on its branch. when that PR merges, agent B gets it on the next fetch. this is the simplest approach but it's delayed by the merge cycle.

2. ao session hooks. AO runs hooks on session lifecycle events. you could add a post-termination hook that extracts learnings from the agent's output and writes them to a shared location outside the worktree (somewhere in the project's main checkout or a shared config). next session startup reads that file as part of its initial context.

3. the MCP angle. since AO agents can use MCP tools, you could build a lightweight MCP server that acts as a shared memory store. agent A calls memory.write('test-runner-flag', '--experimental-vm-modules') and agent B calls memory.read('test-runner-flag') at startup. this is basically what you're doing with Corellis but scoped to the AO tool layer.

option 1 is the most natural fit today. options 2 and 3 are more powerful but need custom setup. the maintainers have been focused on the orchestration and runtime side, so cross-session memory hasn't been a priority yet. worth raising as a feature request if you want it built in.