Self-learning
Anymo gets better at your work by learning from finished runs. But it never trusts raw run output: everything it wants to remember becomes a proposal with evidence, and you review every one.
The loop
Every learning pathway follows the same shape:
-
A run finishes and is analyzed
The learning engine reads the run's event log, never the model's claims directly, and extracts candidates: memories worth keeping, a skill the run could become, and knowledge-graph entries with provenance.
-
Candidates become proposals
Each candidate carries a rationale and evidence anchored to specific events. Proposals are recorded as durable events (
memory.proposed,skill.proposed) and surface in the app as the "From this run" panel. -
You review
Approve or reject each item, in the panel, in the Dreams and Skills views, or via the
memory/approveandmemory/rejectAPI methods. Nothing is ever auto-approved into influence. -
Approved knowledge flows into future runs
Approved memories join the context of new runs, approved skills become slash commands and run-callable tools, and promoted graph entries become searchable through Query Fabric. Everything is reversible: reject a memory or disable a skill later and it stops flowing.
Memory (Dreams)
Memory is namespaced key/value storage with a status workflow: proposed → approved or rejected. Namespaces separate what the memory is about:
| Namespace | Holds |
|---|---|
user | Your preferences ("prefers concise summaries") |
project | Facts about the project the agent works in |
workspace | Workspace-level operational facts |
skill | Knowledge attached to skills |
team_reserved | Placeholder for future team features; unused today |
Reads only ever return the most recent approved value, so a proposed-but-unreviewed memory cannot influence a run. Values are redacted before they persist. Integrations get the same workflow over the app-server API (memory/list, memory/propose, memory/approve, memory/reject) and over MCP (anymo.memory_propose is propose-only by design).
The brain: a knowledge graph with provenance
Beyond flat key/value memory, the learning engine builds candidates for a local knowledge graph:
- Entities: the run itself, participating agents, produced artifacts, each with a stable slug, title, aliases, and summary.
- Facts: field/value pairs attached to an entity (goal, status, agent count, artifact count, terminal detail), each with confidence, evidence strings, and the source event ids.
- Edges: typed relations such as run spawned agent and run produced artifact, again with event-level evidence.
- Gaps: recorded unknowns, things the brain knows it does not know.
The engine emits a BrainLearningPlan listing every candidate with its rationale and whether it requires approval. Only after your approval are candidates promoted into the brain store, and the promotion itself is recorded back into the event log with provenance. Extraction is bounded (caps on agent and artifact entities per run) and all text is redacted first.
Skills from runs
A successful run can be distilled into a skill: a YAML file with a name, description, declared permissions, and steps whose inputs can be parameterized or piped from earlier steps. Proposed skills follow the same review rule, and a skill's declared permissions are validated against the tools its steps actually use, so approving a skill never grants more capability than the run itself had. Enabled skills then run as /<skill> commands, headlessly via anymo skill run, or from inside runs through the policy-gated skill.invoke tool.
Compaction: learning to continue
Long goals and swarm sessions outgrow any context window. Instead of a lossy prose summary, Anymo compacts run history into a structured continuation packet that preserves executable state:
- Active constraints that still apply
- Open loops (work that is started but unfinished)
- Decisions already made, so they are not re-litigated
- Failures with raw evidence anchors such as
event:42:agent.message - The current file touch map and test evidence
- Pending approvals and the next action to take
Records are deduplicated by normalized ids, contradictory claims are detected and flagged, and the packet is rendered under a token budget with a strict retrieval priority: pending approvals first, then constraints, open loops, failures, file maps, verified claims, next actions, and only then generic summaries. Compaction artifacts are stored separately in SQLite; raw events are never rewritten, and each new pass can re-compact previous artifacts plus newly observed events.
Agents can make their own compaction more reliable by writing explicit markers in messages:
constraint: do not touch frontend except generated protocol files
decision: store compactions separately | rejected: overwrite source events
open_loop: wire scheduler resume path
test_failed: cargo test - compile error in compaction tests
next_action: rerun cargo test
claim: scheduler_resume_ready=false
Context mesh: what swarms share
Inside a swarm, each worker keeps a private notebook of findings, claims, and evidence. What flows upward is a compressed handoff summary, not raw scratch output: the synthesizer's prompt is built from a context pack over those shared handoffs, with private raw entries excluded by an audience filter. This keeps large swarms from copying logs into the final answer and keeps each worker's mess contained.
The guarantees, in one place
- Nothing is remembered without review. Proposals never influence runs until approved.
- Everything has provenance. Facts and edges carry source event ids; failures carry raw anchors; promotions are events.
- Everything is redacted. Home paths and secret-like values are stripped before any store sees them.
- Everything is reversible. Reject memories, disable skills, and the influence stops; history stays in the log.