Knowledge Capture as Side Effect

Summary

Design agent systems so that knowledge capture is a byproduct of corrections people are already making — not a separate documentation task. When a user corrects an agent (“don’t call fetch directly, use the wrapper in src/lib/api-client”), the agent suggests persisting that correction as a knowledge item. The user reviews it, optionally edits, and saves. From that point on, every future session retrieves that knowledge when relevant.

This works because it eliminates the core failure mode of documentation: the cost of writing docs always loses to the cost of shipping features. Nobody maintains wikis because maintenance is a separate activity with deferred payoff. By embedding capture into the correction loop — something people do naturally when working with agents — the knowledge base grows as a side effect of normal work.

The pattern extends beyond chat corrections. Knowledge can also be auto-generated by scanning existing artifacts (READMEs, AGENTS.md, CLAUDE.md, .cursorrules, .rules files), and the system can suggest updates to existing items as conventions evolve. The combination of organic capture (corrections) and systematic extraction (repo scanning) covers both tacit and codified knowledge.

At the most ambitious end, agents can autonomously identify and fill documentation gaps. James Pember describes “self-driving documentation” — giving an agent Playwright access to explore software independently, identify knowledge gaps, and create documentation changes itself. Manik Aggarwal auto-generates user-facing changelogs from commit history using guidelines. Megan Salisbury reverse-builds PRDs from code and conversations. Abhi Chandwani maintains verbose git commits specifically to create context for future agent workflows. In each case, the documentation that nobody wrote gets written as a side effect of the agent’s other work.

How to Apply

When to use: When designing any agent system where users will repeatedly correct the same behaviors, establish conventions, or share tribal knowledge. This pattern is most valuable in team environments where knowledge must propagate across multiple users and sessions.

When not to use: For one-off corrections that aren’t worth persisting, or in contexts where the overhead of review-and-save disrupts flow. The key is that the suggestion must be lightweight — a single confirmation, not a documentation workflow.

Design principles:

Capture at the moment of correction: The user is already articulating the knowledge when they correct the agent. Don’t require them to context-switch into “documentation mode” — capture the correction in place.
Human review before persistence: The agent suggests; the human approves and refines. This ensures quality without requiring the human to initiate.
Scope knowledge appropriately: Not all knowledge is universal. Support scoping — repo-level conventions vs org-wide standards — to prevent context pollution. Backend deployment quirks shouldn’t surface when working on the marketing site.
Suggest updates, not just new items: Conventions evolve. The system should detect when existing knowledge items may be stale and propose updates, not just accumulate new entries.
Multiple input channels: Chat corrections are the most organic source, but also extract from existing structured files (READMEs, rule files) and support manual creation for upfront codification.

For AI PMs: This pattern reframes the “how do we keep agent context current?” problem. Instead of building elaborate update workflows, design the agent’s correction loop to double as a knowledge pipeline. The question shifts from “how do we document our conventions?” to “how do we make it trivial to persist corrections?”

Sources

From: 2026-02-13 Agentic Team Memory Devin

Key quote: “You don’t have to think about documentation while you’re working, you just correct the agent the way you’d correct a teammate, and the system prompts you to persist what’s worth keeping.” Attribution: Nader Dabit (@dabit3), Cognition What this source adds: Demonstrates the pattern at scale in Devin’s multi-user engineering environment. The multi-source approach (chat + repo scanning + suggested updates + manual) is the most comprehensive implementation documented. Scoped knowledge (repo-level vs org-wide) is a practical design detail. Links: Original | Archive

From: 2026-02-13 Everyone Should Use Claude Code More

Key quote: “Give an Agent the responsibility of figuring out how/where our documentation can be better and more comprehensive. Using Claude Code together with Playwright to automatically explore our software independently, identify knowledge gaps in our documentation, and then create those changes itself.” Attribution: James Pember What this source adds: Extends the pattern from reactive (capture corrections) to proactive (agent autonomously identifies gaps). Four independent examples show a spectrum: auto-changelogs from commits (Aggarwal), reverse-built PRDs from code (Salisbury), verbose commits as future agent context (Chandwani), and fully autonomous doc exploration (Pember). Together with the Devin source, this confirms the pattern across both team/product contexts and individual PM workflows. Links: Original | Archive

Filesystem as Agent State — the captured knowledge needs to live somewhere; the filesystem-as-state model provides the storage substrate
Deliberate Context Selection — captured knowledge is only useful if it surfaces at the right time; scoped knowledge application is a form of deliberate selection
Reverse Engineer Judgment Into AI — corrections encode expert judgment; this pattern is a mechanism for systematically extracting that judgment
Agent-Mediated Self-Reflection — Chad Boyda’s pattern (surfacing learnings from Slack) bridges self-reflection and knowledge capture