参考
この Stripe の例は Nexus 自体についてではありません。しかし、本気でコーディングエージェントを運用するチームは、すでにコンテキスト引き継ぎが任意ではない規模で動いているという有効なシグナルです。
“responsible for more than a thousand pull requests merged each week.”
Stripe Engineering Blog: Minions + Stripe's one-shot, end-to-end coding agents: Part 2
本当のボトルネック
チームは通常、モデル品質がボトルネックだと考えます。実際には、壊れたコンテキスト移送の方が深刻なことが多いです。同じ設計判断が何度も発見され、同じ失敗が繰り返され、引き継ぎは時間圧力の中で劣化します。
チームが時間を失う場所
セッションのリセット
新しいチャットのたびに、目標、制約、以前の判断を説明し直す必要があります。
ツールの切り替え
過去の判断が引き継がれないと、エージェントを切り替えた瞬間に流れが途切れます。
静的プロンプトファイル
優れた `agent.md` や `claude.md` も、能動的なリコールがなければ長い文脈の中で埋もれてしまいます。
Nexus がどう解決するか
- 1. 判断と作業ログをメモリアトムとして保存します。
- 2. 全履歴ではなく、現在のタスクに関係ある文脈だけをリコールします。
- 3. MCP と API キーで複数エージェントが 1 つのメモリプールを共有します。
- 4. ポリシーと利用状況をプランレベルのガードレール（上限、402 挙動、課金）と一緒に可視化します。
結論
より良いコンテキスト移送は、より良い実行につながります。複数エージェントと頻繁な引き継ぎを運用するチームにとって、メモリの連続性は便利機能ではなく本番要件です。