Lifecycle stage — Build
本番スケールでマルチエージェントシステムを出荷した人はほとんどいません。ノートブックで動くLangGraphデモと、有料顧客のために稼働するシステムとの距離は、他のチームが停滞する場所です。そしてそれは、実際に構築するまで見えない理由で停滞します。これはDEPLOYメソッドのENGINEERおよびPILOTフェーズを、実ユーザーのいるエージェントプロトタイプを工業化する必要のあるチーム向けに12週間の常駐エンゲージメントに凝縮したものです。Auralinkをアーキテクチャから構築しました——170万行の本番コード、約20の自律エージェントが人間の介入なしに78%のインシデントを解決、arXivで査読済み。同等のマルチエージェントシステムは現在本番に存在しません。お客様のチームと私が行う作業は、私が自チームで行ったのと同じ作業で、お客様のコードベース、エージェント、運用制約に適応させます。本番化した8つのAIベンチャーで、どの意思決定を後回しにできるか、どれを今省くとローンチ6週間後に刺さるかを把握しています。
どのエージェントデモもノートブックでは動くが、並行本番トラフィック下では崩壊する。チュートリアルは同期呼び出し、単一のハッピーパス軌跡、モックされたツールを使います。本番では数十のエージェントセッションが並列実行され、それぞれが実際の障害モードを持つ実ツール呼び出しを行い、デモでは綺麗に見えたナイーブなオーケストレーションパターンは、リトライの雷雲、デッドロック、半コミット状態の嵐になります。チームはこれが問題だと認識していますが、解決のためのリファレンスアーキテクチャを持っていません。
単一ターンLLM呼び出しの評価戦略は、マルチステップエージェント軌跡には拡張できない。プロンプトは評価できます。しかし、5ステップ目で誤ったツールを選び、9ステップ目で誤った引数を渡し、最終回答は技術的には正しかった14ステップのプランは、まだ評価できません。エージェント軌跡の障害モードはステップをまたいで複利的に累積し、単一ターン作業の評価メソドロジーは誤解を招くスコアを生みます。軌跡レベルの評価がなければ、モデル更新がシステムを改善したか後退させたかが分からず、自信を持って出荷できません。
各エージェントステップがトークン消費を乗算するため、タスクあたりのコストが予測不能に爆発する。ユーザーの1リクエストがプランを誘発し、ツール呼び出しを誘発し、サブエージェントを誘発し、さらなるツール呼び出しを誘発します。セッションあたりのトークン数は通常のLLM呼び出しの40倍になり、CFOは「なぜある1人のパワーユーザーが先週火曜に18ユーロ分のトークンを消費したか」を説明するモデルを求めます。それに答える計装がありません——ステップごとのトークン会計なし、簡単なステップに安いモデルを選ぶルーティングロジックなし、セッションが暴走した時に優雅に失敗する予算上限なし。
本番でエージェントが何かを誤った時、どのステップ、どのプロンプト、どのツール呼び出しが原因かを教えてくれるオブザーバビリティスタックがない。ユーザーは「エージェントが変な回答をした」と苦情を言います。ログは最終応答しか示しません。エージェントは非決定論的なので軌跡を再現できません。バグがプランナー、ツールルーター、検索レイヤー、または特定のプロンプトテンプレートにあるのか判別できません。すべてのインシデントが数日がかりのフォレンジック作業になり、チームはユーザーより先にシステムへの信頼を失います。
エンゲージメントは4つの3週間フェーズで進行します。エンジニアリングチームに常駐し——御社のエンジニアが構築し、私はAuralinkからのトポロジー意思決定、評価メソドロジー、オブザーバビリティパターンを持ち込みます。コンサルティングスライド上での作業はありません。第12週末には、チームが私なしでシステムを運用しています。
現行プロトタイプを深く掘り下げます——エージェントグラフ、ツールインベントリ、状態管理、すでに遭遇した障害モード。書面のトポロジー設計を作成します: どのエージェント、どの責務、どの通信パターン、どの状態境界、どの障害分離ゾーン。この設計はブログ記事からコピペしたリファレンスアーキテクチャではなく、お客様のドメインとコードベースに特化したものです。第3週末には、チームはシニアレビュアーに対して防御可能なブループリントと、書き換えを要さない現行プロトタイプからの移行パスを持ちます。
御社のエンジニアがトポロジーを実装します。私は難しい判断——オーケストレーションプリミティブ、並行戦略、長時間セッション用の状態マシン、ツール障害時のリトライと補償ロジック——で並走します。第7週のビッグバン切り替えではなく、第5週から実トラフィックに対して段階的にリリースします。第7週末には、新トポロジーが本番トラフィックに対応し、旧プロトタイプは廃止されています。
Auralink向けに開発したパターンに基づく軌跡レベル評価——ステップごとの評価、回帰テスト用の正解軌跡、キャリブレーション済みプロンプトによるLLM-as-judge、そして「新しいバージョンの方が良く感じる」ではなく「このモデル更新はシステムをp < 0.01で4.2%改善した」と言える統計メソドロジー。CFOが将来尋ねる質問に答えられるよう、ステップごとのトークン会計とタスクあたりコストダッシュボード。第9週から、チームが全変更に対して評価を実行します。
午前3時にページャーが鳴った時にオンコールエンジニアが使うオブザーバビリティスタック——ユーザーセッションに紐づいた軌跡トレース、ステップごとのプロンプトと補完、ツール呼び出しの入出力、トークン会計、レイテンシの内訳、コスト帰属。システムが生み出す上位10種類のインシデントに対するランブック。アラート閾値、ダッシュボード、インシデント対応プレイブックをSREチームがオーナーシップを持つための作業セッション。私が去った時、チームがシステムを運用します。リテーナーなし、継続的依存なし。
実ユーザーがいるエージェントプロトタイプ、12週間の常駐エンゲージメントの予算、ハンドオフ後にシステムをオーナーシップするキャパシティのあるエンジニアリングチームを持つエンタープライズ技術組織およびシリーズB+スタートアップ。CTOまたはVPエンジニアリングが既に「エージェントデモは動く」と「エージェントシステムが運用される」の間の壁に当たり、そのギャップがトポロジー問題、評価問題、オブザーバビリティ問題であり、プロンプトエンジニアリング問題ではないと理解しているプロダクトチーム。LLM本番経験のないチーム向けではありません——そのようなチームはまずレディネス監査か戦略スプリントが必要です。既存のコードベースがないチーム向けでもありません。このエンゲージメントは工業化するプロトタイプの存在を前提とし、ゼロからのグリーンフィールド構築ではありません。
大きくはありません。オーケストレーションフレームワークは乗り物です——重要な意思決定はトポロジー、状態管理、評価メソドロジー、オブザーバビリティです。主要なフレームワーク全般、およびカスタムオーケストレーションコードにわたって作業してきました。第1週で、現行フレームワークが目指す場所への適切な乗り物かどうかを評価します。答えが「はい」ならその上に構築し、特定のボトルネックが移行を支持するなら移行します。マーケティングの良さではなく、証拠に基づいて判断します。
2026年に雇うシニアAIエンジニアは、おそらく本番マルチエージェントシステムを出荷したことがありません。ほぼ誰もしていないからです。私は1度実行しました——170万行のコードと78%の自律解決で。そのパターン認識は契約市場にまだ存在しません。御社のエンジニアが実装を行い、私はトポロジー意思決定、評価メソドロジー、オブザーバビリティパターンを持ち込みます。さもなければ、彼らは学ぶのに3イテレーションと12ヶ月かかります。私が去る時、チームはすべてをオーナーシップし、私を再度必要としません。
できません。エージェントトポロジー、評価ハーネス、オブザーバビリティは、それぞれ適切に行えば3週間の問題で、雑に行えば1週間の問題です。圧縮版は動くまで動くシステムを生みますが、4ヶ月目のデバッグコストは1ヶ月目のコンサルティング節約を超えます。12週間がないのであれば、適切なエンゲージメントはパイロット・トゥ・プロダクション・ハードニングサービスで、フルトポロジー再設計なしで本番対応作業をカバーします。適合するなら正直にそれをお勧めします。
ほとんどありません。私が実施したエンゲージメントでは、トポロジー設計は既存コードの60〜80%を保持し、オーケストレーションレイヤー、状態境界、障害分離パターンを変更します。チームが書いたビジネスロジックは通常問題ありません。変更が必要なのは、エージェントがどのように協調し、状態がどのように管理され、障害がどのように扱われるかです。フル書き換えは、コードを読みたくないコンサルタントのサインです。私は御社のコードを読みます。
Auralinkの本番システムから測定された数字で、arXiv論文で報告されています。エージェントプールに割り当てられたインシデントの78%が人間のループなしに解決されます——エンドツーエンドで解決するケースだけでなく、エージェントが正しくエスカレーションするケースも含みます。測定メソドロジーはエンゲージメントで持ち込むものの一部です。私が作業した全チームは異なる数字になります。タスクプロファイルが異なるからです。重要なのは78%を再現することではなく、本当の数字を教えてくれる測定インフラを構築することです。
30分で状況を診断し、このサービスが合うかどうか正直にお伝えします。合わなければ、何が合うかも。