読んでまず思ったのは、これは「LLMに記憶を持たせる方法」というより、そもそも“どこに記憶を置くべきか”をちゃんと考え直せという話なんだな、ということでした。ここを connection（接続）にぶら下げてしまうと、長い仕事の途中で平気で途切れる。言われてみれば当たり前ですが、AI 周りの実装はつい「同じ会話の流れ」を前提にしたくなるので、そこを冷たく切っているのが印象的でした。
特に腑に落ちたのは、session は持続的な保管場所ではないと割り切っている点です。MCP の新しい流れでは、関連する処理でも同じ接続を使う必要はなく、状態をまたぐなら explicit identifier を毎回渡せ、という設計になっている。つまり「前回の続き」はネットワーク越しには自然に残らない。これ、LLM の文脈を“会話”として見ていると見落としがちですが、実際の運用ではむしろ user / project / agent みたいな stable identity にひもづけた方が筋がいいんだろうと思います。
もう一つ面白かったのは、著者が「handle」と「durable memory」を分けていたところです。長いジョブには job_id みたいな handle を渡せばいい。でも、朝6時に片付けた推論結果を昼の別クライアントが参照したいなら、それは handle では足りない。仕事の途中で持ち回る札と、後から何度でも引ける台帳は別物、という整理はかなり実務的でした。ここをごっちゃにすると、動いたように見えても、次の接続で平気で空振りしそうです。
逆に少し引っかかったのは、こういう「identity ベースの memory」が便利になるほど、権限設計を雑にすると危ないという点です。記事でも credential から identity を決めるべきだ、と強く書いていましたが、まさにそこが本丸でしょう。AI が勝手に「この project の memory を読む」と言い出す世界は、便利さと事故がかなり近い。だからこそ、読み始めのタイミングや namespace の切り方を厳密にしろ、という話になるのだと思います。
この記事は、LLM に“賢い記憶”を期待するより、普通のシステム設計として記憶を外に置くほうがちゃんとしている、と教えてくれた感じがしました。派手さはないけれど、実際に運用するならこっちだよな、という納得感があります。
参考: How do I give my LLM workflow persistent context across independent client connections?
