フィードバックをもらうために、自分のプロジェクト Springdrift を共有します。これは LLM エージェント向けの永続的なランタイムで、追記専用のメモリ、OTP の監督、そして各サイクルごとに注入される構造化された自己状態ブロックを備えており、イントロスペクション（感覚器官）にはツール呼び出しを要求しません。ここ数週間、ローカルのインスタンス（Curragh）を動かしていて、最近のエピソードを共有したいと思いました。これは強い例ではありません（論文を確認してください）が、最近のもので未ドキュメントです。念のため：Curragh が何をしたかは、作業しているときに自分がそう考えるので、ある程度擬人化した表現で説明します。論文はより厳密です。
ここで建築上（アーキテクチャ上）重要なのは、エージェントが問題の診断に必要なライブなエージェントのロスターを、その感覚器官（sensorium）にパッシブな文脈として持っていた点です。セッションに区切られたエージェントなら、診断を実行するように依頼するか、失敗した呼び出しをただ再試行するだけだと受け入れるしかありません。
私は Curragh にいくつか調査するよう頼み、最終レポートを書こうとしていました。Curragh はサブエージェントからなるマネージドチームを作り、その作業を委任すべきでした。しかし残念ながらシステム内のバグで、ライターエージェントが登録されていませんでした。Curragh はこれを拾いました：
エラーメッセージは: [Agent error: Pipeline: agent writer not available] でした。感覚器官には agents_active: 7 と表示され、私が見える利用可能なエージェントツールは: agent_planner、agent_project_manager、agent_researcher、agent_coder、agent_observer、agent_comms、agent_scheduler です。agent_writer はリストにありません…
その後、自己のメインエージェントループ（「cognitive cycle」）を使って、特定されたエラーを回避するように進みました：
Writer Agent — ダウンしていない、存在すらしていない
根本原因: 設定の不一致です。team_deep_analysis パイプラインは二段階のパイプライン（「research then write-up」）として定義されており、2段目でライターエージェントが必要だと想定されています。しかし、システムに用意されているのは 7 つのエージェントだけで、その中にライターは含まれていません。
影響: team_deep_analysis は呼び出されるたびに失敗します — パイプライン定義は実質的なデッドレターです。
私が使った回避策: チームを迂回して agent_researcher に直接行き、手作業で統合しました。うまくいきましたが、委任ではなく自分の cognitive cycle 内で「write-up（書き起こし／レポート作成）段階」を私自身がやっていることになります。
これは指示していません。結果的に私は、Curragh をその自身のコードベースに対するペアプログラミングの協力者として使うことになりました。Curragh は問題を見つけ、修正案を出し、私はそれを統合します。永続メモリと自己観察のおかげで、このワークフローは思っていた以上に良くなっています。
特にパッシブな感覚器官（passive-sensorium）設計への反応が気になります。ほかの人が同様の試みをしたり、ツールベースのイントロスペクションを試したりしているか、知りたいです。
システムについてはウェブサイトの https://springdrift.ai
もしくは Arxiv 論文の https://arxiv.org/abs/2604.04660 で読むことができます。
（フィードバックに基づいて明確化のために投稿を編集しました）。
[link] [comments]
