Model: openai/gpt-5.4
Generated: 2026-04-01
Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead
Chapter: 10 — Oh-My-OpenCode’s Innovations
Token Usage: ~4,000 input + ~1,000 output
10.5 Wisdom Accumulation System
One of OMO’s deepest innovations is the wisdom accumulation system centered on .sisyphus/notepads/. At first glance, this may look like a simple note-taking convention. It is more than that. It is OMO’s answer to a fundamental multi-agent problem: how can one task’s discoveries become durable working knowledge for later subtasks without forcing every future agent to reread the entire transcript?
The mechanism appears in prompts, hooks, and Atlas reminders. The notepad protocol instructs agents to append findings into structured files such as:
learnings.mddecisions.mdissues.mdverification.mdproblems.md
The exact emphasis varies across prompts and reminders, but the idea is consistent. Execution should produce not only code changes, but also distilled operational knowledge.
This is conceptually important because transcript history is not the same thing as knowledge. A transcript is raw chronological memory. It contains dead ends, repeated discussion, and irrelevant phrasing. A notepad entry is distilled memory. It captures what matters for future execution: conventions discovered, architectural decisions made, blockers encountered, tests run, and unresolved risks.
In CS terms, this is a derived memory layer. The system is compressing high-entropy conversational context into lower-entropy structured artifacts optimized for reuse. That distinction matters greatly in multi-agent settings, where every new subagent spawned from scratch faces a context budget problem.
Atlas is the key beneficiary and distributor of this knowledge. Its prompt instructs it to read notepad files before delegation and to treat them as accumulated wisdom. Verification reminders explicitly tell Atlas to inspect the notepads after a subagent run. The orchestration idea is elegant: every completed subtask should leave behind a usable residue, and every later subtask should start by consuming that residue.
This produces several advantages.
First, it reduces repeated mistakes. If one agent discovers a local convention, a naming pattern, a hidden dependency, or a blocker, the next agent does not need to rediscover it. Second, it improves consistency. Architectural decisions recorded once can shape many later edits. Third, it helps verification. If a worker ran certain checks or encountered certain issues, the orchestrator can reason more clearly about what remains uncertain.
Fourth, and perhaps most importantly, it transforms the system from isolated episodes into a cumulative workflow. The system is not merely answering a sequence of prompts. It is building a task-specific memory base.
This is fundamentally different from Claude Code’s context isolation tendency. Claude Code has strong persistence and session recovery, but its orchestration style is generally more transcript-centric and less built around explicit accumulated wisdom artifacts shared across later delegated workers. OMO takes a more aggressive stance: knowledge should be extracted after each task and passed to all subsequent subagents.
That difference reflects two philosophies. One philosophy says: each subagent should work from the local context it is given, minimizing coupling. The other says: valuable discoveries should propagate. OMO chooses the second.
The trade-off is worth noting. Shared wisdom can spread errors as well as insights. If a wrong assumption is written into decisions.md, later agents may inherit it confidently. This means notepad quality matters. The system therefore works best when Atlas and verification steps act as filters rather than blindly accepting every note as truth.
Still, the architecture is powerful. Multi-agent systems often suffer from what might be called context amnesia through delegation: every subagent starts smart in general but ignorant in specifics. OMO’s notepads are a direct countermeasure. They create local, project-specific, task-specific memory that survives beyond any single subagent’s context window.
There is a broader lesson here for agent design. Long-term memory in coding agents does not always require vector databases, embeddings, or global retrieval systems. Sometimes a simpler approach works better: structured plaintext files, clear semantics, append-only discipline, and orchestrator-level reminders to read them. Because the notes are human-readable, they are also inspectable. That improves trust and debuggability.
In effect, OMO’s wisdom accumulation system sits between raw logs and formal knowledge bases. It is lightweight, local-first, and execution-oriented. That middle ground is often underappreciated.
The deeper innovation is not the directory name or file list. It is the recognition that autonomous work should leave behind reusable judgment, not just changed files. Coding is not only about modifying source code. It is also about preserving what the system learned while modifying source code. OMO turns that insight into runtime policy.
For future coding agents, this may be one of the most transferable ideas in the whole project. Multi-agent autonomy becomes dramatically more useful when work products include accumulated wisdom, not just task outputs.