要約

  • draft-mo-cats-agent-selection-mapping-00 は、agent sessionのstateを一個のcacheとして扱わず、各要素の存在、再取得、再計算、所在地制約を別々に評価する。
  • 選択は実行ではない。descriptor、resource view、decision record、commitment、handoffを分けなければ、どこで権限と事実が変わったか追跡できない。

「stateがある」という一文は粗すぎる。model-sideのcontextは大きいが再計算できることがある。検索結果は再取得できるかもしれない。planやscratchは小さくても、そこに至るstepを再実行しなければ戻らない。長期memoryは読み取り中心でも、地域外へ出せない場合がある。そしてtool resultは小さくても、非idempotentな操作なら二度と同じ意味で作れない。

30 September 2026付のdraftは、この違いをComputing-Aware Traffic Steeringの選択に入れようとする。Informationalを意図する個人Internet-Draftであり、CATS listの議論材料だ。RFCでもworking-group採択文書でもなく、protocol、encoding、data model、実装報告を定義しない。

対象は一回のrequestではなく、turnとstepを重ねる長いsessionである。draftはlong-horizon、stateful、discrete、heavy-tailedという四性質を置く。placementは秒から分のcostを持つ一方、routing metricはミリ秒で変わる。平均値は遅いtool callを隠し、pauseはstateのretentionを超える。

入力は三層に分かれる。step descriptorは能力、working set、制約、予算、tail目標、許容するdegradation、freshnessを表す。resource viewは同じcandidateのforwarding、computing、storageを見る。selection contextは判断時点、commitment、残りhorizon、stability ruleを持つ。

最初の規則はconstraint firstである。能力tier、context window、memory fit、tenant、jurisdiction、location、真のbudget ceilingはrankのweightではない。満たさないcandidateは除外される。値が欠落、期限切れ、出所不明ならunknownであり、都合よく良好値に変換しない。

これは既存のCATS normalized score記事とは別の境界だ。尺度が共通でも、hard limitを平均へ混ぜれば判断は壊れる。rankはeligible setの内部でのみ意味を持つ。

stateは要素ごとにpresence、residency tier、size、age、retention、retrieval cost、recompute cost、governanceを持つ。とくに非idempotentなtool resultは、単なるaffinityではなくhard requirementになり得る。再取得できる文書と同じhit rateへ畳み込んではならない。

costの時間軸も違う。transferはinstance変更時に一度、storageは要素とstepごと、computeはstepごとに払う。draftの式はtransferとrecomputeの安い方を比較するが、数値は例示にすぎない。重要なのはunitとobserverと代替案を明示することだ。

state affinityは正当なpreferenceだが、sessionを保持する権限ではない。移動が安く、残りstepが費用を回収するならholderは負ける。逆に、空いているtargetでもcontext再構築がsession budgetを食い尽くすなら選ぶべきではない。

判断はadmission、turn/step開始、pause後のwake-up、freshness expiry、持続した改善、constraint risk、tail event、budget threshold、closeで行う。metric updateのたびには動かさない。通常のmoveには最小時間、最小改善、残りhorizonでの純利益が必要で、進行中stepはpreferenceだけでは移さない。

handoffはreserve、transfer/reconstruct、commitの順だ。targetが必要stateをusableにできなければabortし、sourceは使えるまま残す。retryは二重reservationを作らない。ここで初めて、advertisementがcommitmentではないことが実装上の差になる。

失敗時も、preferenceだけを緩め、許可済みdegradationを適用し、eligibleな移動を試し、理由付きでstepを失敗させ、最後にsessionを延期・人手承認・終了する。予算を静かに使い切るretryはfallbackではない。

descriptor、resource snapshot、decision record、commitment、handoff recordは寿命が違う。選択の記録はsteering installもexecutionもoutcomeも証明しない。またinstanceが能力やstateを誇張すれば、観察したいsessionを引き寄せられる。全quantityにcollection time、freshness、source、confidenceが要る。

Lu Hengのreality layersで読むと、意図、観測、適格性、選好、拘束、移動、実行、結果を一つのstatusに潰すことこそ危険だ。「selected」は限定された過去の判断であり、成功という権威ではない。

情報源