Memory tuning

Last updated

Argus remembers things across reviews. Confirmed patterns, known scenarios, dismissed findings, per-file synthesis — all of it feeds back into future reviews as context. The match is semantic, not exact text: a similarity score between 0 and 1 gates whether each memory influences a review.

Four of those gates are tunable per-org, plus one toggle that controls long-term cleanup. Defaults work for most teams. Tune when you observe specific failure modes in your reviews.

Settings marked Proonly affect reviews on the Pro plan (deep-review specialists, scenarios, simulation). Free-tier installations can view and set them, but the associated pipeline stages don't run.

Where to tune

Open Settings from the dashboard sidebar and switch to the Memory tab. Changes apply to the next review. An overridden field shows an amber border and a delta chip; reset to default via the circular-arrow icon next to each control.

Thresholds

Each gate is a similarity cutoff in [0, 1]. Higher = stricter (fewer but more relevant matches). Lower = more permissive (more context, more noise).

finding_enrich

Default 0.50. Controls whether a pattern match enriches a review comment with "we've seen this before" context.

  • Raise (e.g. 0.65) if you see unrelated patterns cited on unrelated findings — the match is too loose.
  • Lower (e.g. 0.40) if you have a mature pattern library but reviews rarely cite anything — the gate is too strict.

specialist_minPro

Default 0.60. Server-side similarity cutoff for the deep review specialists (bug hunter, security, architecture, regression). Controls which patterns/scenarios/feedback they see per file.

  • Raise if specialist prompts feel noisy — irrelevant past findings diluting the signal.
  • Lower for small repos where the pattern library is still thin and you want specialists to reach further.

scenario_triggerPro

Default 0.75. When a simulation fails against a known scenario, this is the minimum similarity for it to count as "triggered" and bump the scenario's trigger count (used to prioritize long-standing issues).

  • Raise if scenarios are getting credit for tangential simulation failures.
  • Lower if known scenarios are clearly related to failures but not being counted.

scenario_dedupePro

Default 0.85. When a new candidate scenario is extracted, any existing scenario above this similarity counts as a duplicate and the new one is skipped.

  • Raiseif you're seeing distinct scenarios silently merged.
  • Lower if your scenarios list has obvious duplicates accumulating.

Shared-container retirementPro

Some patterns apply across every repo in your org — conventions auto-learned from developer replies, for example. Those live in a shared container that, without any cleanup, would grow forever. One bad pattern from a single developer's reply could silently influence every review across every repo indefinitely.

A nightly reconciler decays dormant shared patterns by age and writes the decayed confidence back to each doc, so a pattern fades out of reviews before it is finally deleted:

  • Day 0–30: grace window — full confidence 1.00, no decay.
  • Day 30+: confidence decays 0.05 per week of dormancy, always measured from the base 1.00 (never compounded), and the reconciler writes the new value back to the doc each night.
  • Below the 0.30 retrieval floor (~14 weeks past grace, ≈4 months) the pattern stops influencing reviews — it is still stored and recoverable, just no longer surfaced.
  • At or below 0.20 (~16 weeks past grace, ≈4.7 months of unbroken dormancy) the reconciler deletes it.
  • Re-learning — the pipeline extracts the same pattern again — resets confidence to 1.00 and restarts the clock. The reconciler's own nightly write-back does not: it anchors the decay to the original timestamp, so aging keeps progressing until a genuine re-learn.

disable_shared_decay — toggle this ON to keep everything in the shared container forever. Default OFF. Useful for regulated industries where pattern deletion needs a human in the loop, or for orgs early in their Argus rollout where you want to observe accumulated patterns before any retire.

How to know it's working

The scenario_triggergate emits a structured log line each time it's evaluated in the pipeline:

INFO threshold_check name=scenario_trigger value=0.81 threshold=0.75 passed=true

Trace these in your observability stack after changing scenario_trigger. If passed=true on every check the threshold is too low; if passed=false on every check, too high.

finding_enrich and specialist_minare applied server-side as similarity cutoffs on the memory search itself, so they don't emit a per-check log line. Validate those by watching review output — how many past patterns and findings get cited — rather than by grepping logs.

Safe defaults

If you're unsure, don't tune. The defaults are chosen to work well on mid-sized repos with a moderate pattern library. Start with defaults, observe for 2–3 weeks, then tune only the specific gate that's misfiring.

Settings are per-installation. Cross-repo overrides (per-repo threshold tuning) are on the roadmap but not yet shipped — today all repos under one installation share the same gates.