Dedupe And Memory

The four states

Every scout classifies each candidate finding against prior runs, the inbox, and the scratchpad before authoring a report. Bake this classifier into the scout’s Decide section:

1. Net new — no prior run mentions the topic, no inbox report and no scratchpad entry covers it. → Author a report via emit_report if it clears the report bar (see report-contract.md).
2. Material update on an existing live report — a live report already covers the topic (one this scout authored last run, or a pipeline report), but there’s new evidence (a different corroborating source, a fresh deploy correlation, contradicting data, a meaningful escalation in scope). → edit_report it — use append_evidence for the new observation, append_note for a reading of it, or rewrite title/summary on a report the scout authored. Don’t mint a near-duplicate. Live reports only: edit_report never changes a report’s status, so if the prior report is suppressed or resolved and the issue is genuinely back, author a fresh report (citing the prior report_id in the summary) rather than editing a closed one nobody will see.
3. Same fact already covered — an existing report already captures the same evidence shape, nothing has changed. → Skip. Optionally rewrite a scratchpad entry confirming the topic stayed quiet.
4. Already-addressed or noise — a scratchpad entry with an addressed: / noise: / dedupe: prefix names the entity with a “team aware” note. → Skip; note it in the run summary.

Scratchpad memory

The scratchpad is durable, per-team prose keyed by string. It has no tags: the category is encoded in the key prefix so a future run finds an entry with a single text= search. Re-using a key rewrites the entry in place (the idempotent refresh — use it to confirm a quiet observation without duplicating entries). An entry can carry an optional expires_at: expired entries drop out of searches (unless include_expired=true) and a daily janitor deletes them two weeks past expiry, so set it on anything with a natural shelf life (a watch: on a live issue, a cursor) and leave baselines and allowlists unexpiring.

One keyspace, several writers. Every scout on the team shares it, and so do the two report-pipeline stages: the research run and the self-driving implementation run. Each search result carries created_by_skill, which reads a scout’s skill name for a scout entry and pipeline:report-research or pipeline:implementation for a pipeline one. It names the entry’s original creator only: a rewrite of an existing key keeps the creator, so the field does not say who last wrote the content, and the current writer of a shared key is unknown. Two rules follow. Search the identity of the thing (the issue id, the flag key, the file path) rather than only your own prefix, or you find your own past work and nothing else. And only ever forget keys under your own prefix that you created: scout-scratchpad-forget deletes by exact key without checking the writer, so removing another writer’s cursor or dedupe: row, or a key of yours a sibling has since taken over, makes it repeat work or lose its place.

Format: <prefix>:<domain>:<entity> — e.g. pattern:error_tracking:baseline, noise:logs:rabbitmq-deploy-window, dedupe:csp_violations:a1b2c3d4. The self-driving implementation run writes here too, under pattern:impl:<repository>:<area>, recording what it worked out about that repository while acting on a report. Each canonical specialist has its own <domain> label (error_tracking, logs, llm_analytics, experiments, feature-flags, session-replay, web-analytics, pipelines, health, …) — not a closed set. A new scout introduces its own domain label and reuses the prefixes; match the label a surface’s existing entries already use.

When to author a report vs. write memory

What a good entry looks like

Good entries are future-run actionable — the next scout reads them and changes behavior:

Why it works: dated, names the entity id, gives a clear conditional (“still firing → escalate; quiet → skip”), bounded by a precise time anchor, and the key prefix makes it findable. Bad entry: key note-1, content “we have errors today, FYI” — no actionability, no entity, no condition, uncategorized key the next run can’t find or act on.

Give your scout 2–3 worked example entries scoped to its surface so each run matches the format instead of inventing its own.

Cross-project noise patterns

These are noise across essentially all PostHog projects — list the relevant ones in your scout’s Disqualifiers so it skips them unless there’s a real escalation:

• Single-user, single-session events — one user, one occurrence, no other signal. Almost always a personal browser quirk.
• Dev-environment bursts — high counts whose service / properties.env is dev / local / test. Filter before weighing.
• Sandbox-internal errors — Docker TimeoutExpired, sandbox sync failures, agentsh errors. Internal harness operations, not user-facing.
• Single-session frontend state quirks — e.g. KEA store-path errors; not user-impacting unless distinct-user counts climb.
• Known upstream provider errors — Anthropic / OpenAI rate limits, third-party outages already covered by past memory. Don’t re-file unless volume or shape changes meaningfully.

The team’s scratchpad extends this list per-project as the scout learns — which is exactly why the save-memory discipline matters.