The repository is the strongest default system of record for coding-agent decisions because it versions authority beside the code, travels into local and remote workspaces, supports ordinary review, and avoids binding project knowledge to one model or vendor.
Authority should travel with the work
Coding agents operate in different places: a developer laptop, an IDE, a CI runner or a remote worktree. Repository-local records arrive through the same checkout as the source. A separate wiki or chat history may be useful to people, but it is not guaranteed to be present when an agent begins a task.
Keeping the accepted record in Git also makes the governing version explicit. The decision used for a patch can be tied to the same commit as the code being changed.
Review is the trust boundary
A decision becomes authoritative because people review and accept it, not because a model generated or summarised it. Repository workflows already provide diffs, ownership, approval and history. Reusing that boundary makes changes to project authority visible.
Agents can propose a new record or a superseding change, but the accepted state should still pass through the team's normal review process.
Local does not mean isolated
Repository-local records can still be indexed, queried over MCP and checked in CI. Local describes where authority lives, not the absence of interfaces. A language-neutral schema and machine-readable output let multiple clients consume the same record without moving ownership into a hosted knowledge service.
When external systems still matter
Product planning, ticketing and collaboration systems remain valuable inputs. The important distinction is between inbound context and accepted repository authority. An explicit connector can propose or synchronise information, while the reviewed repository record defines what an agent may rely on when changing the code.