LangChainがGTMエージェントを構築した方法
LangChainはSalesforceやGongなどのデータを活用し、営業担当者の承認プロセスを組み込んだ自律型GTMAgentを開発し、成約率250%向上と月間1,320時間の業務削減を実現した。
キーポイント
営業プロセスの自動化と人間関与の両立
Salesforceのリードをトリガーに、過去のコンタクト履歴やアカウント状態を分析し、Slackでドラフトを送信する仕組みを構築。最終送信は営業担当者の承認必須とする「Human-in-the-loop」設計を採用した。
Deep Agentsフレームワークの採用理由
長期にわたり複数のツールと大量データを安全に連携させる必要があるため、LangChainの「Deep Agents」を採用し、信頼性と監査可能性を確保した。
顕著な営業成果と業務効率化
2025年12月〜2026年3月の期間で、リードから合格見込み先への転換率が250%向上し、パイプライン金額は3倍に拡大。チーム全体で月1,320時間の業務時間を節約した。
透明性と継続的学習
エージェントは出力の根拠を明示し、営業担当者の編集履歴から自動的に学習・改善するフィードバックループを実現している。
インバウンドリードの自動処理とフィルタリング
サポートチケットや既存の接触履歴など「送信しないべき理由」を優先チェックし、クリア後にSalesforceやGong、LinkedIn等多様なデータソースから調査してパーソナライズされたメール草案を作成する。
アカウントインテリジェンスと行動計測
メール作成に加え、取引リスクや拡大機会などのアカウントレベルのシグナルを統合し、営業担当者の全操作をLangSmithに記録して品質評価と回帰テストを行う。
48時間SLAによる自動送信
シルバーリードのドラフトが承認・却下されない場合、48時間経過後に自動送信する仕組みを導入し、対応漏れの防止とフォローアップ率の向上を実現した。
影響分析・編集コメントを表示
影響分析
LangChainのこの取り組みは、LLMを活用した営業支援（GTM）における「信頼性と監査可能性」の重要性を再確認させる。完全自動化への過度な依存を防ぎ、人間との協調設計を採用した点は、エンタープライズ領域でのAI実装における標準的なベストプラクティスを示唆している。
編集コメント
自社製品Deep Agentsの活用事例を詳細に公開しており、販促色が強いものの、「Human-in-the-loop」や「監査可能性」を明文化した設計思想は、実務でAIエージェントを導入する際の重要な指針となる。
imageヴィシュヌ・スuresh とジェス・オウによる
LangChain におけるすべてのアウトバウンド（営業活動）は、かつて同じ手順から始まっていました：担当者がタブを切り替えながら作業を行うのです。アカウント記録には Salesforce を、通話履歴には Gong を、連絡先情報には LinkedIn を、文脈把握には企業ウェブサイトを使用します。1 つの単語も書かれる前に 15 分間の調査が必要で、チームメイトが昨日すでに接触していないかを確認する簡単な方法はありませんでした。インバウンド（受注）後のフォローアップは、新しい連絡先ごとに同じメッセージを Apollo に手動で入力することを意味していました。
私たちは、このプロセスをエンドツーエンドで実行する GTM エージェント（Go-To-Market Agent：市場参入エージェント）を構築しました。これは Salesforce の新規リード（見込み顧客）が発生した際にトリガーされ、 outreach すべきかどうかを確認し、文脈（会議履歴を含む）を集約し、担当者が承認するための Slack ドラフト（推論と出典情報付き）を送信します。このプロセスは長期にわたり多段階で、複数のツールと大量のデータを信頼性高くオーケストレーションする必要があるため、Deep Agents を基盤として構築しました。
主要な成果
2025 年 12 月から 2026 年 3 月にかけて、リードから合格見込み商談への転換率が 250% 向上し、同じ期間にパイプラインドル（見込み売上高）が 3 倍になりました。
担当者のフォローアップ率は、シルバーリードで 97% 上昇、ゴールドリードで 18% 上昇しました。
営業担当者は月あたり各々 40 時間を回復し、チーム全体では合計 1,320 時間の時間節約となりました。
営業チームメンバーのアクティブ利用率は、日次で 50%、週次で 86% に達しました。
チームからの評価
必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等)は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:
{"translation": "翻訳全文"}
制約と成功基準
コードを書く前に、エージェントが実際に何をする必要があるかを定義しました。
私たちの目標は 2 つありました。1 つ目は、営業担当者がリードごとに調査やドラフト作成に費やす時間を短縮すること、2 つ目はマーケティング経由で流入した見込み顧客のコンバージョン率を向上させることです。アウトバウンド（営業先開拓）における調査とドラフト作成は、システムが安全かつ監査可能であり、使用を通じて改善されるという条件付きであれば、体系的に自動化可能です。
譲れない要件
人間による監視（ヒューマン・イン・ザ・ループ）: 担当者の明示的なレビューと承認なしには、何一つ送信されません。タイミングを誤ったメール 1 通が、数ヶ月かけて築き上げた関係を台無しにする可能性があります。
顧客とのやり取り履歴の知識: エージェントは、何かドラフトを作成する前に、その担当者やチームメンバーが既に連絡を取っていないかを確認する必要があります。
中核機能
関係性に基づくパーソナライゼーション：ドラフトは、顧客、温かい見込み客、冷たい見込み客など、アカウントの現在の状態を反映するものであり、すべてのリードを同じように扱うべきではありません。
説明可能性：営業担当者は主要な入力内容を確認し、エージェントが特定の角度を選択した理由を理解できる必要があります。これにより、担当者がドラフトを改善し、フィードバックを提供できるようになります。
学習ループ：エージェントは営業担当者の編集履歴から時間をかけて学習し、誰かが手動でプロンプトを更新することなく、ドラフトの品質を向上させるべきです。
測定
すべての営業担当者によるアクション（送信、編集、キャンセル）は LangSmith にログ記録され、背後にあるトレースに紐付けられます。これにより、品質の評価、回帰現象の検出、効果的な施策の定量化が可能になります。
スコープの拡大：アカウントインテリジェンス
単発のドラフト作成だけでなく、エージェントには週ごとに営業担当者が注力すべき場所を把握させるため、取引リスク、拡張機会、競合他社の動きといったアカウントレベルのシグナルを能動的に提示させることも目指しました。
私たちが構築したもの
GTM エージェントは 2 つの主要な機能を果たします。(1) リードのリサーチとパーソナライズされたメールドラフトの作成、(2) ウェブ上の活動、開発者エコシステム、製品の使用状況、マーケティングとの接点にわたるアカウントレベルのシグナルを集約し、営業担当者に注力すべき場所を提示することです。この意図データ（intent data）を営業担当者のアカウントに紐付けることで、意味のある活動を浮き彫りにし、取引リスクや競合他社の動きを警告し、次に誰にアプローチすべきかを明確にします。
私たちはエージェントを以下のデータソースに接続しました：
imageインバウンドリード処理
Salesforce に新しい見込み顧客が現れると、エージェントは即座に引き継ぎます。まず行うのは、何も送信しない理由がないかを確認することです。誰かがサポートチケットを提出したばかりだったり、チームメイトがすでに今週中に連絡していたりする場合は、自動メールを送信するのは誤りとなります。このエージェントは慎重になるようにプログラムされています。
imageこれらのチェックをクリアすると、以前営業担当者が手動で行っていたのと同じ調査を開始します：Salesforce のレコード全体を引き抜き、Gong のトランスクリプトを読み込み、見込み先の LinkedIn プロフィールを確認します。社内の履歴があまりない場合は、Exa を使ってウェブを検索し、その企業が現在 AI で何をしているのかを理解します。
メールドラフトの作成方法は、関係性の状態によって異なります。エージェントは定義されたアウトバウンドスキル（outbound skill）に従い、ドラフト作成前に読み込むプレイブックを実行します。このスキルは、温かいケースと冷たいケースの両方をカバーするように設計されています。既存顧客には異なるアプローチが用いられ、温かい見込み先にはそれとは違う内容が提供され、さらに冷たいコンタクトにはまた別の対応が取られます。冷たい outreach の場合、エージェントは定義されたスキル内のプレイブックに従い、簡潔かつ調査に基づいた内容に留めます。
営業担当者は、送信・編集・キャンセルのボタンが付いた Slack のダイレクトメッセージで完成したドラフトを確認できます。また、エージェントがなぜ特定の角度を採用したのかという推論も表示されるため、その理由が明確になります。もし送信された場合、エージェントは候補者をオプションとして登録するための一連のフォローアップメールをキューに追加します。
エージェントを洗練させる過程で、シルバーリードに対して 48 時間の SLA（サービスレベルアグリーメント）を追加しました。営業担当者がその期間内にドラフトを承認または却下しない場合、自動的に送信されます。これにより、対応なしで流失していたリードのフォローアップ率が有意に向上しました。
アカウントインテリジェンス
チームが拡大するにつれ、各営業担当者が 50 件から 100 件以上のアカウントを管理するようになりました。そのような大量の案件では、連絡が取れなくなったり、拡張の機会を見逃したりすることが容易です。
毎週月曜日の朝、エージェントは Salesforce と BigQuery からデータを取得します。その後、外部の世界で資金調達ラウンド、製品ローンチ、新しい AI 関連の取り組みがないか確認します。レポートは、異なるデータポイントを重視する営業チームと展開されたエンジニアリングチームという 2 つの対象者に合わせて調整されています。
営業部門においては、このエージェントは製品の利用状況、開発者エコシステム、ウェブ上の活動、採用動向、および企業のニュースにわたるシグナルを統合し、拡大の機会を浮き彫りにします。経営陣の異動、パッケージインストール数の急増、そして企業が AI エンジニアの採用を積極的に進めているか、あるいはエージェント型システムの構築を行っているかを特定します。これらは、同社が拡大の準備ができていることを示す強力なシグナルです。また、新機能のリリース時には、潜在的に最適なマッチング先も特定し、直近の活動が新機能とよく合致する顧客アカウントを提案します。さらに、アカウントがアクティブであることだけでは不十分であるため、最も関与度の高い個人を特定し、次に誰にアプローチすべきかを提案します。
デプロイされたエンジニアにとっては、焦点はアカウントの健全性へと移ります。このエージェントは BigQuery から製品利用データを取得し、直近のカスタマーコールからのハイライト、今後の更新日、および顧客がクレジット残高を使い果たす寸前であるケースを強調表示します。また、直近の通話から未解決の質問やスレッドも浮き彫りにします。その目的は、実際に人間の介入が必要な事項を特定し、チームが日曜日の夜にダッシュボードを掘り下げる時間を費やすことがないようにすることです。
image構築方法
このエージェントは複数のソースからデータを取得し、それらを超えて推論を行い、パーソナライズされた出力を生成する必要があります。これは、単なる LLM（大規模言語モデル）の呼び出しでは信頼性を持って処理できないレベルです。
多段階のオーケストレーションには Deep Agents を選定しました。その理由は、入力データ（会議データ、CRM の履歴、ウェブ調査など）がサイズや構造において本質的にばらつきが大きいためです。Deep Agents を用いることで、大きなツール結果は自動的に仮想ファイルシステムにオフロードされるため、独自の切り捨て・検索層を構築する必要はありませんでした。また、ハッチス（harness）のネイティブな計画機能を使用して、一貫したチェックリスト（送信不可チェック→調査→ドラフト作成→根拠提示→フォローアップ）を強制することで、実行プロセスのデバッグが容易になり、エージェントの迷走も減少しました。
エージェントを LangSmith に接続したことで、営業担当者が実際にどのように利用しているかを把握し、時間の経過とともにエージェントが改善されているかどうかを測定できるようになりました。これは、後から評価機能を追加するのではなく、最初から評価体制を整備することを意味しており、プロンプトの反復やモデルバージョンの切り替え時に回帰（regression）を検出するために極めて重要であることが判明しました。
エージェントのパターン
GTM エージェントを本番環境へ移行したことで、解決すべき 2 つの問題が浮き彫りになりました。1 つ目は、利用する人々から学習させる方法であり、2 つ目は、大規模な運用において実行効率を維持する方法です。
メモリ管理
営業担当者が Slack でドラフトを編集すると、システムは元の文書と改訂版を比較します。変更が実質的なものである場合、LLM が差分を分析し、構造化されたスタイルの観察結果を抽出します：何が変わったか、それが担当者の好意について何を暗示しているか、そして任意の引用例です。これらの観察結果は PostgreSQL に保存され、各営業担当者ごとにキー付けられ、今後のドラフト作成時にはこれらが事前に読み込まれます。
各営業担当者は、トーンや簡潔さに関する独自のスタイル上の好みを持っています。フィードバックループは自動的に行われます。編集のたびにエージェントが学習し、次のドラフトに反映されます。週次で実行される cron ジョブにより、これらの記憶が定期的に圧縮され、時間の経過による肥大化を防ぎます。
imageサブエージェントの委任
アカウントインテリジェンスは、コンパイルされたサブエージェントを通じて実行されます。これらは、限られたツールセットと構造化された出力スキーマを持つ軽量なエージェントであり、メインのエージェントとの契約として機能します。営業調査用のサブエージェントは Apollo、Exa、BigQuery にアクセスでき、構造化された見込み顧客および市場の文脈を返します。展開エンジニア用のサブエージェントは Salesforce、Gong、サポートツールを使用して、使用傾向、未解決チケット、拡張シグナルを返します。
親エージェントはアカウントごとに 1 つずつサブエージェントを起動し、ツールの分離と出力の予測可能性を保ちます。サブエージェントが独立して実行されるため、並列実行が可能です。LangSmith Deployment が水平方向のスケーリングと永続的な実行を処理するため、ボリュームが増大してもシステムは信頼性を維持します。
image評価とフィードバック
新しいワークフローのための本番コードを書く前に、LangSmith において成功の基準を定義します。まず、営業担当者が実際に直面する状況に基づいた代表的なシナリオからなる小規模なライブラリを作成し、それらを用いて初期のエージェントや機能を構築しました。そして、拡張を行う前に基本機能が正しく動作することを確認しています。
機能が稼働し始めたら、LangSmith における評価セットをより困難なケースに広げました。具体的には、エージェント AI や自然言語処理（NLP）の深掘りを行っている研究者、再エンゲージメントを試みている既存顧客、過去の Gong のトランスクリプトを持つアカウント、医療分野など専門用語が多用される業界です。すべてのテストは外部 API を模倣するテストハネスを通じて実行され、実際のデータに触れる前に制御された環境で動作を観察できるようにしています。
評価は2つのレベルで行います。第一に、ルールベースのアサーションにより基本事項をチェックします：適切なツールの使用、正しい順序、重複したドラフトの回避です。第二に、LLM 判事（LLM judge）がトーン、単語数、フォーマットをスコアリングします。これらは CI における完全な評価スイートの一部として実行され、エージェントの動作に説明できない変化が生じた場合は、調査すべきバグとして扱います。
しかし、評価（evals）は物語の一部しか語らない。実際に重要なのは、担当者が日次でドラフトをどう活用するかだ。私たちはすべての Slack 操作（送信、編集、キャンセル）を追跡し、それを LangSmith のトレースに直接紐付けている。時が経つにつれ、これにより執筆パターンと実際の成果を相関させることができるようになる：どのスタイルが開封率を高めるか、どの件名が返信を得るかなどだ。ある傾向が十分な数の担当者に共通して見られる場合、それをエージェントのデフォルト行動としてコード化する。
LangSmith の評価スイートと担当者のフィードバックループは互いに補強し合う。一方は回帰（regressions）を検出し、他方は改善を推進する。
営業チームを超えた採用
GTM エージェントは当初、背景プロセスとして動作するアンビエントエージェントとして始まった。Salesforce にリードが現れると、エージェントが実行され、ドラフトが担当者の Slack に届く。トリガーも手動作業もない。
その後、SDR がエージェントに直接対話できる手段を提供することを主目的としたサイド実験として、会話型の Slack インターフェースを構築した。しかし、私たちが予想していなかったのは、それが社内の他の部門へどれほど急速に広がったかだ。エージェントがすでに Salesforce、Gong、BigQuery、Gmail と接続されていたため、人々は私たちが設計しなかった用途を見つけたのだ。エンジニアは SQL を書かずに製品利用状況を確認した。カスタマーサクセス担当者は更新前の電話前にサポート履歴を参照した。アカウントエグゼクティブは会議前に Gong のトランスクリプトを要約した。
これらのワークフローのいずれも意図的に構築したものではない。エージェントにはアクセス権があり、人々は最も抵抗の少ない道（path of least resistance）を見つけたのだ。ボットに話しかける方が、6 つものタブを開くよりも簡単だった。
GTM エージェントを他のチームがどのように活用しているかについては、追って別の記事で取り上げます。
学び
ゼロから始める人に伝えたいいくつかのポイントがあります：
成功の定義から始めましょう。新しいワークフローのための本番コードを書く前に、まず「良い状態」とは何かを定義し、それを中心に小さなシナリオライブラリを構築します。このセットはエージェントが成熟するにつれて拡大していきます。何かがリリースされる頃には、回帰を検出し、ドリフトを警告し、CI で自動的に実行される評価テストスイートが整っています。
人間が関与するプロセス（ヒューマン・イン・ザ・ループ）は単なる安全性を超えています。これはデータ収集のメカニズムとしても機能することが分かりました。すべての担当者によるアクション（送信、編集、キャンセル）は、学習に活用できるシグナルとなりました。メモリシステムとフィードバックループが機能するのは、担当者がそのフローの中にいるからです。
エージェントを最初からレコードシステム（記録管理システム）に接続してください。社全体での有機的な採用が進んだのは、エージェントが既に必要なデータへのアクセス権を持っていたからです。エンジニアやカスタマーサクセス部門が利用することを計画していませんでしたが、アクセス権が既に存在していたため、その利用は自然と広がりました。
長時間実行されるワークフローには適切なインフラストラクチャが必要です。このエージェントでは、ツールを一つ二つ追加した単純な LLM（大規模言語モデル）呼び出しだけでは不十分でした。複数のソースから情報を取得し、それら間で推論を行い、サブエージェントを並列で実行し、ターン間を通じて状態を維持する必要があります。そのようなオーケストレーションのために構築されたエージェントハネス「Deep Agents」を採用したおかげ、ゼロからインフラストラクチャを再構築する必要がなくなりました。
私たちはまだ初期段階にあります。GTM エージェントは今日すでに実際のワークフローを処理していますが、記憶機能や評価（evals）、トレースに紐づく再アクションなど、私たちが構築したフィードバックループこそが、今後 6 ヶ月間で本格的な改善をもたらす要因となります。
そして、それは Slack におけるアクティブなメンバーでもあります！
原文を表示
imageBy Vishnu Suresh and Jess Ou
Every outbound at LangChain used to start the same way: a rep toggling between tabs. Salesforce for the account record, Gong for call history, LinkedIn for the contact, the company website for context. Fifteen minutes of research before a single word was written, and no easy way to know if a teammate had already reached out yesterday. Inbound follow-up used to mean manually dropping the same message into Apollo for every new contact.
We built a GTM agent that runs the process end-to-end. It triggers on new Salesforce leads, checks whether we should reach out, gathers context (including meeting history), and sends a Slack draft (with reasoning + sources) for the rep to approve. We built it on Deep Agents because this is a long-running, multi-step process that has to orchestrate multiple tools and large amounts of data reliably.
Key results
Lead-to-qualified-opportunity conversion rate up 250% from December 2025 to March 2026, driving 3x more pipeline dollars in the same period
Rep follow-up rate is up 97% for silver leads and 18% for gold leads
Sales reps reclaimed 40 hours per month each, totaling 1,320 hours across the team
50% daily and 86% weekly active usage for sales team members
Team love
image
image
image
image
image
imageConstraints & success criteria
Before writing any code, we defined what the agent actually needed to do.
We had two goals: reduce the time reps spend researching and drafting per lead, and improve conversion on marketing-generated inbound. Outbound research and drafting is systematic enough to automate, but only if the system is safe, auditable, and improves with use.
Non-negotiables
Human-in-the-loop: Nothing is sent without an explicit rep review and approval. A single poorly timed email can undo months of relationship-building.
Contact history knowledge: The agent needed to check whether a rep or teammate had already reached out before drafting anything.
Core capabilities
Relationship-aware personalization: The draft should reflect the current state of the account (customer vs. warm prospect vs. cold), and not treat every lead the same way.
Explainability: Reps should be able to see key inputs and understand why the agent chose a particular angle so they could refine it and provide feedback.
Learning loop: The agent should learn from rep edits over time so drafts improve without anyone manually updating prompts.
Measurement
Every rep action (send, edit, cancel) is logged to LangSmith and attached to the underlying trace so we can evaluate quality, catch regressions, and quantify what’s working.
Scope expansion: account intelligence
Beyond one-off drafts, we also wanted the agent to proactively surface account-level signals like deal risks, expansion opportunities, and competitive moves, so reps know where to focus each week.
What we built
The GTM agent does two things: (1) it researches leads and writes personalized email drafts, and (2) it aggregates account-level signals across web activity, developer ecosystems, product usage, and marketing touchpoints to show reps where to focus. By tying that intent data back to a rep’s accounts, it surfaces meaningful activity, flags deal risks and competitive moves, and clarifies who is ideal to reach out to next.
We connected the agent to the following data sources:
imageInbound lead processing
When a new lead shows up in Salesforce, the agent takes over immediately. The first thing it does is look for reasons not to send anything. If someone just filed a support ticket, or if a teammate already reached out earlier in the week, sending an automated email would be a mistake. The agent is programmed to be cautious.
imageOnce it clears those checks, it does the same research a rep used to do manually: pulls the full Salesforce record, reads through Gong transcripts, checks the prospect's LinkedIn profile. If there isn't much internal history, it goes to the web with Exa to understand what the company is doing with AI right now.
How it writes the email draft depends on the state of the relationship. The agent follows a defined outbound skill, a playbook it loads before drafting. The skill is designed to cover both warm and cold cases. An existing customer gets something different than a warm prospect, who gets something different than a cold contact. For cold outreach, the agent keeps it brief and research-backed, following a playbook we've defined in the skill.
imageThe rep sees the finished draft in a Slack DM with buttons to send, edit, or cancel. They can also see the agent's reasoning, so it's clear why it took a particular angle. If they send it, the agent queues up a set of follow-up emails to optionally enroll the prospect in.
As we've refined the agent, we added a 48-hour SLA for silver leads: if a rep hasn't approved or declined the draft within that window, it sends automatically. This has meaningfully increased our follow-up rate for leads that would otherwise slip through without a response.
imageAccount intelligence
As our team scaled, reps started owning anywhere from 50 to over 100 accounts each. At that volume, it's easy for things to go quiet or for expansion opportunities to slip through.
Every Monday morning, the agent pulls data from Salesforce and BigQuery. It then checks the outside world for funding rounds, product launches, and new AI initiatives. We tailored the reports for two audiences: our sales team and our deployed engineering team, since they care about different data points.
For sales, the agent aggregates signals across product usage, developer ecosystems, web activity, hiring trends, and company news to surface expansion opportunities. It flags executive moves, spikes in package installations, and whether a company is actively hiring AI engineers or building agentic systems – which is a strong signal they're ready to expand. It also identifies potential good fits when we launch new features, matching accounts whose recent activity aligns well with the new features. And because knowing an account is active isn't enough on its own, it surfaces which individuals are most engaged and suggests who to reach out to next.
For deployed engineers, the focus shifts to account health. The agent pulls product usage from BigQuery, highlights from recent customer calls, upcoming renewal dates, and cases where a customer is close to running out of credits. It also surfaces open questions and unresolved threads from recent calls. The goal is to flag what actually needs a person to step in, so the team isn't spending Sunday evenings digging through dashboards.
imageHow we built it
The agent needed to pull from multiple sources, reason across them, and produce a personalized output. This is more than a simple LLM call can handle reliably.
We chose Deep Agents for the multi-step orchestration because the inputs are inherently spiky: meeting data, CRM history, and web research vary a lot in size and structure. With Deep Agents, large tool results get offloaded into a virtual filesystem automatically, so we didn't have to build our own truncation and retrieval layer. We also used the harness's native planning tooling to enforce a consistent checklist (do-not-send checks → research → draft → rationale → follow-ups), which made runs easier to debug and reduced agent wandering.
imageWe connected the agent to LangSmith so we could understand how sales reps were actually using it and measure whether the agent was improving over time. That meant setting up evaluations from the start rather than retrofitting them later, which turned out to be critical for catching regressions when we iterated on prompts or swapped model versions.
Agent patterns
Moving our GTM agent to production surfaced two problems we had to solve: how to make the agent learn from the people using it, and how to keep runs efficient at scale.
Memory
When a rep edits a draft in Slack, the system compares the original against the revised version. If the changes are substantive, an LLM analyzes the diff and extracts structured style observations: what changed, what it implies about the rep's preferences, and an optional quoted example. Those observations are stored in PostgreSQL, keyed per rep, and every future run reads them before drafting.
Each rep has stylistic preferences around tone and brevity. The feedback loop is automatic. Every edit teaches the agent, and the next draft reflects it. A weekly cron compacts these memories to keep them from getting bloated over time.
imageSubagent delegation
Account intelligence runs through compiled subagents: lightweight agents with constrained tool sets and structured output schemas that act as contracts with the main agent. The sales research subagent has access to Apollo, Exa, and BigQuery, and returns structured prospect and market context. The deployed engineer subagent uses Salesforce, Gong, and support tools to return usage trends, open tickets, and expansion signals.
The parent agent spawns one subagent per account, keeping tools isolated and outputs predictable. Because subagents run independently, we can execute them in parallel. LangSmith Deployment handles horizontal scaling and durable execution, so the system stays reliable as volume grows.
imageEvals and feedback
Before writing any production code for a new workflow, we define what success looks like in LangSmith. We started with a small library of representative scenarios grounded in the situations our reps actually face, used those to build the initial agent or feature, and made sure the fundamentals work before expanding.
Once things were functional, we broadened the evaluation set in LangSmith to cover harder cases: a researcher deep in agentic AI or NLP, an existing customer we're trying to re-engage, accounts with prior Gong transcripts, verticals with heavy jargon like healthcare. Everything runs through a test harness that mocks our external APIs so we can observe behavior in a controlled environment before it touches real data.
We evaluate on two levels. First, rule-based assertions check the basics: right tools, right order, no duplicate drafts. Second, an LLM judge scores tone, word count, and formatting. Both run as part of a full eval suite in CI, and we treat any unexplained drift in agent behavior as a bug worth investigating.
But evals only tell part of the story. What actually matters is how reps use the drafts day to day. We track every Slack action (send, edit, cancel) and attach it directly to the trace in LangSmith. Over time, this lets us correlate writing patterns with real outcomes: which styles drive opens, which subject lines get replies. When something holds across enough reps, we codify it into the agent's default behavior.
The LangSmith eval suite and the rep feedback loop reinforce each other. One catches regressions, the other drives improvement.
Adoption beyond the sales team
The GTM agent started as an ambient agent, running as a background process. A lead appears in Salesforce, the agent runs, a draft lands in the rep's Slack. No trigger, no manual work.
We later built a conversational Slack interface as a side experiment, mostly to give SDRs a way to interact with the agent directly. What we didn't expect was how quickly it spread to the rest of the company. Because the agent was already connected to Salesforce, Gong, BigQuery, and Gmail, people found uses we hadn't designed for. Engineers checked product usage without writing SQL. Customer success pulled support history before renewal calls. Account executives summarized Gong transcripts before meetings.
We didn't build any of those workflows intentionally. The agent had the access, and people found the path of least resistance. Talking to the bot was easier than opening six different tabs.
We'll cover how other teams are using the GTM agent in a follow-up post.
Learnings
A few things we'd tell someone starting from scratch:
Start with a definition of success, not code. Before we write any production code for a new workflow, we define what good looks like and build a small scenario library around it. That set expands as the agent matures. By the time something ships, we have an eval test suite that catches regressions, flags drift, and runs in CI automatically.
Human-in-the-loop goes beyond safety. It turned out to be a data collection mechanism. Every rep action (send, edit, cancel) became a signal we could learn from. The memory system and feedback loop work because reps are in the flow.
Connect the agent to your systems of record from the start. The organic adoption across the company happened because the agent already had access to the data people needed. We didn't plan for engineers or customer success to use it, but that usage spread because the access was already there.
Long-running workflows need the right infrastructure. This agent required much more than a simple LLM call with a tool or two. It needed to pull from multiple sources, reason across them, run subagents in parallel, and maintain state across turns. Picking an agent harness, Deep Agents, built for that kind of orchestration saved us from rebuilding infrastructure from scratch.
We're still early. The GTM agent handles a real workflow today, but the feedback loops we've built – including memory, evals, and rep actions tied to traces – are what will make it meaningfully better over the next six months.
And it’s an active member in Slack!
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み