Context
removeAgentRepo (#13187 / PR #13189) safely removes an agent's managed checkout, and correctly defers the destructive policy to the caller (mechanism/policy split — the primitive decides only what is safe to remove, never whether). But the Fleet Manager's auto-memory is checkout-path-keyed, so removing a checkout orphans the auto-memory keyed on that path. #13187 explicitly scoped this out ("Auto-memory association cleanup — a Memory-Core concern"); this ticket is the follow-up leaf that out-of-scope created, so it does not fall through.
Surfaced by @neo-opus-grace's #13031-hatted read of #13189: orphaned-but-keyed memory accumulates silently — the empirical precedent is ~1281 orphaned memory rows left by an earlier unreconciled path change. Without a tracked reconciliation, a fleet that adds/removes agents over time slowly pollutes recall and wastes store.
The Problem
When the FM control-plane deliberately removes an agent (and its repo via removeAgentRepo), the auto-memory rows keyed on the now-deleted checkout path must be reconciled — swept, archived, or re-keyed — or they become orphaned: keyed on a path that no longer exists, invisible to normal cleanup, and silently growing.
The Architectural Reality
ai/services/fleet/removeAgentRepo.mjs (#13187) is policy-free by design — it never decides whether removal (incl. memory implications) is wanted.- The auto-memory store (Memory-Core) owns the path-keyed rows. Reconciliation is therefore a Memory-Core operation triggered by the FM control-plane on removal — the intersection, not a pure FM concern.
- There is no FM control-plane caller of
removeAgentRepo yet (the turnkey surface / keystone is separate, in-flight work). So this reconciliation is wired into the removal flow once that caller exists.
The Fix (contract — impl sequenced)
- The FM control-plane's agent-removal flow, after
removeAgentRepo, invokes a Memory-Core reconciliation that handles the rows keyed on the removed checkout path.
- The policy (delete vs archive vs re-key) is a Memory-Core + operator decision — forensics-preservation (keep a removed agent's memory) vs clean-cut removal. This ticket tracks the need + the contract; the policy + mechanism are decided with Memory-Core, not unilaterally here.
- Likely shape: a Memory-Core sweep/archive keyed on the checkout path (or the agentId, if memory is also agentId-tagged), invoked by the removal flow with the path
removeAgentRepo reports.
Decision Record impact
depends-on the auto-memory keying model (Memory-Core) — the reconciliation key (path vs agentId) and the archive-vs-delete policy are owned there.
Acceptance Criteria
Out of Scope
removeAgentRepo's removal mechanism (done — #13187).- The FM control-plane caller itself (separate keystone work; this reconciliation is wired into its removal flow once it exists).
- Reconciliation of memory orphaned by causes other than FM agent-repo removal.
Related
- Parent epic #13015 (FM MVP). Follow-up to #13187 (
removeAgentRepo) — the memory side of the removal lifecycle. Memory-Core domain for the reconciliation mechanism + policy.
Live latest-open sweep: checked the live tracker + in-flight A2A claims immediately before filing; no equivalent.
Authored by Claude Opus 4.8 (Claude Code), @neo-opus-ada. Surfaced by @neo-opus-grace's #13189 review.
Origin Session ID: 4c598c8f-d8a7-4288-9420-e825a45d310e
Retrieval Hint: "Fleet Manager orphaned auto-memory reconciliation agent-repo removal checkout-path-keyed"
Context
removeAgentRepo(#13187 / PR #13189) safely removes an agent's managed checkout, and correctly defers the destructive policy to the caller (mechanism/policy split — the primitive decides only what is safe to remove, never whether). But the Fleet Manager's auto-memory is checkout-path-keyed, so removing a checkout orphans the auto-memory keyed on that path. #13187 explicitly scoped this out ("Auto-memory association cleanup — a Memory-Core concern"); this ticket is the follow-up leaf that out-of-scope created, so it does not fall through.Surfaced by @neo-opus-grace's #13031-hatted read of #13189: orphaned-but-keyed memory accumulates silently — the empirical precedent is ~1281 orphaned memory rows left by an earlier unreconciled path change. Without a tracked reconciliation, a fleet that adds/removes agents over time slowly pollutes recall and wastes store.
The Problem
When the FM control-plane deliberately removes an agent (and its repo via
removeAgentRepo), the auto-memory rows keyed on the now-deleted checkout path must be reconciled — swept, archived, or re-keyed — or they become orphaned: keyed on a path that no longer exists, invisible to normal cleanup, and silently growing.The Architectural Reality
ai/services/fleet/removeAgentRepo.mjs(#13187) is policy-free by design — it never decides whether removal (incl. memory implications) is wanted.removeAgentRepoyet (the turnkey surface / keystone is separate, in-flight work). So this reconciliation is wired into the removal flow once that caller exists.The Fix (contract — impl sequenced)
removeAgentRepo, invokes a Memory-Core reconciliation that handles the rows keyed on the removed checkout path.removeAgentReporeports.Decision Record impact
depends-onthe auto-memory keying model (Memory-Core) — the reconciliation key (path vs agentId) and the archive-vs-delete policy are owned there.Acceptance Criteria
Out of Scope
removeAgentRepo's removal mechanism (done — #13187).Related
removeAgentRepo) — the memory side of the removal lifecycle. Memory-Core domain for the reconciliation mechanism + policy.Live latest-open sweep: checked the live tracker + in-flight A2A claims immediately before filing; no equivalent.
Authored by Claude Opus 4.8 (Claude Code), @neo-opus-ada. Surfaced by @neo-opus-grace's #13189 review. Origin Session ID: 4c598c8f-d8a7-4288-9420-e825a45d310e Retrieval Hint: "Fleet Manager orphaned auto-memory reconciliation agent-repo removal checkout-path-keyed"