主なポイント
- センスはコンテキストから生まれます。 モデルはすでに良いコードを書きますが、あなたの会社らしい作品を作らせるには、デザイナーの原則、AIスロップ（低品質生成物）へのガードレール、そしてフィードバックの背後にある理由を与える必要があります。
- エージェントにデザイナーのコンピュータを与える。 Slackのスレッドごとに専用のサンドボックスが用意され、エージェントはターン間でプロジェクトを保持しながら、動画エンジン、画像ツール、共有キャンバスを横断して作業し、自らのレンダリング結果を検査できます。
- モデルが向上したらルールを削除する。 モデルの弱点を補うためのルールには賞味期限があります。モデルが改善されるにつれて、デザイン原則は残しつつ、回避策は取り除いていきましょう。
- 長時間実行するエージェントにはマルチプレイヤーUXが必要。 大きなジョブは非同期のサブエージェントで数時間実行されるため、Slackスレッドには計画、リアルタイムの進捗、そしてリリース前の承認が表示され、チームの誰もが実行中のエージェントを途中で誘導できます。
- フォークして利用できます。 オープンソースのリポジトリには完全なハーネスが含まれており、Managed Deep Agents でチームのSlackにデプロイできます。
上記のプロモーションはContent Studio、つまり私たちのデザインエージェントによって作成されたもので、Slackでのたった一つのプロンプトから、動画、ソーシャルグラフィック、再現されたUI画像、スライドデッキなどを生成できます。エージェントが生成するすべてのアセットはコードで書かれています。
Content Studioは完全に社内で、 Managed Deep Agentsの上に構築されました。現在では社内で最も広く使われているGTMエージェントの一つですが、最初からそうだったわけではありません。初期のフィードバックは……決して良いものではありませんでした。
では、どうやってこれほど低い品質からここまで到達したのでしょうか？
私たちは4か月かけてContent Studioに私たちのセンスとデザイン原則を教え込みました。その大部分は、会社全体の前で間違いを犯すのを見守ることによってでした。
この記事では、GTM Engineeringチームがデザインチームと協力してContent Studioをゼロから構築した過程を紹介します。私たちにとって良いデザインとは何か、エージェントにどうやって私たちのセンスを教えたか、そして静止画からローンチフィルムまで何でも作らせるハーネスについてです。
私たちはデザインエージェントをオープンソース化しました。 オープンソースの リポジトリをフォークし、ブランドトークン、フォント、スキルを追加して、にブランドのトークン、フォント、スキルを追加し、あなたのチームのSlackにデプロイしましょう でチームのSlackにデプロイしましょう。.
その後、10月28日の GTM Engineering Live 10月28日にご参加ください。ハーネスとUXの内部を掘り下げ、この記事に収まりきらなかった成果物もご紹介します。
スケールするデザインエージェントの構築
LangChainはスピードが速い会社です。常にプロダクトローンチキャンペーン、ウェビナー、ブログ、イベントが行われています。それぞれの取り組みには、ブログヘッダーや図から、デッキ、動画、広告クリエイティブまで、さまざまなアセットが必要です。デザインチームは限界まで忙しく、繰り返しの依頼がより戦略的で革新的な仕事を圧迫していました。リーンなスタートアップとして、会社の誰もが高品質でブランドに沿った作品を作れる、摩擦の少ない方法が必要でした。
これらのニーズに応えるため、私たちはSlack上で動くデザインエージェント、Content Studioを構築しました。チームメンバーが希望を記述し、関連するコンテンツやブリーフを添付すると、エージェントがブランドに沿った完成ファイルを返します。Content Studioを構築するにあたり、私たちに必要だったのは3つの要素です：
- デザイナーたちの専門的判断エージェントのスキルとチェックに書き込み、何が優れたデザインかをエージェントが判断できるようにした。
- カスタム環境 モデルを取り巻く環境であり、デザイン作業のあらゆるレイヤーに対応するツールを備えた動画編集コンピュータを含む。
- 適切なUXにより、何時間もかかるプロジェクトにチーム全体が1つのSlackスレッドから共同で取り組める。
Managed Deep Agents は、Content Studioを社内で本番稼働させるために必要なすべてを提供してくれた。マネージドな LangSmith Sandbox、Slackとの統合、マネージドツール、スコープ付きのエージェントメモリ、そしてエージェント実行のスケジューリングだ。これにより、少人数チームは面倒な仕組み作りではなく、デザイン作業、スキル、ツール、Slack体験に時間を費やすことができる。
主な成果
- Content Studioは社内全体で3,000を超えるアセットを制作しており、その中には80を超えるスライドデッキが含まれる。そのデッキの1つは、私たちの最も視聴されたオーガニックYouTube動画でも使用された。
- その制作物を使った投稿は、Xで約4.5M回のビューを獲得した。
- LangChainアカウントでは、そのビジュアルを使った投稿は、他の投稿と比べて約2倍のいいね、3.7倍のブックマークを獲得している。
- 現在、リクエストの4分の3はマーケティング以外の部門から来ており、ユーザーの75%は毎週戻ってくるリピーターである。
- 現在のリクエスト1件の中央値コストはモデル利用料で約50セントであり、9月中旬の約8ドルから低下した。移行後、当社自身のコードは約80%減少した への移行後、独自コードは約80%削減された。.
AIは本当にデザインが得意なのか?
構築に入る前に、まず世紀の論争に答えておこう。AIは本当に優れたデザインを生み出せるのだろうか?
モデルはもともと実行力があり、HTMLやCSS、チャートのスペック、アニメーションのタイムラインを書くことができた。しかし、私たちの文脈を持っていなかったため、ありふれたパターンに頼ってしまった。これは Anthropicが「分布的収束(distributional convergence)」と呼ぶものだ。その結果、洗練されて見えても他の無数の作品と似たようなものになったり、美しくアニメーションしていても伝えたい点が伝わらなかったりすることがある。ありふれていることが必ずしも悪いわけではないが、私たちはエージェントがその目的に沿った選択をするようにしたかった。
ケイティ・ディルStripeのHead of Designである彼女は、わかりやすい比喩を示しています。第二次世界大戦後に急いで建設する必要に迫られた建築家たちは、モダニズムのすっきりした形やむき出しの表面を何度も何度も模倣しました。その模倣は見た目を保ちながら、その背後にある思想や個性を失っていきました。彼女の警告は、AIがソフトウェアに対して同じことをしうるというものです。彼女はそれを「zombie UI」と呼び、私たちには自分なりの視点が必要だと述べています。なぜなら「持たなければ、AIが代わりに与えてしまう」からです。
私たちは、AIがデザインを苦手としているとは考えていません。ただし、視点を与えない限りAIには自分の視点がなく、私たちの視点を与えるということは、私たちの審美眼を教え込むことを意味しました。
デザインエージェントにセンスを教える
テイスト(审美眼)とは、正しい仕事と優れた仕事を仕分ける判断力である。デザインにおいて、2つのレイアウトがどちらも正しいフォント、色、余白を使っていても、主張を成し遂げるのは片方だけだ。テイストは、Dillが言うところの「気づくことに本当に長けること」から生まれる。
その気づきこそが、私たちがAIスロップ(AIの粗悪出力)を見分ける術を学んだ方法であり、それは最も多く、指示書がエージェントに判断を委ねているときに現れます。
例えば、下の左の画像は、当社のブランドスキル(カラー、フォント、ロゴなどを含む)を適用したローカルのコーディングエージェントによって作成されたものです。しかし最終的な結果は、正しいロゴのロックアップ、テキストの配置、どの色がプライマリーカラーでどの色がセカンダリーカラーかといった、重要な要素が欠けていました。
同じプロンプトがContent Studioでは完璧にブランドに合った画像を生成しました。これは、ローカルエージェントがブリーフで指定されていない各判断を、それまで最も多く目にしてきたものに基づいて補完したためです。この手法では、Content Studioは同じ空白を私たちの選択で補いました。
Content Studioに提供したガイドラインは、カラートークン、フォントのウェイト、スペーシング、配置といった基本事項から始まりました。しかし、改善の多くは、その上に追加した要素からもたらされました。私たちは、1フレームにつき1つのフォーカルポイントを持つといったデザイン原則、よくあるAIデザインパターンに対するガードレール、そして各フィードバックの背後にある理由を導入しました。より優れた基盤モデルと組み合わせることで、これらはContent Studioがデザイナーのように考え、コミュニケーションを取れるようになることにつながりました。
最初はそうではありませんでした。初期のモーショングラフィックスの一つで、鳥が画面外へ飛び立ち、その後ろに光のリボンが1秒足らず尾を引くシーンがありました。私たちは鋭いエッジをなくしてほしいと依頼しましたが、最初の仕上がりはぎこちなく、角ばった丸いエッジが戻ってきました。デザイナーであれば、私たちの意図を理解できたはずです。エッジは柔らかくなじませ、尾は鳥の動きと逆方向に向かって細くなりながらフェードアウトするべきだったのです。
その後の反復によって、エージェントはそのディテールをデザイナーの目で評価するようになっていた。鳥の尾がどこにあるべきかを素早いスケッチで特定し、リボンが剥がれないようにするための独自のコマごとのチェックを構築した。ほとんどの視聴者はこのディテールを意識的に気づくことはないだろうが、何かがおかしければそれを感じ取るはずだ。
測定可能な問題は最も解決しやすいものでした。デフォルトでの大文字表記はかつてレビューで頻繁に指摘されていましたが、今では自動チェックがすべての事例を検出します。より難しい判断はより主観的なもので、例えばキャンペーンのアイデアが十分に強いか、メッセージが明確に伝わっているか、実行がオーディエンスの共感を得られているかといった点です。デザイナーがそのような判断を下した際には、その理由づけをスキルとして記録し、エージェントが今後のドラフトに適用できるようにしています。
Content Studioは、誰がデザイン作業を行えるかを変えました。PM、エンジニア、創業者がSlackでエージェントにブリーフを伝えるだけで、ブランドに合った出荷可能な成果物を手に入れられます。現在、リクエストの4分の3はマーケティング部門以外から来ています。デザイナーにとっては、役割がクリエイティブディレクターに近いものへと変わり、すべての素材を自ら制作するのではなく、方向性を定めて成果物をレビューする立場になっています。
設計上の判断を正しく行うことは、プロセスの一部でした。その判断を実行するために、エージェントにツールと環境を与えることも必要でした。
メディアハーネスの構築
あるデザイナーは複数のツールを使って仕事をしています。静止画にはPhotoshop、モーションには動画エンジン、プロトタイピングとコラボレーションには共有キャンバスを使用します。さらに、ブランドガイドライン、デザインアセット、社内ドキュメントにも頼っています。
エージェントにも同様の環境が必要です。つまり、作業に使うコンピュータ、デザインプロセスのさまざまな部分に対応するツール、そしてデザイナーが仕事に持ち込む文脈です。ハーネスはこれらの要素を一つにまとめます。 Deep Agents 基盤となる ハーネス「エージェントループ、計画、ファイル、サブエージェント、コンテキスト管理を含みます。」 マネージド・ディープエージェント 生产環境でパッケージ化して実行します。私たちはその周囲に環境を構築し、エージェントにプロジェクトを維持し、複数のツールを横断して作業し、その結果を確認できるコンピュータを与えました。
harness_v1
そのハーネスの最初のバージョンは、モデルに代わってデザインを行おうとしていました。初期のモデルが、私たちが出荷したいと思うモーショングラフィックやローンチフィルムを作成するには、多くの支援が必要でした。当時はまだ自分自身で解決できなかった部分を補うために、私たち自身のデザイン判断をより多く指示やコードに盛り込もうというのが私たちの直感でした。
そこで私たちは、タイトル、レイアウト、アニメーション用の再利用可能な115のUIコンポーネントからなるデザインシステムを、いつどのように使うかのガイダンスとともに構築しました。これによりモデルには既存のデザイン一式が提供され、ゼロから行う必要のある創造的な判断の数が減りました。
そのおかげでブランドの一貫性は保たれましたが、エージェントは各フレームに対して同じレイアウトとアニメーションを繰り返すだけで、あまり変化がありませんでした。
このタスクをモデルがいずれは得意になると分かっていたため、私たちはその瞬間に向けて環境の構築を続け、その過程でスキルやツールリングを実験しました。モデルを助けるために、参照やより詳細な指示を追加することもあれば、それらを完全に取り除いて、モデルが自分の力でどこまでできるかを確かめることもありました。
しかし結果はまだ望む水準に達しておらず、そのギャップを埋めるにはますます多くのエンジニアリング作業が必要でした。モデルにできないことを補うため、私たちはスキルにルールを追加し続け、より多くのモーションコードを書き、より多くのコンポーネントを構築し続けました。
そしてOpus 5.5が登場すると、品質が即座に跳ね上がるのを目にしました。私たちはスキルを見直し、ハードコードされたルールの大半を削除し、デザインの原則と高レベルのガイダンスだけを残しました。結果はさらに改善し、バラエティが増え、繰り返しが減りました。モデルはついに、これまで私たちが前もって構築しようとしてきた創造的な決定を自分で下せるようになったのです。
これは私たちの 「苦い教訓（Bitter Lesson）」でした。モデルの弱点を補うために設計されたルールは、モデルの向上とともに有用性を失っていきます。残るのは、モデルを取り巻く環境です。つまり、モデルが使うツール、参照するコンテキスト、そして人々がその仕事をどう導くかです。創造的な決定を前もって構築するのではなく、新しい世代のモデルそれぞれを活かせるよう、ハーネスを十分に柔軟にすることに注力しました。
デザイナーのコンピューター
ハーネスの動作をお見せするために、Content Studioに動画プロジェクトをエンドツーエンドで扱う様子を題材にした映画を作ってもらいました。その結果が、ピクセルのジャングルに住むオウムが主人公の、デイヴィッド・アッテンボロー風のナレーション（ElevenLabsで音声化）が付いた作品です。これを使って、ハーネスの層、すなわち作品の背後にあるコンピューター、ツール、コンテキストを見ていきましょう。
デザインは反復的な作業です。何かを作り、見て、何度も変更することがよくあります。そこで、エージェントには会話全体を通じて作業を続けられるコンピューターが必要です。各Slackスレッドにはそれぞれ専用の LangSmith Sandboxが割り当てられます。これはファイルシステムとシェルを備えた隔離されたLinuxマシンで、プロジェクトはスレッドの存続期間中そこに置かれます。
エージェントが作るものはすべてコードで構築されます。スライド用のHTMLページであれ、チャート用のデータ仕様であれ、動画用のアニメーションタイムラインであれ同じです。これにより、ゼロからやり直さずに反復作業が容易になります。オウムを早めに登場させるよう依頼された場合、エージェントはタイミングの値を1つ変更して再レンダリングでき、アートワークやコピーには影響しません。フラットな画像や生成動画クリップでは、些細な編集でもアセット全体の作り直しにつながりかねません。
ブリーフ、プラン、シーンコード、音声、レンダリング結果はすべて1つのプロジェクトフォルダーに置かれ、その仕事に携わるすべてのサブエージェントがそこから作業します。
さらにその上に、作業の各層でデザイナーが手に取るようなツールをインストールしました：
モーションは最も難しい層です。これは2つのエンジンで動いています：
- 編集用のHyperFrames： HyperFramesは、HeyGenのオープンソース動画フレームワークで、動画をWebページに変換します。クリップ、画面収録、キャプション、テキストはすべてそのページ上の単なる要素であり、 GSAP のタイムラインがそれらを動かします。そのため、ウェビナーにキャプションを付けたり、製品デモをカットしたりするよう依頼されると、エージェントはそれをWebページのように編集します。そのCLIは基本的にエージェントの編集スイートです。コンポジションをlintし、フレームを取り出して確認し、カットをレンダリングします。また、 HeyGenの公式スキルもインストールしているため、エージェントはそのフォーマットを作った人たちから学ぶことができます。
motion-studioアニメーション用のエンジン： Webページでは速い動きをぼかしたり、ものを光らせたり、ロゴを3Dで回転させたりすることはできませんが、オリジナルアニメーションにはまさにその仕上げが欲しかったのです。そこで私たちは独自のキャンバスエンジンを構築しました。エージェントが書くコードが毎フレームの全ピクセルを描画し、エンジンは最大16の瞬間を1つのフレームにブレンドします。これはカメラのシャッターが動きをぼかすのと同じ仕組みです。オウムの映画はこの方法で作られました。
どちらのエンジンも各フレームをタイムスタンプに基づいてレンダリングするため、10秒のフレームはいつレンダリングされても同じ見た目になります。これにより、エージェントは映画全体をレンダリングせずに個々の瞬間を検査でき、複数のフレームを並列にレンダリングすることも可能になります。音声も同じタイムライン上で動作し、ナレーション、音楽、効果音が映像と同期されます。
このセットアップにより、エージェントはほぼ何でも作れます。しかし、さらなるガイダンスがなければ、私たちのデザインではなくモデル自身のデザイン選択にデフォルトで従ってしまいます。次の課題は、私たちのブランドとデザイン基準に沿って作業するよう教えることでした。
デザイナーの脳
私たちはエージェントの知識を、それぞれ明確な目的を持つ4つの異なる機能に整理しました。スキルは特定のタスクの実行方法を導き、ウィキは私たちの会社や優れた仕事のあり方についてのコンテキストを提供します。測定可能なものはすべてゲート、すなわちコードで書かれた決定論的なチェックによって処理されます。別のメモリ層が、人々が時間をかけてエージェントに教えたことを記録します。
スキル
エージェントはリクエストを受け取ると、最初にそれがどんな種類の仕事かを見極めます。これは私たちの media-production スキルが担います。私たちはこれを ルータースキルと呼んでいます その大部分が1つのテーブルで構成されているためです。各行は、ある種の依頼(キャンペーン、リスタイル、サムネイル、投稿、YouTubeパッケージ、ローンチフィルム、短編アニメーション)を、それを処理するパスと専門スキルに対応付けています。ルーターは、その作業に共有ビジュアルキャンバスが必要かどうかも判断し、小さな編集を完全なプロセスから除外します。
上記のような映画の場合、ルーターは launch-film 大規模なモーション制作の監督向けに設計されたスキルを選びます。48個のスキル全体で合計約1,000ファイルにのぼりますが、それぞれがトピックではなくジョブにスコープされており、その説明はルーティングルールのように読め、いつ使用しないかについても記載されています。
スキルは互いに繰り返すのではなく、組み合わさります。 launch-film が監督し、 motion-studio が映像と音声を作るため、アニメーションの技法は一度だけ書かれます。 launch-film また、起動するサブエージェント向けの役割ブリーフや、コードでショット単位で再構築した実際の88秒のローンチフィルムのケーススタディも含まれています。このケーススタディで、エージェントは映画をサブエージェント間でどう分割するかを学びました。ハードなシーン切り替えでカットし、連続したカメラワークは1つのサブエージェントに任せ、並行作業が始まる前に共有コードを凍結します。
説明はスキルと同様にツールにとっても重要です。コンテキスト使用量を抑えるため、MCPツールを組み込みの検索の背後に置きました。エージェントは最初は自社のツールのみを持ち、ツール名と説明全体をキーワード検索して、必要に応じて追加のツールスキーマを読み込みます。
Wiki
スキルは仕事のやり方を説明しますが、wikiはそれを上手く行うために必要なコンテキストと参考資料を提供します。ブランドトークン、グラフィック言語、トーン・態度から、プラットフォーム、キャンペーン、製品情報まで、あらゆるものを網羅しています。専用のモーションwikiでは、監督、技法、サウンド、レビューを扱い、70本の参考映画の分析も併せて提供しています。
この情報をスキル間で複製するのではなく、wikiに直接リンクしています。これにより共有知識が一箇所に保たれ、更新が容易になります。フォントルールのようなものが変更された場合も、一度更新するだけで、すべてのスキルが最新バージョンを参照できます。
私たちの働き方を知っていることは、必ずしもモーションデザインを安価にするわけではありません。誤ったクリエイティブな判断は、依然として何時間ものレンダリングコストになり得ます。
スペック駆動デザイン
モーションは、レンダリング時間とトークンの両面で、間違えると特に高くつきます。ストーリーボードの1フレームは約50ミリ秒でレンダリングできますが、完成フィルムの1秒には8から40秒かかります。サブエージェントがすべてのアクトを書き、レンダリングし、レビューするため、これらのコストは急速に積み上がります。そこでエージェントは、まずストーリーボードでアイデアを発展させ、安価にさまざまな方向性を探索し、方向性が承認されてから本制作に移ります。
この探索を支援するため、ムードボードを基に作業するデザイナーのように、エージェントにインスピレーションを得るための参考映画のライブラリを与えました。適切なルックが見つからない場合は、画像モデルを使って新しいリファレンスを生成し、まずクイックドラフトから始めて、最有望な選択肢を洗練させていきます。これらの画像はビジュアルの方向性を確立するのに役立ちますが、ストーリーボードと最終フィルムは実際のタイポグラフィとブランドアセットを使ってコードで構築されます。
方向性を決めると、承認されたストーリーボードが、映画の残りの部分を構築する際のスペックになります。そしてプロジェクトは3つのステージを経て進みます:
- ストーリーボード:ビジュアルアイデア、コピー、ショットについて合意するためのもの。
- アニマティック:音声に合わせたタイミングのラフカットで、静止画では分からないペース配分を確認するためのもの。
- 本制作:サブエージェントが承認されたショットを構築、チェック、レンダリングする段階。
最初はこの順序をスキルの指示に記述していましたが、エージェントは時間を節約するためにレビューを省略することがありました。現在はパイプラインがコードでこれを強制し、すべてのアクトがレビューを通過するまで組み立てを待たせる一方、指示はクリエイティブな判断を引き続き導きます。常に守られるべき順序はコードに置き、判断はプロンプトに残します。
プロンプトではなく、指し示す
これらの方向性の選択はチームの決定です。Slackは仕事の依頼と受け取りには便利ですが、スレッドは線形のテキストであり、ストーリーボードは空間的なものなので、フィードバックは何かを指し示すのではなく、それがどこにあるかを説明することになりがちで、たとえ一言の修正であっても、すべての変更は新しいプロンプトとしてエージェントに戻されなければなりません。
Paper がこの問題を解決してくれました。エージェントを念頭に構築されたデザインキャンバスで、エージェントにファイルを直接操作させるMCPサーバーを備えています。人々は同じファイル内で作業し、方向性を並べて比較したり、特定のフレームにコメントを残したり、自分で編集したりできます。キャンバスが共有されているため、エージェントはそのファイルに戻り、コメントや編集を次のイテレーションの指針として使えます。
課題は、Paperのエージェントツールはデスクトップアプリ内でしか動作せず、私たちのエージェントはクラウドサンドボックスで動作していることでした。このギャップを埋めるため、常時稼働のLinuxワーカー上でPaper Desktopをヘッドレスで実行し、仮想ディスプレイと認証済みブリッジを使って両者を接続しています。1回のセットアップでチーム全体をサポートできます。
承認後でも、ストーリーボードを完成した映画に仕上げるには数時間かかることがあります。その時点で、作業は小さなプロジェクトのような形になり、並行して構築されている複数のパーツをまとめる必要があります。このすべてを調整するのは、単一のエージェントターンでは処理しきれません。
参謀長としてのエージェント
先ほどのオウムの映画を、Slackでの制作途中の段階で考えてみてください。ある人がリファレンスを共有し、別の人が異なるオープニングを提案し、3人目がフレーム4にフィードバックを残す——その間もエージェントは構築を続けています。これは、メモを取る人が映画の制作も担うブレインストーミングのようなものです。同期サブエージェントでは、メインエージェントが完了を待たなければならないため、その間に人々がエージェントとやり取りする方法がありません。
これを解決するため、サブエージェントを非同期化し、メインエージェントの役割を実装者から参謀長へと変えました。メインエージェントは複雑なプロジェクトをより小さく分離されたタスクに分解し、サブエージェントに割り当て、作業を並行して進めます。同時に、状況の変化をチームに伝え続けるため、人々はフィードバックを続け、プロジェクトの方向性を定め続けることができます。
各タスクについて、メインエージェントはサブエージェントのプロフィールを、役割、関連するコンテキスト、ファイルの所有権、成果物の検証方法を網羅した明確なブリーフとともに作成します。また、タスクの複雑さに応じてモデルと effort レベルを選択します。
また、メインエージェントが作業を調整するための少数のツールセットも追加しました。
start_taskは、パートをバックグラウンドでサブエージェントに引き渡しますcheck_tasksは、実行中のタスクを表示し、完了したレポートを読み取りますcancel_taskおよびresume_taskは、ブリーフに合わなくなった作業を停止したり、中断した箇所から再開したりしますreport_progressは、サブエージェントが作業の途中で更新を送信できるようにしますschedule_wakeupは、メインエージェントにタイマーを与え、次の実行をトリガーしてジョブを継続させます
内部では、各サブエージェントはバックグラウンドタスクとして実行される通常の Deep Agents task ツールです。完了すると、私たちのコードは結果を含むメインエージェントの新しい実行をキューに入れます。実行中のメインエージェントを人が誘導することもできます。作業中に届いたメッセージは、次のモデル呼び出しの前に挿入されるためです。サブエージェントはプロジェクトフォルダを通じて調整し、それぞれが自分の所有するファイルのみを書き込み、進捗をディスク上に保持します。
作業がバックグラウンドで実行されている間、スレッドは何が起きているかを表示しなければなりません。メインエージェントは、プランと完了予定時刻、実行中のサブエージェントを示すライブステータス行、レンダリングの進捗とコスト、各編集に対する確認応答、そして公開前に承認カードを表示することで、スレッドを最新の状態に保ちます。
このアプローチの最も明確な試金石のひとつとなったのが、52枚のスライドのプレゼンテーションをリスキンする夜間ジョブでした。エージェントはまず3枚のサンプルスライドを作成し、自分の作業を見直した上で、番号付きのバッチごとに承認を得ながらデッキの残りを進めました。途中で新しいスライドを2枚追加もしました。夜間に、メインエージェントは約1時間実行され、そのサブエージェントは合計で6時間以上作業しましたが、会話をブロックすることは一切ありませんでした。
自己改善するハーネス
チームと数ヶ月働いたデザイナーは、その好みを学び、同じフィードバックを二度聞く必要がありません。メモリがなければ、エージェントは新しいスレッドごとにゼロから始めることになります。これを避けるため、私たちは2つの学習ループを構築しました。高速ループはフィードバックをその場でキャプチャし、低速ループは完了したプロジェクトからバックグラウンドで学習します。
高速ループ: 誰かがルールや好みを共有すると、エージェントは同じターン内でそれを保存します。 Managed Deep Agents は、メモリをプレーンなファイルとして2層で保存します。1つはチーム全体で共有され、もう1つは各個人に固有のものです。
個人の好みはスレッドをまたいで引き継がれますが、共有された標準が優先され、会社のチャネル向けに作成されたものは会社のトーンに従います。各層には、モデル呼び出しごとに読み込まれる AGENTS.md ファイルがあります。初期のバージョンが500Kトークンまで成長した後、現在はこれらのファイルを200行のインデックスに制限しています。
低速ループ: 各ジョブの後、私たちの learn_from_job ツールが軽量のサブエージェントを起動し、根拠に基づくレッスンを最大5つまでキャプチャして、使用されたスキルに関連付けます。今後のジョブはそれらのレッスンを読んで評価し、週に一度、バックグラウンドエージェントが有用性が証明されたレッスンをスキルと wiki に取り込みます。
次のステップ
初期のレビューを覚えていますか?最大の改善は、デザイナーの判断を、レビュースレッドに散在させたままにするのではなく、エージェントが学習できる共有環境にキャプチャしたことで得られました。その過程で、より多くの人がデザイン作業にアクセスできるようにしました。
次に、エージェントにキャンペーンのライフサイクル全体を管理させたいと考えており、その一部はすでに機能しています。承認権限を持つ承認者のサインオフがあれば、Buffer を通じて会社のソーシャル投稿を公開し、従業員が自分のアカウントから共有するための投稿を下書きし、引用する価値のある投稿を提案する毎日のレビューを含む、スケジュールされたルーチンを実行します。
私たちの目標はこれをさらに進め、単一の承認済みクリエイティブディレクションが1つのスレッドからキャンペーン全体を担えるようにすることです。エージェントはブリーフを書き、各チャネル向けのアセットを作成し、投稿をスケジュールし、チームの拡散を支援し、パフォーマンスデータを次のキャンペーンの参考にします。公開前に人はすべてをレビューし承認します。
自分のデザインエージェントを構築する: この オープンソースリポジトリ には、この記事のハーネスが含まれています。サンドボックスコンピュータ、スキル、wiki とメモリ、非同期サブエージェント、そして Slack UX です。フォークして、ブランドトークン、フォント、スキルを追加し、チームの Slack にデプロイしましょう。それには Managed Deep Agents.
その場合は、10月28日の GTM Engineering Live 10月28日に。ハーネスとUXの内部構造を掘り下げ、この記事に収まりきらなかった取り組みもご紹介します。