Memory for a coding agent

Good project memories explain why a convention exists, record a verified development command, or point to the architectural decision behind an unusual boundary. They should be concise enough to retrieve and specific enough to validate. A path, commit, issue, or documentation URL gives the next session somewhere to check before treating the memory as current.

Avoid storing generated guesses as settled project facts. Build output, branch state, package versions, and test counts can change quickly and are cheap to re-read. Memory may help the agent know which file or command to inspect, but the working tree and current tool output should decide what is true now.

Use a stable entity ID for the unit whose context should travel together. A small product may use one project scope. A larger organization may separate repositories, services, or environments to keep conventions from leaking across unrelated work. If an agent works across multiple scopes, select them deliberately for each task rather than merging every memory into a global profile.

The application or MCP host should derive the permitted scope from the authenticated workspace and current task. Remembering a deployment procedure does not grant permission to deploy, and remembering a file path does not authorize a write. Keep memory retrieval separate from tool grants, approvals, and code review so useful context never becomes ambient authority.

At task start, recall a small set of project conventions and decisions related to the request, then verify them against current files. During work, prefer live repository search for exact APIs and configuration. At task end, retain only durable lessons that passed review: a new convention, a resolved incompatibility, or a pointer to a decision record.

Aether documents an MCP connector for compatible tools as well as direct language SDKs. Choose the integration that fits the host you control. In either case, record what was recalled and what new memory was written so a maintainer can distinguish stored context from code evidence and undo a bad memory without reverting unrelated source changes.

Write down which categories may be retained, who can correct them, and when they expire. Exclude secrets, credentials, unreviewed vulnerability details, and temporary branch state. Prefer references to repository documents over copying large source files into memory. If the source changes, the reference encourages a fresh read rather than returning stale code as an answer.

Test a known convention, a superseded decision, two repositories with similar names, and a request that should return no memory. Score whether recall found the right pointer, then separately score whether the coding agent verified it before editing. The safest success condition is not that the agent remembered more; it is that the agent reached correct, reviewable work with less repeated discovery.