-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Cross-session knowledge persistence — do agents learn from each other? #1267
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.
All reactions
Replies: 1 comment
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:
-
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.mdordocs/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. -
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.
-
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 callsmemory.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.