実際にリリースされるエージェント
エージェントのハイプサイクルには明確な答えがあります。プロダクション環境でエージェントを活用して成功しているチームは、自律的なスウォーム（群れ）を構築しているわけではありません。彼らが構築しているのは、「退屈な」システムです。
私は1ヶ月間、プロダクションで何が機能しているかを観察しました。パターンは明確です。収益を生んだり時間を節約したりするエージェントは、無限ループを持ちません。それらは観測可能（observable）であり、境界（bounded）が定められています。そして、必要に応じて人間の助けを求めます。
これにより、エージェント・プラットフォームの評価方法が変わります。
プロダクションでエージェントを使用しているチームは、以下に依存しています：
- 手動によるプロンプト構築
- 既製品のモデル
- 人間の介入前に10ステップ以内で制限された実行
これこそがエンジニアリングの規律です。
デモでは、完全な自律性を備えた自己修正型エージェントが示されます。しかし、実際にリリースされるエージェントは見た目が異なります。それらは明示的なゲート（制御ポイント）を使用しています。
カスタマーサービス・エージェントは5ステップを処理した後にエスカレーションします。コーディング・エージェントはテストを実行しますが、レビューなしでコードをマージすることはありません。データ・エージェントはクエリを実行する前に承認を求めます。これらは、機能するアーキテクチャ上の選択です。
成功しているエージェントは、狭く、繰り返しの可能な問題を解決します。返品処理、チケットのトリアージ、コンプライアンス問題のフラグ立てなどです。スコープが狭いということは、失敗が予測可能であり、デバッグが容易であることを意味します。
エージェントをリリースする上で最も難しいのは、それらをより賢くすることではありません。それらを可視化し、ガバナンス（統制）を効かせることです。
チームが失敗する原因は、多くの場合以下の通りです：
- エージェントが失敗したときに、何を行ったのかを説明できない
- 不適切な結果をトレースできない
- コストの境界を設定できない
- ツールの承認を強制できない
- 決定プロセスを理解するためにセッションをリプレイできない
これらはインフラストラクチャの問題です。
プラットフォームを選ぶ際は、質問を変えてください。
- スピードについて問うのではなく、すべての決定とトレースを確認できるかどうかを問うてください。
- モデルのサポートについて問うのではなく、複数のランタイムを1か所からガバナンスできるかどうかを問うてください。
- 自律性について問うのではなく、人間のゲートをどれだけ簡単に追加できるかを問うてください。
勝利するインフラストラクチャは、観測性、ガバナンス、そして制限された自律性を提供します。それはコントロールプレーンです。信頼できるエージェントと、午前3時にプロダクション環境を破壊するエージェントを分けるものなのです。
プロダクションチームは、もはやエージェントを構築できるかどうかを問いません。それらをいかに確実に運用するかを問うのです。
「退屈な」インフラストラクチャが勝利します。
Source: https://dev.to/paultwist/the-agents-that-actually-ship-why-boring-beats-autonomous-49li
Optional learning community: https://t.me/GyaanSetuAi