What AGENTS.md is good at
- Defining process expectations for agents.
- Specifying command sequences and completion criteria.
- Enforcing style, test, and review norms.
What AGENTS.md does not store by itself
- Decisions made in a specific coding session.
- Work logs tied to file-level changes.
- Follow-up tasks discovered during implementation.
- A current summary of project status.
AGENTS.md defines the policy. Sidecar is the storage layer that policy writes to.
A minimal AGENTS.md memory contract
drop-in template markdown
# Required workflow for code changes
1) sidecar context --format markdown
2) implement changes
3) sidecar worklog record --done "<what changed>" --files <paths> --by agent
4) if behavior/design/architecture changed: sidecar decision record --title "<decision>" --summary "<why>" --by agent
5) if follow-up exists: sidecar task add "<follow-up>" --priority medium --by agent
6) sidecar summary refreshWhy this combination works
Consistent behavior
Each agent run follows the same before/after loop.
Local durability
Records stay in the repo instead of disappearing with chat state.
Human readability
Teammates can inspect decisions and work logs directly.
Agent readability
New sessions can load context from structured records.
Rollout checklist for an existing repo
- Install and initialize Sidecar.
- Add the memory contract block to AGENTS.md.
- Run one real task through the full loop.
- Review output quality with
sidecar context. - Tune prompts and conventions in preferences.
FAQ
What is the difference between AGENTS.md and Sidecar?
AGENTS.md defines how agents should work. Sidecar stores what happened during that work as structured project memory.
Do I need both AGENTS.md and Sidecar?
You can use each independently, but together they are stronger: AGENTS.md enforces process and Sidecar preserves outcomes.
Can this workflow work for teams and solo developers?
Yes. The same repo-local records help solo continuity and team handoffs.