Start from what the team already knows

Project memory is curated knowledge the Sazabi agent and your teammates rely on: architecture notes, what normal looks like, runbooks for recurring problems, and write-ups of past incidents. Reading it first saves rediscovering known causes. Writing to it keeps the next person from starting over.

0. How the tools work

The Sazabi MCP server lists only two tools, search and execute. Browse Sazabi's operations with search and namespace: "sazabi" (an empty query without a namespace lists connected connectors, not Sazabi operations). Before calling one, repeat search with namespace: "sazabi", the hit's full name as the query, and includeInputSchema: true to load its arguments. Then run it with execute as { name, arguments }, the name copied from the hit (for example sazabi/logs.ask). Memory operations: sazabi/memory.search, sazabi/memory.list, sazabi/memory.create, sazabi/memory.update.

1. Read first

Before investigating, run sazabi/memory.search for the service, the symptom and the error. Open matching runbooks and incident notes. Follow a runbook's steps when it fits, but check it against the current code and logs: memory can be stale, and a runbook for last year's architecture is a lead, not an order.

2. Write only what lasts

After the work is verified, decide if anything is durable:

• Worth writing: a root cause that could recur, a runbook for a procedure you just did by hand, a fact about the system that took effort to find.
• Not worth writing: raw logs, guesses, one-off findings, anything that will be wrong next week, secrets.

Use clear paths: runbooks/<topic>.md with kind runbook, or notes/investigations/<topic>.md with kind note.

3. Create or update, never clobber