Mem0 Agent Rules: AGENTS.md Explained

Overview

Mem0's packages use different languages, formatters, and tests, so the root guide starts with a routing table. A second table maps changes to required deliverables, followed by rules for accepted issues and contributor accounts.

Nested instruction files Hard prohibitions Verification by change type Contribution etiquette

Documents

├── 
├──  · symlink → AGENTS.md
├── .github
│   ├── ISSUE_TEMPLATE
│   │   └──  — Matching issue form
│   ├── 
│   ├──  · symlink → AGENTS.md
│   └── 
├── cli
│   ├── node
│   │   ├── 
│   │   └──  · symlink → AGENTS.md
│   └── python
│       ├── 
│       └──  · symlink → AGENTS.md
├── docs
│   ├── contributing
│   │   ├── 
│   │   └── 
│   ├── 
│   └──  · symlink → AGENTS.md
├── integrations
│   ├── 
│   └──  · symlink → AGENTS.md
├── mem0
│   ├── 
│   └──  · symlink → AGENTS.md
├── mem0-ts
│   ├── 
│   └──  · symlink → AGENTS.md
├── server
│   ├── 
│   └──  · symlink → AGENTS.md
├── skills
│   ├── 
│   └──  · symlink → AGENTS.md
├── tests
│   └── 
├── 
├── 
└──

Techniques in this file

01 / Nested instruction files

Route by the edited package before running tools

The opening requires reading the nearest instructions and explains that line lengths, linters, and test runners differ. The routing table makes those differences visible before an agent applies a root-level default.

8This is a polyglot monorepo and **every package sets its own rules**. Read the `AGENTS.md` nearest the files you are editing before running any command. The linters, formatters, test runners, and line lengths genuinely differ per package, and using the wrong one fails CI or produces a diff full of noise.

02 / Hard prohibitions

Explain a filename-sensitive workflow restriction

The Do NOT section requires maintainer approval for workflow changes. It ties that restriction to publishing credentials pinned to workflow filenames, giving the rule a concrete operational reason.

14- Modify anything in `.github/workflows/` without explicit maintainer approval. Publishing credentials are pinned to workflow filenames.

03 / Verification by change type

Map change types to supporting evidence

The shipping table distinguishes bug fixes, features, integrations, providers, and refactors. Bug fixes require a regression that fails without the change; public features also require docs and discovery updates.

105| **Bug fix** | A regression test that fails without the fix, written first. The fix. The relevant suite passing. The package's linter run. |

04 / Contribution etiquette

Separate change readiness from account recognition

The contribution section explains two independent gates. It states that being vouched does not bypass accepted-issue requirements, while absence from the list does not itself block a newcomer.

139Being vouched grants nothing. It is a "we have seen this person before" flag that mutes the newcomer comment, not permission to skip the accepted-issue rule. Being absent from the list costs nothing.

05 / Contribution etiquette

Describe recovery instead of encouraging gate bypasses

An unaccepted issue can close a PR automatically, and maintainer acceptance reopens it. The guide tells agents not to create duplicate submissions or manually work around that state machine.

141If you are an agent opening a pull request on someone's behalf, the practical consequence is one rule: **get the linked issue labelled `accepted` before you open the pull request, or expect the pull request to be closed and to reopen later.** Do not work around either gate, do not reopen a gated pull request by hand, and do not re-file the same change under a new pull request when one is closed.