How do you use lessons from human overrides to improve automated memory-compaction remediation policies?

Human overrides should improve automated memory-compaction remediation through a reviewed feedback loop, not by blindly copying operator actions. An intervention is evidence that the controller may have missed a signal, misclassified a bottleneck, chosen an unsafe action, or escalated too late. It is not automatically proof that the human action caused recovery.

Collect overrides → Classify failure patterns → Form hypotheses → Design bounded policy changes → Test on held-out incidents → Shadow/canary → Monitor and learn.

Beginner-friendly production incident

A LangGraph API-test generator uses requirements, test-generation, security-review and publisher agents. Celery workers run compaction jobs and an automated controller responds to congestion.

Over three weeks, operators repeatedly intervene when the controller adds workers during LLM-provider quota exhaustion. More workers lead to more 429 responses and retries, while successful summary throughput remains capped.

The right lesson is not “always scale down.” It is that the controller fails to distinguish local worker saturation from upstream shared quota exhaustion. Engineering should add provider request/token quota signals, restrict scaling during confirmed throttling, and test against both genuine worker shortages and quota incidents.

Step-by-step numerical example

Suppose engineers review 40 human overrides in a month:

1. 18 involved upstream 429s and retry amplification.
2. 10 involved urgent compactions waiting behind reserved background jobs.
3. 7 involved invalid or stale summaries.
4. 5 had uncertain causes.

The groups are mutually exclusive in this illustration.

The team adds a quota-aware remediation rule for the 18 throttling cases, then evaluates on 20 different, held-out quota incidents:

• The previous policy needed manual intervention in 15/20 = 75% of cases.
• The proposed policy needed intervention in 5/20 = 25%.
• The observed absolute reduction is 50 percentage points; the relative reduction is (75−25)/75 ≈ 66.7%.
• But the proposed policy also caused 2 unnecessary admission reductions in those 20 cases.

The new policy may be promising, but fewer manual overrides alone does not prove it is better. Assess the two false mitigations, downstream handoff latency, output correctness, cost, and fairness. These example sample sizes are too small to establish subtle benefits with confidence.

What should each override teach the system?

1. Detection: Which SLO burn, queue age, provider errors, or context-safety evidence triggered intervention? Were alerts late or noisy?
2. Diagnosis: What did the operator believe was wrong? Could provider recovery, other deployments, or traffic changes explain the outcome?
3. Action: What policy changed, at which version, and for which tenant, workflow, or queue? Did the action actually propagate?
4. Safety: Did every agent consume validated, authorized context with complete required event tails and approvals?
5. Side effects: Did background maintenance starve, another tenant lose capacity, or retries increase?
6. Recovery: Did handback succeed, or did a delayed Celery remediation task reapply a stale policy?
7. Evidence quality: Are timelines and traces complete? Is causal attribution verified or uncertain?

Capture incident IDs, policy revisions, job IDs, source watermarks, summary versions, operator approvals, and accepted-workflow outcomes; avoid collecting sensitive raw prompts unnecessarily.

Convert override evidence into distinct improvements

• Better detection: Improve SLO denominators, sample thresholds, and sustained-burn signals after an operator catches an incident early.
• Better classification: Distinguish shared provider quotas, local worker saturation, revision churn, and semantic validation failures.
• Safer actions: Limit blast radius and require reversible actions, spend ceilings, version checks, and expiry.
• Controller stability: Add hysteresis, cooldowns, minimum dwell times, and one authoritative policy writer when overrides expose oscillation.
• Earlier human escalation: Keep high-risk semantic or authorization decisions human-controlled when automated classification is unreliable.
• Better observability: Add missing worker reservation, queue propagation, model retry, or summary-consumption traces when an operator lacks sufficient evidence.

Every improvement should have an owner, an explicit safety invariant, a benchmark case, and a measurable closure condition.

Why not learn directly from operator labels?

Human override records are biased observational data. Operators typically intervene during severe incidents, sometimes with private contextual knowledge that the future controller will not have. They may choose precautionary actions that were unnecessary, and apparent recovery may coincide with provider recovery.

A supervised model trained to imitate every override could repeat mistakes. Start with transparent, approved decision rules. If exploring learned policies, evaluate counterfactual limitations, rare safety failures, uncertainty, and held-out workloads; require a human-reviewed deployment path. Never allow a model to autonomously bypass context-integrity gates or rewrite production control-plane behavior.

How to build a safe feedback pipeline

1. Aggregate overrides by incident signature, root cause, policy version, workload, and verified outcomes.
2. Semantically deduplicate repeated incidents without collapsing different underlying causes into one category.
3. Prioritize by expected harm and confidence. A rare cross-tenant memory read matters more than common low-impact delays.
4. Propose one bounded policy change and identify which evidence is available at decision time.
5. Create replay scenarios from the original incidents, plus held-out cases that differ in source size, queue congestion, provider quotas, and tenant mix.
6. Test both success cases and false positives. Include normal traffic, legitimate worker saturation, intermittent 429s, delayed metrics, and concurrent remediator instances.
7. Verify invariant checks: no unvalidated summary activation, no missing committed events, no authorization bypass, and no outdated policy overwrite.
8. Run shadow decision-making first; then canary with stable workflow-level assignment and predeclared abort gates.
9. Measure accepted-workflow p95 latency, cost, human override frequency, unnecessary interventions, background fairness, and safety incidents.
10. Document policy version, review approval, incident links, observed uncertainty, deployment outcome, and reversion path.

Do not use future incident outcomes as inputs during replay. For example, a controller making a decision at 10:05 must not read a provider recovery that only happened at 10:20.

Example reviewed policy change

An improvement proposal derived from three throttling incidents can state:

• Hypothesis: Sustained 429 responses combined with exhausted global token quota indicate upstream throttling rather than local worker shortage.
• Old failure: Increase compaction workers, amplifying retries and contention.
• Proposed action: Temporarily pause speculative compaction and bound globally admitted model requests, with approved cooldown and quota checks.
• Safety conditions: Preserve complete source events and validated summary references; never skip security approval.
• Counterexample test: When worker CPU/concurrency is saturated but provider quota is healthy, the scheduler must still be able to scale.
• Release plan: Held-out traffic replay, shadow evaluation, limited canary, owner approval, and revision-fenced rollback.
• Acceptance: Fewer genuinely needed human interventions with no meaningful regression in correctness, fairness, or accepted-workflow SLOs.

The thresholds and response actions must be calibrated for the actual production provider and queue system.

LangGraph and Celery integration

LangGraph: Include workflow/checkpoint IDs, policy version, memory-summary version, source watermark, and override incident ID in the execution trace. After any intervention, a resumed node must independently verify its required evidence and approvals. Human-in-the-loop interrupts help collect decisions, but do not make unsafe summaries safe.

Celery: Track logical compaction jobs separately from delivery attempts and retries. Compare ready, reserved, and active jobs with validated completions and provider quota pressure. Idempotent tasks and revision-fenced activation prevent old remediation attempts or compactor results from overwriting newer state.

How do you know the learning loop works?

Measure four outcomes together: fewer justified manual overrides per eligible workflow, better SLO and incident recovery, no memory or security integrity regression, and acceptable false-mitigation, cost, and fairness impact. A controller that merely suppresses alarms or discourages overrides has not improved reliability.

Google SRE's postmortem guidance emphasizes blameless, systematic investigation and follow-through on owned corrective actions. Applying that principle here means learning from the environment and decision process rather than blaming an operator or assuming an intervention was perfect.

Difference from previous lessons

• Q214–215: General multi-agent postmortem and recurring-failure prevention.
• Q247–248: Automated remediation and preventing its feedback loops.
• Q249: Safe human override design.
• Q250: Safe return of authority to automation.
• Q251: Audit and evaluate individual override outcomes.
• This lesson: Transform patterns across reviewed overrides into testable, approved improvements to compaction remediation policies.

In short

Treat human overrides as structured diagnostic feedback, not ground-truth instructions. Turn incidents into bounded hypotheses, test on independent workloads, maintain non-bypassable context safety gates, and use production outcomes to decide whether a policy improvement is real.

Further reading

• Google SRE: Incident Management
• Google SRE: Postmortem Culture
• LangGraph: Interrupts
• Celery: Monitoring