AI エージェントが永続データ（指示・記録・ドキュメント）を自動保存する仕組みでは、保存の摩擦を一律にせず誤保存時の影響範囲（blast radius）で非対称にすると、低摩擦と安全性を両立できる。

判断基準:

• 毎セッション自動適用されるデータ（恒常的な指示・ポリシー）→ 提案 + ユーザー承認制。一度入ると以後の全セッションに影響するため。承認は会話内で同期的に取れば永続キューは不要。
• 事後に閲覧・編集・削除できる蓄積データ（設計記録・調査結果・手続きメモ）→ 自動保存 + 事後報告。誤保存しても直せるので、確認で会話を止めるコストの方が高い。

状態管理の置き場: 承認待ち・却下・退役などのワークフロー状態は、ローカルキャッシュではなくサーバ側の status カラム（例: active / proposed / retired / discarded）で一元管理する。理由: (1) UI から提案中の状態まで見え、エージェントの動きがブラックボックスにならない、(2) マシン間で状態が分岐しない、(3) キャッシュと DB の突き合わせという恒久的な運用問題を持たずに済む。

重要な落とし穴 — 状態を残すなら類似検索は status で分割する: 却下・退役レコードを保存時の重複チェックと同じ検索空間に無差別に残すと、「過去に却下されたものに似ている」というだけで新規保存が重複扱いで静かにスキップされ、蓄積が却下履歴に汚染されて機能停止する。重複チェックは active のみを対象にし、discarded への照合は「提案を出すか」のゲート判定として分離する（保存処理には影響させない）。フィルタなしの類似検索をリポジトリ層のインターフェースとして公開しないと型で強制できる。

却下の扱い: 却下は物理削除せず discarded 状態 + 却下理由で残すと、同じ提案の再発防止と採用基準改善の材料に転用できる。ただし永久ブロックにはせず、状況が変わったら再提案できる条件（却下時点のシグナル量を記録しておき、大幅に増えたら再点火等）を持たせる。

トレードオフ: サーバ管理はオフライン時に蓄積できないが、エージェント利用はほぼオンラインなので「失敗したら会話内で報告・再試行」で始め、必要になってから送信バッファを足すのが可逆性の高い順番。