エージェントフレームワークをどう捉えるべきか
LangChain Blog は、複雑化するエージェントフレームワークの設計思想と選択基準を理解するための思考法を提示し、開発者が技術選定における本質的な判断力を高めるよう促している。
キーポイント
フレームワーク間の比較限界の認識
特定のフレームワークが他より優れているという絶対的な評価は難しく、各フレームワークには固有の設計哲学とトレードオフが存在することを強調する。
問題定義から逆算した選定プロセス
技術の機能やトレンドに惑わされず、解決すべき具体的な課題（ユースケース）を明確にした上で、それに適したフレームワークを選ぶべきだと説く。
抽象化レベルと制御性のトレードオフ
高い抽象化は開発速度を上げるが制御性を損ない、低レベルなアプローチは柔軟性が高いが実装コストが増大するというバランスの重要性を指摘する。
影響分析・編集コメントを表示
影響分析
この記事は、AI エージェント開発が急成長する中で生じる「ツール過多」や「トレンド追従型選定」への警鐘を鳴らすものであり、開発者が技術選定の質を高めるための重要な指針となる。業界全体として、単なるツールの比較から、アーキテクチャ設計の文脈における適切な判断へと成熟を促す影響がある。
編集コメント
技術選定における「目的と手段」の混同を防ぐための、非常に示唆に富む視点提供記事です。
TL;DR:
- 信頼性の高いエージェントシステムを構築する上で難しい部分は、各ステップにおいて LLM（大規模言語モデル）が適切なコンテキストを持っていることを保証することです。これには、LLM に含める内容を正確に制御することと、関連するコンテンツを生成するために適切なステップを実行することが含まれます。
- エージェントシステムは、ワークフローとエージェント（およびその間のあらゆるもの）の両方から構成されます。
- 多くのエージェントフレームワークは、宣言型または命令型のオーケストレーションフレームワークではなく、単なるエージェントの抽象化のセットに過ぎません。
- エージェントの抽象化は始めやすくする一方で、しばしば複雑さを増し、各ステップで LLM が適切なコンテキストを持っていることを保証することを困難にする可能性があります。
- 形状や規模が異なるあらゆる形態のエージェントシステム（エージェントまたはワークフロー）は、フレームワークによって提供されるか、ゼロから構築されることとなる、同じセットの便利な機能から恩恵を受けます。
- LangGraph は、宣言型と命令型の両方の API を備えたオーケストレーションフレームワークとして捉えるのが最も適切であり、その上に一連のエージェント抽象化が構築されています。
OpenAI は最近、エージェントの構築に関するガイドを公開しましたが、そこには以下のような誤った見解が含まれています：
この呼びかけは当初私を怒らせましたが、回答を書くことを始めてから気づきました：エージェントフレームワークについて考えるのは複雑なのです！おそらく 100 種類以上の異なるエージェントフレームワークがあり、比較するための軸も多数存在します。時にはそれらが混同され（例えばこの引用のように）、過度な宣伝やポーズ、ノイズが溢れています。しかし、エージェントフレームワークに関する精密な分析や思考はほとんど行われていません。このブログはその試みです。以下をカバーします：
- 背景情報
エージェントとは何か？
- エージェント構築の難しさ
- LangGraph とは何か？
- エージェントフレームワークの種類
「エージェント」対「ワークフロー」
- 宣言型 vs 非宣言型
- エージェント抽象化
- マルチエージェント
- よくある質問
フレームワークの価値とは何か？
- モデルが向上すれば、すべてがワークフローではなくエージェントになるのか？
- OpenAI はその見解で何を間違えたのか？
- すべてのエージェントフレームワークはどのように比較されるか？
本ブログ全体を通じて、いくつかの資料を繰り返し参照します：
- エージェント構築に関する OpenAI のガイド（私は特に良いとは思っていません）
- 効果的なエージェント構築に関する Anthropic のガイド（これは非常に気に入っています）
- LangGraph（信頼性の高いエージェントを構築するための私たちのフレームワーク）
背景情報
本ブログの残りの部分を準備するための有益な文脈。
エージェントとは何か
エージェントには一貫した定義がなく、しばしば異なる視点から提示されます。
OpenAI は、エージェントを定義する際に、より高レベルで思想的リーダーシップを発揮するアプローチを取っています。
**エージェントとは、あなたの代わりに独立してタスクを完了するシステムです。
私は個人的にこの定義を好んでいません。これは実際にはエージェントが何かを理解するのに役立たない曖昧な声明であり、単なる思想リーダーシップであって、実用的ではありません。
これを Anthropic の定義と比較してみましょう:
「エージェント」は複数の方法で定義できます。ある顧客は、エージェントを、さまざまなツールを使用して複雑なタスクを完了するために、長期間にわたって独立して動作する完全に自律的なシステムとして定義します。他の人々は、この用語を、事前に定義されたワークフローに従うより指示的な実装を説明するために使用しています。Anthropic では、これらのすべてのバリエーションをアジェンティック・システムと分類しますが、ワークフローとエージェントの間には重要なアーキテクチャ上の区別を設けます:ワークフローとは、LLM とツールが事前に定義されたコードパスを通じてオーケストレーションされるシステムです。
一方、エージェントは、LLM が自身のプロセスやツールの使用を動的に指示し、タスクをどのように完了するかについて制御を維持するシステムです。
私は Anthropic の定義をいくつかの理由で好んでいます:
- エージェントの定義がはるかに精密で技術的です。
- また、「アジェンティック・システム」という概念にも言及しており、ワークフローとエージェントの両方をそのバリエーションとして分類しています。これは素晴らしいと思います。
💡
実際に運用されている「アジェンティック・システム」のほとんどは、ワークフローとエージェントの組み合わせです。
ブログ記事の後半部分で、Anthropic はエージェントを「通常は環境からのフィードバックに基づいてツールを使用する LLM のループ」と定義しています。
冒頭でエージェントに対して壮大な定義を掲げているにもかかわらず、これは基本的に OpenAI が意味するところとほぼ同じです。
これらの種類のエージェントは、以下のパラメータによって特徴づけられます：
- 使用するモデル
- 使用する指示（システムプロンプト）
- 使用するツール
ループ内でモデルを呼び出します。モデルがツールの呼び出しを決定した場合、そのツールを実行し、何らかの観測結果やフィードバックを取得して、それを LLM に戻します。LLM がツールの呼び出しを行わないと判断するまで（または停止基準を満たすツールを呼び出すまで）、この処理を続けます。
OpenAI と Anthropic の両社は、ワークフローがエージェントとは異なる設計パターンであることを明確に指摘しています。ここでは LLM の制御は弱く、フローはより決定論的になります。これは有益な区別です！
OpenAI と Anthropic はどちらも、必ずしもエージェントが必要であるわけではないことを明示的に述べています。多くの場合、ワークフローの方が単純で、信頼性が高く、コストが安く、高速であり、パフォーマンスも優れています。Anthropic の記事からの素晴らしい引用：
**LLM を用いてアプリケーションを構築する際は、可能な限り最もシンプルな解決策を見つけることを推奨し、必要が生じた場合にのみ複雑さを増すようにしてください。これは、エージェントシステム自体を構築しないことにもなり得ます。エージェントシステムは、より優れたタスクパフォーマンスのためにレイテンシとコストをトレードオフすることが多く、このトレードオフがどの時点で妥当となるかを検討する必要があります。
より多くの複雑さが正当化される場合、ワークフローは明確に定義されたタスクに対して予測可能性と一貫性を提供しますが、大規模な柔軟性とモデル駆動型の意思決定が必要となる場合はエージェントの方が優れた選択肢となります。
OpenAI も同様の見解を示しています:
エージェントの構築を決定する前に、ユースケースがこれらの基準を明確に満たすことを検証してください。そうでない場合、決定論的な解決策で十分である可能性があります。
実際には、「エージェントシステム」のほとんどはワークフローとエージェントの組み合わせであることがわかります。そのため、私は実際に「それがエージェントかどうか」という議論よりも、「システムがどの程度エージェント的か」という議論を好みます。この考え方の提案者である素晴らしいアンドリュー・ン氏に感謝します こちら をご覧ください:
**何かがエージェントかどうかを二元的に選択する必要があるのではなく、システムは異なる程度で「エージェント的」であると考えた方がより有用だと考えました。名詞の「エージェント」とは異なり、「エージェント的（agentic）」という形容詞を用いることで、そのようなシステムを考察し、これらすべてをこの成長中のムーブメントに含めることができます。
エージェント構築の難しさとは何でしょうか？
私は、ほとんどの人がエージェントを構築するのは難しいと同意するだろうと思います。あるいは——プロトタイプとしてのエージェントを作るのは簡単ですが、ビジネスに不可欠なアプリケーションを支える信頼性の高いものを作ることは難しいのです。
その難しさの本質はまさに「信頼性を高めること」にあります。Twitter で見栄えのするデモを簡単に作れるかもしれません。しかし、それをビジネスに不可欠なアプリケーションの基盤として運用できるでしょうか？多くの労力なしにはできません。
数ヶ月前、エージェント構築者たちに対して調査を行い、「生産環境でより多くのエージェントを導入する際の最大の制限は何ですか？」と尋ねました。圧倒的に多かった回答は「パフォーマンスの質」でした——依然としてこれらのエージェントを機能させるのは非常に難しいのです。
*なぜエージェントの性能が時折低下するのでしょうか？* 大規模言語モデル（LLM）が誤作動を起こすからです。
*なぜ LLM は誤作動を起こすのでしょうか？* 2 つの理由があります：(a) モデル自体が十分ではない、(b) モデルに渡されるコンテキストが不適切（または不完全）であること。
私たちの経験則では、後者のケースが非常に頻繁に見られます。これを引き起こす要因は何でしょうか？
- 不十分または短すぎるシステムメッセージ
- 曖昧なユーザー入力
- 適切なツールへのアクセス権がない
- ツールの説明が不明瞭である
- 正しいコンテキストが渡されていない
- 不適切にフォーマットされたツールのレスポンス
💡
信頼性の高いエージェントシステムを構築する上で難しい部分は、各ステップにおいて LLM が適切なコンテキストを持っていることを保証することです。これには、LLM に入力される内容を正確に制御することと、関連するコンテンツを生成するために適切なステップを実行することが含まれます。**
エージェントフレームワークについて議論する際、この点を心に留めておくことが役立ちます。LLM に渡される正確な内容を制御しにくくするフレームワークは、単に邪魔をしているだけです。正しいコンテキストを LLM に渡すこと自体がすでに十分難しいのに、なぜ自らそれを難しくする必要があるのでしょうか？
LangGraph とは何か
💡
LangGraph は、宣言型と命令型の両方の API を備えたオーケストレーションフレームワーク（orchestration framework: 調整・制御フレームワーク）として考えられ、その上に一連のエージェント抽象化（agent abstractions: エージェントの抽象概念）が構築されています。
LangGraph は、エージェントシステムを構築するためのイベント駆動型フレームワークです。これを使用する最も一般的な方法は以下の 2 つです：
- 宣言的でグラフベースの構文
- 低レベルフレームワークの上に構築されたエージェント抽象化
LangGraph は 機能的 API もサポートしており、さらに基盤となる イベント駆動型 API にも対応しています。Python と Typescript の両方のバリアントが存在します。
エージェントシステムは、ノードと エッジ として表現できます。ノードは作業の単位を表し、一方エッジは遷移を表します。ノードとエッジは単なる通常の Python または TypeScript のコードに過ぎません。つまり、グラフの構造は宣言的な方法で表現されますが、グラフロジックの内部動作は通常の命令型コードです。エッジには 固定 型と 条件付き 型の両方があります。したがって、グラフの構造は宣言的ですが、グラフ内を通過する経路は完全に動的になり得ます。
LangGraph には 組み込みの永続化レイヤー が備わっています。これにより、フォールトトレランス、短期記憶、および 長期記憶 が可能になります。
この永続化レイヤーはまた、「人間-in-the-loop」および「人間-on-the-loop」といったパターン、つまり中断、承認、再開、タイムトラベルなどを可能にします。
LangGraph にはトークン、ノード更新、任意のイベントのストリーミング [streaming] に対する組み込みサポートがあります。
LangGraph は、デバッグ、評価、観測のために LangSmith とシームレスに統合されます。
エージェントフレームワークの種類
エージェントフレームワークはいくつかの次元において異なります。これらの次元を理解し、混同しないことが、エージェントフレームワークを適切に比較するための鍵となります。
ワークフロー vs エージェント
ほとんどのフレームワークには、より高レベルなエージェント抽象化が含まれています。一部のフレームワークには、一般的なワークフローのための抽象化も含まれています。LangGraph は、エージェントシステムを構築するための低レベルのオーケストレーションフレームワークです。LangGraph は ワークフロー、エージェント、およびその間のあらゆるもの をサポートしています。私たちはこれが重要だと考えています。前述したように、生産環境で稼働しているほとんどのエージェントシステムは、ワークフローとエージェントの組み合わせです。本番環境対応のフレームワークは両方をサポートする必要があります。
信頼性の高いエージェントを構築する際の難しさ、つまり LLM に適切なコンテキストを提供することについて思い出しましょう。ワークフローが有用な理由の一部は、LLM に対して適切なコンテキストを渡すことを容易にする点にあります。データの流れをあなたが完全に決定できるのです。
アプリケーションを「ワークフロー」から「エージェント」までのスペクトラム上のどこに構築するかを考える際、2 つの点を考慮する必要があります：
- 予測可能性と自律性のトレードオフ
- 低い参入障壁と高い拡張性
予測可能性と自律性のトレードオフ
システムがよりエージェンシー（自律性）を持つようになるほど、その挙動は予測しにくくなります。
時には、ユーザーの信頼獲得や規制対応などの理由から、システムの挙動を予測可能にしたい、あるいはそうする必要がある場合があります。
信頼性と予測可能性は 100% 一致するわけではありませんが、実務的にはこれらが密接に関連していることが多いです。
この曲線上でどこを目指すかは、アプリケーションごとに非常に具体的になります。LangGraph を用いれば、この曲線上のあらゆる地点でアプリケーションを構築でき、あなたが目指す特定のポイントに移動することも可能です。
低い参入障壁と高い拡張性
フレームワークを考える際、その「床（参入障壁）」と「天井（拡張性）」について考えるのは有益です：
- Low floor（低い参入障壁）：初心者にも親和性が高く、すぐに使い始められるフレームワーク
- High floor（高い参入障壁）：学習曲線が急峻であり、効果的に使用するには相当な知識や専門性が求められるフレームワーク
- Low ceiling（低い天井）：実現可能な範囲に制限があり、すぐに限界に達してしまうフレームワーク
- High ceiling（高い天井）：高度なユースケースに対して広範な機能と柔軟性を提供し、ユーザーの成長とともに拡張可能となるフレームワーク
Workflow フレームワークは高い天井を持ちますが、参入障壁も高いです。エージェントロジックの多くを自分で記述する必要があります。
Agent フレームワークは参入障壁が低く、すぐに使い始められますが、非自明なユースケースには不十分な場合があります。
LangGraph は、低い参入障壁（組み込みのエージェント抽象化によりすぐに使い始められる）と高い天井（高度なユースケースを実現するための 低レベル機能）の両方の側面を持つことを目指しています。
宣言的 vs 非宣言的
宣言的フレームワークにはメリットがあります。一方で欠点もあります。これはプログラマーの間で尽きることのない議論であり、人によって好みが分かれます。
「非宣言的」と言う場合、通常は対義語として「命令的」を指しています。
多くの人は LangGraph を宣言的フレームワークと説明しますが、それは部分的にしか正しくありません。
まず、ノードとエッジ間の接続は宣言的な方法で行われますが、実際のノードやエッジ自体は単なる Python や TypeScript の関数に過ぎません。したがって、LangGraph は宣言型と命令型の融合のようなものです。
第二に、推奨される宣言型 API 以外にも他の API を実際にサポートしています。具体的には、機能的 API と イベント駆動型 API の両方をサポートしています。宣言型 API が有用なメンタルモデルであると考えていますが、すべての人に適しているわけではないことも認識しています。
LangGraph に関する一般的なコメントとして、「これは Tensorflow（宣言型の深層学習フレームワーク）のようであり、Agents SDK などのフレームワークは Pytorch（命令型の深層学習フレームワーク）のようだ」というものがあります。
これは誤りです。Agents SDK（および元の LangChain、CrewAI など）のようなフレームワークは、宣言型でも命令型でもありません。それらは単なる抽象化です。エージェントの抽象化（Python クラス）を持ち、その中にエージェントを実行する一連の内部ロジックが含まれています。これらは本質的にオーケストレーションフレームワークではなく、単なる抽象化に過ぎません。
エージェント抽象化
ほとんどのエージェントフレームワークには、エージェントの抽象化が含まれています。通常は、プロンプト、モデル、ツールを扱うクラスとして始まり、その後いくつかのパラメータが追加され…さらに多く追加され…そしてさらに多くのパラメータが加わります。最終的に、多様な振る舞いを制御する無数のパラメータの羅列となり、すべてがクラスの背後に抽象化されてしまいます。何が起こっているかを確認したりロジックを変更したい場合、クラスの中に入り込んでソースコードを修正する必要があります。
💡
これらの抽象化は、各ステップで LLM（大規模言語モデル）に実際に入力される内容を理解したり制御したりすることを非常に困難にしてしまいます。これは重要です—この制御権を持つことは、信頼性の高いエージェントを構築する上で不可欠です（前述の通り）。これがエージェント抽象化が抱える危険性です。
私たちは痛い目を見てこれを学びました。これが元々の LangChain のチェーンやエージェントにおける問題でした。それらは邪魔になる抽象化を提供していたのです。2 年前のその中の一つの抽象化として、モデル、プロンプト、ツールを受け取るエージェントクラスがありました。これは新しい概念ではありません。当時十分な制御権を返すものではなかったし、現在も同様です。
明確に言っておきますが、これらのエージェント抽象化にはある程度の価値があります。始めるのが容易になるからです。しかし、信頼性の高いエージェントを構築するには、これらのエージェント抽象化はまだ十分ではないと考えています（おそらく永遠にそうではないでしょう）。
これらのエージェント抽象化を捉える最良の方法は、Keras のように考えることです。これらは簡単に始められるためのより高レベルな抽象化を提供しますが、それらが下位レベルのフレームワークの上に構築されており、将来的に使いこなせなくなることを防ぐことが極めて重要です。
そのため、私たちはエージェント抽象化を LangGraph 上に構築しました。これにより、エージェントを簡単に始めることができますが、必要に応じて下位レベルの LangGraph に容易に切り替えることも可能です。
マルチエージェント
多くの場合、エージェントシステムは単一のエージェントだけでなく、複数のエージェントを含みます。OpenAI はそのレポートで次のように述べています：
**多くの複雑なワークフローにおいて、プロンプトやツールを複数のエージェントに分割することで、パフォーマンスとスケーラビリティの向上が図れます。エージェントが複雑な指示に従えなかったり、誤ったツールを継続的に選択したりする場合は、システムをさらに細分化し、より明確に区別されたエージェントを導入する必要があります。
💡
マルチエージェントシステムの鍵となる部分は、それらがどのように通信するかです。再び言いますが、エージェント構築における難しい点は、LLM に対して適切なコンテキストを提供することです。これらのエージェント間のコミュニケーションは非常に重要です。
これを行う方法は数多くあります！ハンドオフはその一つです。これは私が実際に非常に気に入っている Agents SDK のエージェント抽象化の一つです。
しかし、これらのエージェントが通信するための最良の方法は、場合によってはワークフローであることもあります。Anthropic のブログ記事にあるすべてのワークフロー図を抽出し、LLM 呼び出しをエージェントに置き換えてみてください。このワークフローとエージェントの融合は、しばしば最も高い信頼性をもたらします。
再び申し上げますが、エージェントシステムは単なるワークフローでもなければ、単一のエージェントでもありません。それらはしばしば両者の組み合わせとして機能します。Anthropic のブログ記事で指摘されているように：
これらのパターンを組み合わせ、カスタマイズする**これらのビルディングブロック（構成要素）は指針となるものではありません。開発者が異なるユースケースに合わせて形状を変え、組み合わせることのできる一般的なパターンです。
一般的な質問
評価すべきフレームワークの異なる軸を定義し、探求したところで、次にいくつかの一般的な質問に答えてみましょう。
フレームワークの価値とは何か？
エージェントシステムを構築するためにフレームワークが必要かどうかを疑問視する人々をよく見かけます。エージェントフレームワークはどのような価値を提供できるのでしょうか？
エージェント抽象化（Agent Abstractions）
フレームワークは、始めるのに容易にし、エンジニアがプロジェクトを構築・保守するための共通の手段を提供するという点で汎用的に有用です。これはオンボーディングとメンテナンスを容易にします。上記でも言及した通り、エージェント抽象化には実際のデメリットも存在します。ほとんどのエージェントフレームワークにおいて、これが提供する唯一の価値となっています。しかし、LangGraph については、このようにならないように非常に努力しました。
短期記憶（Short-term memory）
今日の多くのエージェント型アプリケーションには、何らかのマルチターン（例：チャット）コンポーネントが含まれています。LangGraph は、マルチターン体験（スレッド）を可能にするための本番環境対応ストレージ を提供しています。
長期記憶
まだ初期段階ではありますが、エージェントシステムが経験から学習する（例えば、会話間を跨いで情報を記憶するなど）ことに対して非常に楽観的です。LangGraph は、スレッド間の記憶のための本番環境対応ストレージ を提供しています。
人間ループ（Human-in-the-loop）
多くのエージェント型システムは、何らかの人間ループコンポーネントを備えることでより良くなります。例としては、ユーザーからのフィードバックを取得する、ツール呼び出しの承認を行う、またはツール呼び出しの引数を編集するなどがあります。LangGraph は、本番環境システムでこれらのワークフローを可能にするための組み込みサポート を提供しています。
人間ループ外（Human-on-the-loop）
実行中のエージェントに対してユーザーが影響を与えることを許可するだけでなく、事後にユーザーがエージェントの軌跡を検査し、さらに以前のステップに戻ってそこから変更を加えて再実行することも有用です。これを「人間ループ外」と呼び、LangGraph はこれのための 組み込みサポート を提供しています。
ストリーミング
多くのエージェント型アプリケーションは実行に時間がかかるため、エンドユーザーへの更新情報を提供することが、良好なユーザー体験を提供する上で極めて重要になります。LangGraph は、トークン、グラフステップ、および任意のストリームの 組み込みストリーミング を提供しています。
デバッグ/観測性
信頼性の高いエージェントを構築する上で難しい部分は、LLM（大規模言語モデル）に適切なコンテキストを渡していることを確認することです。エージェントが実行した正確なステップや、各ステップにおける入力・出力を調査できることは、信頼性の高いエージェントを構築するために不可欠です。LangGraph は、最高クラスのデバッグと観測性を実現するために LangSmith とシームレスに統合されています。なお：AI 観測性 は、従来のソフトウェアの観測性とは異なります（これは別の記事で詳しく扱うべきテーマです）。
フォールトトレランス
フォールトトレランスは、分散アプリケーションを構築するための従来のフレームワーク（Temporal など）における重要なコンポーネントです。LangGraph は、耐久性のあるワークフロー と 設定可能なリトライ を活用することで、フォールトトレランスの実装を容易にします。
最適化
手動でプロンプトを微調整するのではなく、評価用データセットを定義し、それに基づいてエージェントを自動的に最適化した方が簡単な場合もあります。LangGraph は現時点ではこれを標準機能としてサポートしていませんが、まだ時期尚早だと考えています。しかし、これは考慮すべき興味深い次元であり、常に注視している事項であるため、あえて記載しました。現在、これに最適なフレームワークは dspy です。
💡
これらの価値提案（エージェントの抽象化を除く）は、すべてエージェント、ワークフロー、およびその間のあらゆるものに対して価値を提供します。
では、本当にアジェンティック・フレームワークが必要なのでしょうか？
あなたのアプリケーションがこれらすべての機能を必要としない場合、または自分で実装したい場合は、フレームワークを必ずしも必要としないかもしれません。一部の機能（例えば短期記憶など）はそれほど複雑ではありません。一方で、他の機能（例えば人間によるループ制御や LLM 固有の観測性など）はより複雑です。
そしてエージェントの抽象化については、Anthropic の投稿で述べられている内容に同意します：
フレームワークを使用する場合は、その背後にあるコードを理解してください。内部構造に関する誤った仮定が、顧客のエラーの一般的な原因となっています。
モデルが向上すれば、すべてがワークフローからエージェントへと移行するのか？
エージェント（ワークフローと比較して）を支持する共通の議論の一つに、「現時点では機能しないが、将来は機能するようになるため、結局は単純なツール呼び出し型のエージェントだけで十分になる」というものがあります。
私は複数のことが同時に真実になり得ると考えています：
- これらのツール呼び出しエージェントのパフォーマンスは向上する
- LLM に何を入力するかを制御できることは依然として非常に重要である（ゴミを入れればゴミが出る）
- 一部のアプリケーションでは、このツール呼び出しループだけで十分である
- 他のアプリケーションでは、ワークフローの方が単純で、安価で、高速であり、より良いものになる
- ほとんどのアプリケーションにおいて、本番環境のエージェントシステムは、ワークフローとエージェントの組み合わせとなるだろう
OpenAI や Anthropic がこれらの点について議論するとは思わない。Anthropic の投稿から：
LLM を用いてアプリケーションを構築する際は、可能な限り最も単純な解決策を見つけることを推奨し、必要な場合にのみ複雑さを増すようにしてください。これは、エージェントシステム自体を構築しないことにもなり得る。エージェントシステムは、しばしばレイテンシとコストを犠牲にしてタスクパフォーマンスを向上させるが、このトレードオフがどの時点で妥当であるかを検討すべきだ。
そして OpenAI の投稿から：
エージェントの構築に着手する前に、ユースケースがこれらの基準を明確に満たすことを検証せよ。そうでなければ、決定論的な解決策で十分かもしれない。
この単純なツール呼び出しループだけで十分なアプリケーションが存在し得るだろうか？私は、これはおそらく、あなたのユースケースに特化した大量のデータを用いてトレーニング/ファインチューニング/強化学習されたモデルを使用している場合にのみ真実となるだろう。これは 2 つの方法で起こり得る：
- あなたのタスクはユニークです。多くのデータを収集し、独自のモデルをトレーニング/ファインチューニング/強化学習します。
- あなたのタスクはユニークではありません。大規模モデルラボが、あなたのタスクに代表されるデータでトレーニング/ファインチューニング/強化学習を行っています。（補足：もし私が、自分のタスクがユニークではない分野で垂直統合型スタートアップを構築していたなら、そのスタートアップの長期的な存続可能性についてかなり心配するでしょう）。
あなたのタスクはユニークです
ほとんどのユースケース（特にエンタープライズユースケース）がこのカテゴリに当てはまると私は確信しています。AirBnb がカスタマーサポートをどのように処理するかは、Klarna のそれとは異なり、Rakuten のそれとも異なります。これらのタスクには非常に多くの微妙な違いがあります。カスタマーサポート分野で先駆的なエージェント企業である Sierra は、単一のカスタマーサポート*エージェント*を構築しているのではなく、むしろカスタマーサポートエージェント*プラットフォーム*を構築しています：
**Sierra Agent SDK を使用すると、開発者は宣言型プログラミング言語を用いて、合成可能なスキルを組み合わせて手続き的知識を表現することで、強力かつ柔軟なエージェントを構築できます。
各企業の顧客対応体験はユニークすぎて汎用的なエージェントではパフォーマンスが十分でないため、彼らはそうする必要があります。
特定のタスク用にトレーニングされたモデルを使用した単純なツール呼び出しループを持つエージェントの一例：OpenAI の Deep Research。つまり、これは可能であり、素晴らしいエージェントを生み出すこともできます。
もし特定のタスクに対して SOTA モデルを訓練できるのであれば、確かに任意のワークフローを可能にするフレームワークは不要であり、単純なツール呼び出しループを使用するだけで済みます。この場合、エージェントがワークフローよりも好まれることになります。
私の頭の中にある非常にオープンな問いがあります：自社のタスクに対して SOTA モデルを訓練するためのデータ、ツール、あるいは知識を持っているエージェント企業はどれくらいあるのでしょうか？現時点では、大規模モデルラボのみがこの作業が可能だと考えています。しかし、これは変わるでしょうか？小さな垂直特化型スタートアップが自社のタスク向けに SOTA モデルを訓練できるようになるでしょうか？この問いに対して非常に興味を持っています。現在これに取り組んでいる方がいらっしゃいましたら、ぜひご連絡ください！
あなたのタスクはユニークではない**
一部のタスクは十分に汎用的であり、大規模モデルラボがこれらの非汎用的なタスクにおける単純なツール呼び出しループを適切に実行できる十分な品質のモデルを提供できると考えています。
OpenAI は API を通じて Computer Use モデルをリリースしました。これは汎用的なコンピュータ操作データでファインチューニングされたモデルであり、その汎用的なタスクにおいて十分に良好な性能を発揮することを目的としています。（補足：まだ十分に良い状態には至っていないと考えています）
コードはこれに関する興味深い例です。コーディングは比較的汎用的であり、これまでエージェントにとっての突破的なユースケースとなってきました。Claude Code と OpenAI の Codex CLI は、この単純なツール呼び出しループを利用するコーディングエージェントの 2 つの例です。基盤モデルが膨大なコードデータとタスクでトレーニングされていることは確実だと断言できます（Anthropic がこれを行っているという証拠は こちら を参照してください）。
興味深いことに、一般モデルがこのデータでトレーニングされる際、このデータの正確な形状がどれほど重要なのでしょうか。Ben Hylak は先日、多くの人々の共感を呼んだように思える 興味深いツイート を投稿しました。
**モデルはもうカーソルの使い方を知らない。すべてターミナル向けに最適化されているのだ。だから 3.7 や o3 は Cursor 内ではひどく、それ以外では驚異的に素晴らしいのである。
これは二つのことを示唆している可能性があります：
- あなたのタスクは、一般モデルが学習済みのタスクと非常に非常によく似ている必要があります。あなたのタスクが類似している度合いが少ないほど、一般モデルがあなたのユースケースに十分対応できる可能性は低くなります。
- 一般モデルを他の特定のタスクでトレーニングすると、あなたのタスクにおけるパフォーマンスが低下する可能性があります。Cursor のユースケースに似たデータが、新しいモデルのトレーニングにも同程度（あるいはそれ以上）使用されていることは間違いありません。しかし、わずかに異なる形状の新規データの流入がある場合、それは他のあらゆる種類のデータを上回る影響力を持ちます。これは現在、一般モデルが多数のタスクで本当に驚異的なパフォーマンスを発揮することが難しいことを示唆しています。
💡
エージェントがワークフローよりも好まれるアプリケーションであっても、低レベルなワークフロー制御とは無関係なフレームワークの特徴から恩恵を受けることになります：短期記憶ストレージ、長期記憶ストレージ、人間によるループ（human-in-the-loop）、人間による監視ループ（human-on-the-loop）、ストリーミング処理、フォールトトレランス、デバッグ/観測機能。
OpenAI はどこを間違えたのか？
OpenAI の立場を再検討すると、それは「エージェントフレームワーク」の異なる次元を混同する誤った二項対立に基づいていることがわかります。これは彼らの単一の抽象化の価値を誇張するために用いられています。具体的には、「宣言型 vs 命令型」と「エージェント抽象化」、ならびに「ワークフロー vs エージェント」を混同しています。
💡
結局のところ、これは生産環境向けのエージェントシステム構築における主な課題や、フレームワークが提供すべき本質的な価値を見失っています。その主な課題とは、開発者が LLM に到達するコンテキストを明示的に制御できつつ、永続化、フォールトトレランス（耐障害性）、人間を介したインタラクションといった生産環境上の懸念事項をシームレスに処理できる、信頼性の高いオーケストレーション層です。
私が問題視する具体的な部分を分解してみましょう:
"宣言的グラフと非宣言的グラフ"
LangGraph は完全に宣言的ではありませんが、それなりに宣言的であるため、それが私の主な不満点というわけではありません。私が本当に問題視するのは、「非宣言的」という表現が過度な役割を担い、誤解を招いている点です。通常、人々が宣言的フレームワークを批判する際によりインペラティブ（命令型）なフレームワークを望むものです。しかし、Agents SDK はインペラティブフレームワークではありません。それは抽象化です。より適切なタイトルは、「宣言的 vs インペラティブ」や「オーケストレーションフレームワークが必要か」、あるいは主張したい内容に応じて「エージェントの抽象化こそがすべて必要である理由」や「ワークフロー対エージェント」となるはずです（彼らは以下で両方の主張をしているように見えます）。
"このアプローチは、ワークフローがより動的かつ複雑になるにつれて、すぐに煩雑で困難なものになり得る"
必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:
{"translation": "翻訳全文"}
これは宣言型か非宣言型かという問題とは何の関係もありません。この問題はワークフローとエージェントの違いに関わるものです。Agents SDK でエージェントロジックを宣言的なグラフとして容易に表現でき、そのグラフは Agents SDK と同じく動的で柔軟です。
そして、ワークフロー対エージェントの点について。多くのワークフローには、このようなレベルの動的性や複雑さは必要ありません。OpenAI も Anthropic もこれを認めています。できる限りワークフローを使うべきです。ほとんどのエージェンシーシステムは組み合わせです。はい、ワークフローが本当に動的で複雑な場合はエージェントを使用すべきです。しかし、すべてにエージェントを使うべきではありません。OpenAI は論文の前半でも実際にこう述べています。
"しばしば専門的なドメイン固有言語の学習を必要とする"
再び言いますが、Agents SDK は命令型フレームワークではありません。それは抽象化です。また、ドメイン固有言語（その抽象化）も持っています。現時点では、Agents SDK の抽象化を学び、それに対応して作業する必要があることは、LangGraph の抽象化を学ぶ必要があることよりも悪いと主張します。主に、信頼性の高いエージェントを構築する上で難しいのは、エージェントが適切なコンテキストを持っていることを確認することであり、Agents SDK は LangGraph よりもはるかにそれを隠蔽しているからです。
"より柔軟である"
これは厳密に真実ではありません。むしろその逆です。Agents SDK でできることはすべて、LangGraph でもできます。Agents SDK が許容するのは、LangGraph でできることの 10% に過ぎません。
"コードファースト"
Agents SDK では抽象化を記述しますが、LangGraph では通常のコードを大量に記述します。Agents SDK の方がコードファーストであるという点について、私はその理由がわかりません。
「慣れ親しんだプログラミング構文を使用する」
Agents SDK を使うには、全く新しい抽象化のセットを学ぶ必要があります。一方、LangGraph では通常のコードを大量に記述します。これほど馴染み深いものはありません。
「より動的で適応性の高いエージェントオーケストレーションを可能にする」
これもまた、宣言型か非宣言型かの問題ではありません。これはワークフローとエージェントの違いに関する話です。上記のポイントを参照してください。
エージェントフレームワークの比較
私たちはエージェントフレームワークのさまざまなコンポーネントについて議論してきました：
- 柔軟なオーケストレーション層なのか、それとも単なるエージェント抽象化なのか？
- もし柔軟なオーケストレーション層であるなら、宣言型かそれ以外か？
- このフレームワークは（エージェント抽象化以外の）どのような機能を提供しているのか？
これらの次元をスプレッドシートにリストアップしてみるのは面白いだろうと思い、試みました。この作業においては可能な限り公平になるよう努めました（Twitter でフィードバックを求め、多くの良い意見をいただきました）。
現在、この比較には Agents SDK、Google の ADK、LangChain、Crew AI、LlamaIndex、Agno AI、Mastra、Pydantic AI、AutoGen、Temporal、SmolAgents、DSPy が含まれています。
もし特定のフレームワークを漏らした場合や、何らかの誤りがある場合は、コメントを残してください！
💡
スプレッドシートのライブ版はこちらで見つけることができます。
結論
- 信頼性の高いエージェントシステムを構築する上で難しい部分は、各ステップで LLM（大規模言語モデル）が適切なコンテキストを持っていることを保証することです。これには、LLM に取り込む内容を正確に制御することと、関連するコンテンツを生成するために適切なステップを実行することが含まれます。
- エージェントシステムは、ワークフローとエージェント（およびその間のあらゆるもの）の両方から構成されます。
- ほとんどのエージェントフレームワークは、宣言型または命令型のオーケストレーションフレームワークではなく、単なるエージェント抽象化のセットです。
- エージェント抽象化は始めやすくする一方で、各ステップで LLM が適切なコンテキストを持っていることを保証するのが難しくなり、かえって複雑さを増すことがあります。
- 形状や規模が異なるあらゆる形態のエージェントシステム（エージェントまたはワークフロー）は、フレームワークによって提供されるか、ゼロから構築されることとなる、同じセットの便利な機能から恩恵を受けます。
- LangGraph は、宣言型と命令型の両方の API を備えたオーケストレーションフレームワークとして捉えるのが最も適切であり、その上に一連のエージェント抽象化が構築されています。
原文を表示
TL;DR:
- The hard part of building reliable agentic systems is making sure the LLM has the appropriate context at each step. This includes both controlling the exact content that goes into the LLM, as well as running the appropriate steps to generate relevant content.
- Agentic systems consist of both workflows and agents (and everything in between).
- Most agentic frameworks are neither declarative or imperative orchestration frameworks, but rather just a set of agent abstractions.
- Agent abstractions can make it easy to get started, but they can often obfuscate and make it hard to make sure the LLM has the appropriate context at each step.
- Agentic systems of all shapes and sizes (agents or workflows) all benefit from the same set of helpful features, which can be provided by a framework, or built from scratch.
- LangGraph is best thought of as a orchestration framework (with both declarative and imperative APIs), with a series of agent abstractions built on top.
OpenAI recently released a guide on building agents which contains some misguided takes like the below:
This callout initially angered me, but after starting to write a response I realized: thinking about agent frameworks is complicated! There are probably 100 different agent frameworks, there are a lot of different axes to compare them on, sometimes they get conflated (like in this quote). There is a lot of hype, posturing, and noise out there. There is very little precise analysis or thinking being done about agent frameworks. This blog is our attempt to do so. We will cover:
- Background InfoWhat is an agent?
- What is hard about building agents?
- What is LangGraph?
- Flavors of agentic frameworks“Agents” vs “workflows”
- Declarative vs non-declarative
- Agent abstractions
- Multi agent
- Common QuestionsWhat is the value of a framework?
- As the models get better, will everything become agents instead of workflows?
- What did OpenAI get wrong in their take?
- How do all the agent frameworks compare?
Throughout this blog I will make repeated references to a few materials:
- OpenAI’s guide on building agents (which I don’t think is particularly good)
- Anthropic’s guide on building effective agents (which I like a lot)
- LangGraph (our framework for building reliable agents)
Background info
Helpful context to set the stage for the rest of the blog.
What is an agent
There is no consistent definition of an agent, and they are often offered through different lenses.
OpenAI takes a higher level, more thought-leadery approach to defining an agent.
Agents are systems that independently accomplish tasks on your behalf.
I am personally not a fan of this. This is a vague statement that doesn’t really help me understand what an agent is. It’s just thought-leadership and not practical at all.
Compare this to Anthropic’s definition:
"Agent" can be defined in several ways. Some customers define agents as fully autonomous systems that operate independently over extended periods, using various tools to accomplish complex tasks. Others use the term to describe more prescriptive implementations that follow predefined workflows. At Anthropic, we categorize all these variations as agentic systems, but draw an important architectural distinction between workflows and agents:Workflows are systems where LLMs and tools are orchestrated through predefined code paths.Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.
I like Anthropic’s definition better for a few reasons:
- Their definition of an agent is much more precise and technical.
- They also make reference to the concept of “agentic systems”, and categorize both workflows and agents as variants of this. I love this.
💡
Nearly all of the “agentic systems” we see in production are a combination of “workflows” and “agents”.
Later in the blog post, Anthropic defines agents as “… typically just LLMs using tools based on environmental feedback in a loop.”
Despite their grandiose definition of an agent at the start, this is basically what OpenAI means as well.
These types of agents are parameterized by:
- The model to use
- The instructions (system prompt) to use
- The tools to use
You call the model in a loop. If/when it decides to call a tool, you run that tool, get some observation/feedback, and then pass that back into the LLM. You run until the LLM decides to not call a tool (or it calls a tool that triggers a stopping criteria).
Both OpenAI and Anthropic call out workflows as being a different design pattern than agents. The LLM is less in control there, the flow is more deterministic. This is a helpful distinction!
Both OpenAI and Anthropic explicitly call out that you do not always need agents. In many cases, workflows are simpler, more reliable, cheaper, faster, and more performant. A great quote from the Anthropic post:
When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all. Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense.When more complexity is warranted, workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale.
OpenAI says something similar:
Before committing to building an agent, validate that your use case can meet these criteria clearly. Otherwise, a deterministic solution may suffice.
In practice, we see that most “agentic systems” are a combination of workflows and agents. This is why I actually hate talking about whether something is an agent, but prefer talking about how agentic a system is. h/t the great Andrew Ng for this way of thinking about things:
Rather than having to choose whether or not something is an agent in a binary way, I thought, it would be more useful to think of systems as being agent-like to different degrees. Unlike the noun “agent,” the adjective “agentic” allows us to contemplate such systems and include all of them in this growing movement.
What is hard about building agents?
I think most people would agree that building agents is hard. Or rather - building an agent as a prototype is easy, but a reliable one, that can power business-critical applications? That is hard.
The tricky part is exactly that - making it reliable. You can make a demo that looks good on Twitter easily. But can you run it to power a business critical application? Not without a lot of work.
We did a survey of agent builders a few months ago and asked them: *“What is your biggest limitation of putting more agents in production?”* The number one response by far was “performance quality” - it’s still really hard to make these agents work.
*What causes agents to perform poorly sometimes?* The LLM messes up.
*Why does the LLM mess up?* Two reasons: (a) the model is not good enough, (b) the wrong (or incomplete) context is being passed to the model.
From our experience, it is very frequently the second use case. What causes this?
- Incomplete or short system messages
- Vague user input
- Not having access to the right tools
- Poor tool descriptions
- Not passing in the right context
- Poorly formatted tool responses
💡
The hard part of building reliable agentic systems is making sure the LLM has the appropriate context at each step. This includes both controlling the exact content that goes into the LLM, as well as running the appropriate steps to generate relevant content.
As we discuss agent frameworks, it’s helpful to keep this in mind. Any framework that makes it harder to control exactly what is being passed to the LLM is just getting in your way. It’s already hard enough to pass the correct context to the LLM - why would you make it harder on yourself?
What is LangGraph
💡
LangGraph is best thought of as a orchestration framework (with both declarative and imperative APIs), with a series of agent abstractions built on top.
LangGraph is an event-driven framework for building agentic systems. The two most common ways of using it are through:
- a declarative, graph-based syntax
- agent abstractions (built on top of the lower level framework)
LangGraph also supports a functional API, as well as the underlying event-driven API. There exist both Python and Typescript variants.
Agentic systems can be represented as nodes and edges. Nodes represent units of work, while edges represent transitions. Nodes and edges are nothing more than normal Python or TypeScript code - so while the structure of the graph is represented in a declarative manner, the inner functioning of the graph’s logic is normal, imperative code. Edges can be either fixed or conditional. So while the structure of the graph is declarative, the path through the graph can be completely dynamic.
LangGraph comes with a built-in persistence layer. This enables fault tolerance, short-term memory, and long-term memory.
This persistence layer also enables “human-in-the-loop” and “human-on-the-loop” patterns, such as interrupt, approve, resume, and time travel.
LangGraph has built-in support for streaming: of tokens, node updates, and arbitrary events.
LangGraph integrates seamlessly with LangSmith for debugging, evaluation, and observability.
Flavors of agentic frameworks
Agentic frameworks are different across a few dimensions. Understanding - and not conflating - these dimensions is key to being able to properly compare agentic frameworks.
Workflows vs Agents
Most frameworks contain higher level agent abstractions. Some frameworks include some abstraction for common workflows. LangGraph is a low level orchestration framework for building agentic systems. LangGraph supports workflows, agents, and anything in-between. We think this is crucial. As mentioned, most agentic systems in production are a combination of workflows and agents. A production-ready framework needs to support both.
Let’s remember what is hard about building reliable agents - making sure the LLM has the right context. Part of why workflows are useful is that they make it easy to pass the right context to LLMs. You decide exactly how the data flows.
As you think about where on spectrum of “workflow” to “agent” you want to build your application, there are two things to think about:
- Predictability vs agency
- Low floor, high ceiling
Predictability vs agency
As your system becomes more agentic, it will become less predictable.
Sometimes you want or need your system to be predictable - for user trust, regulatory reasons, or other.
Reliability does not track 100% with predictability, but in practice they can be closely related.
Where you want to be on this curve is pretty specific to your application. LangGraph can be used to build applications anywhere on this curve, allowing you to move to the point on the curve that you want to be.
High floor, low ceiling
When thinking about frameworks, it can be helpful to think about their floors and ceilings:
- Low floor: A low floor framework is beginner-friendly and easy to get started with
- High floor: A framework with a high floor means it has a steep learning curve and requires significant knowledge or expertise to begin using it effectively.
- Low ceiling: A framework with a low ceiling means it has limitations on what can be accomplished with it (you will quickly outgrow it).
- High ceiling: A high ceiling framework offers extensive capabilities and flexibility for advanced use cases (it grows with you?).
Workflow frameworks offer a high ceiling, but come with a high floor - you have to write lot of the agent logic yourself.
Agent frameworks are low floor, but low ceiling - easy to get started with, but not enough for non-trivial use cases.
LangGraph aims to have aspects that are low floor (built-in agent abstractions that make it easy to get started) but also high ceiling (low-level functionality to achieve advanced use cases).
Declarative vs non-declarative
There are benefits to declarative frameworks. There are also downsides. This is a seemingly endless debate among programmers, and everyone has their own preferences.
When people say non-declarative, they are usually implying imperative as the alternative.
Most people would describe LangGraph as a declarative framework. This is only partially true.
First - while the connections between the nodes and edges are done in a declarative manner, the actual nodes and edges are nothing more than Python or TypeScript functions. Therefore, LangGraph is kind of a blend between declarative and imperative.
Second - we actually support other APIs besides the recommended declarative API. Specifically, we support both functional and event-driven APIs. While we think the declarative API is a useful mental model, we also recognize it is not for everyone.
A common comment about LangGraph is that is like Tensorflow (a declarative deep learning framework), while frameworks like Agents SDK are like Pytorch (an imperative deep learning framework).
This is just incorrect. Frameworks like Agents SDK (and original LangChain, CrewAI, etc) are neither declarative or imperative - they are just abstractions. They have an agent abstraction (a Python class) and it contains a bunch of internal logic that runs the agent. They’re not really orchestration frameworks. They are just abstractions.
Agent Abstractions
Most agent frameworks contain an agent abstraction. They usually start as a class that involves a prompt, model, and tools. Then they add in a few more parameters… then a few more… then even more. Eventually you end up with a litany of parameters that control a multitude of behaviors, all abstracted behind a class. If you want to see what’s going on, or change the logic, you have to go into the class and modify the source code.
💡
These abstractions end up making it really really hard to understand or control exactly what is going into the LLM at all steps. This is important - having this control is crucial for building reliable agents (as discussed above). This is the danger of agent abstractions.
We learned this the hard way. This was the issue with the original LangChain chains and agents. They provided abstractions that got in the way. One of those original abstractions from two years ago was an agent class that took in a model, prompt, and tools. This isn’t a new concept. It didn’t provide enough control back then, and it doesn’t now.
To be clear, there is some value in these agent abstractions. It makes it easier to get started. But I don’t think these agent abstractions are good enough to build reliable agents yet (and maybe ever).
We think the best way to think about these agent abstractions is like Keras. They provide higher level abstractions to get started easily. But it’s crucial to make sure they are built on top of a lower level framework so you don’t outgrow it.
That is why we have built agent abstractions on top of LangGraph. This provides an easy way to get started with agents, but if you need to escape to lower-level LangGraph you easily can.
Multi Agent
Oftentimes agentic systems won’t just contain one agent, they will contain multiple. OpenAI says in their report:
For many complex workflows, splitting up prompts and tools across multiple agents allows for improved performance and scalability. When your agents fail to follow complicated instructions or consistently select incorrect tools, you may need to further divide your system and introduce more distinct agents.
💡
The key part of multi agent systems is how they communicate. Again, the hard part of building agents is getting the right context to LLMs. Communication between these agents is important.
There a bunch of ways to do this! Handoffs are one way. This is an agent abstraction from Agents SDK that I actually quite like.
But the best way for these agents to communicate can sometimes be workflows. Take all the workflow diagrams in Anthropic’s blog post, and replace the LLM calls with agents. This blend of workflows and agents often gives the best reliability.
Again - agentic systems are not just workflows, or just an agent. They can be - and often are - a combination of the two. As Anthropic points out in their blog post:
Combining and customizing these patternsThese building blocks aren't prescriptive. They're common patterns that developers can shape and combine to fit different use cases.
Common Questions
Having defined and explored the different axes that you should be evaluating frameworks on, let’s now try to answer some common questions.
What is the value of a framework?
We often see people questioning whether they need a framework to build agentic systems. What value can agent frameworks provide?
Agent abstractions
Frameworks are generically useful because they contain useful abstractions which make it easy to get started and provide a common way for engineers to build, making it easier to onboard and maintain projects. As mentioned above, there are real downsides to agent abstractions as well. For most agent frameworks, this is the sole value they provide. We worked really hard to make sure this was not case for LangGraph.
Short term memory
Most agentic applications today involve some sort of multi-turn (e.g. chat) component. LangGraph provides production ready storage to enable multi-turn experiences (threads).
Long term memory
While still early, I am very bullish on agentic systems learning from their experiences (e.g. remembering things across conversations). LangGraph provides production ready storage for cross-thread memory.
Human-in-the-loop
Many agentic systems are made better with some human-in-the-loop component. Examples include getting feedback from the user, approving a tool call, or editing tool call arguments. LangGraph provides built in support to enable these workflows in a production system.
Human-on-the-loop
Besides allowing the user to affect the agent as it is running, it can also be useful to allow the user to inspect the agent’s trajectory after the fact, and even go back to earlier steps and then rerun (with changes) from there. We call this human-on-the-loop, and LangGraph provides built in support for this.
Streaming
Most agentic applications take a while to run, and so providing updates to the end user can be critical for providing a good user experience. LangGraph provides built in streaming of tokens, graph steps, and arbitrary streams.
Debugging/observability
The hard part of building reliable agents is making sure you are passing the right context to the LLM. Being able to inspect the exact steps taken by an agent, and the exact inputs/outputs at each step is crucial for building reliable agents. LangGraph integrates seamlessly with LangSmith for best in class debugging and observability. Note: AI observability is different from traditional software observability (this deserves a separate post).
Fault tolerance
Fault tolerance is a key component of traditional frameworks (like Temporal) for building distributed applications. LangGraph makes fault tolerance easier with durable workflows and configurable retries.
Optimization
Rather than tweaking prompts manually by hand, it can sometimes be easier to define an evaluation dataset and then automatically optimize your agent based on this. LangGraph currently does not support this out of the box - we think it is a little early for this. But I wanted to include this because I think it is an interesting dimension to consider, and something we are constantly keeping our eyes on. dspy is the best framework for this currently.
💡
All of these value props (aside from the agent abstractions) provide value for both agents, workflows, and everything in between.
So - do you really need an agentic framework?
If your application does not require all of these features, and/or if you want to build them yourself, then you may not need one. Some of them (like short term memory) aren’t terribly complicated. Others of them (like human-on-the-loop, or LLM specific observability) are more complicated.
And regarding agent abstractions: I agree with what Anthropic says in their post:
If you do use a framework, ensure you understand the underlying code. Incorrect assumptions about what's under the hood are a common source of customer error.
As the models get better, will everything become agents instead of workflows?
One common argument in favor of agents (compared to workflows) is that while they don’t work now, they will work in the future, and therefore you will just need the simple, tool-calling agents.
I think multiple things can be true:
- The performance of these tool-calling agents will rise
- It will still really important to be able to control what goes into the LLM (garbage in, garbage out)
- For some applications, this tool calling loop will be enough
- For other applications, workflows will just be simpler, cheaper, faster, and better
- For most applications, the production agentic system will be a combination of workflows and agents
I don’t think OpenAI or Anthropic would debate any of these points? From Anthropic’s post:
When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all. Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense.
And from OpenAI's post:
Before committing to building an agent, validate that your use case can meet these criteria clearly. Otherwise, a deterministic solution may suffice.
Will there be applications where this simple tool calling loop will be enough? I think this will likely only be true if you are using a model trained/finetuned/RL’d on lots of data that is specific to your use case. This can happen in two ways:
- Your task is unique. You gather a lot of data and train/finetune/RL your own model.
- Your task is not unique. The large model labs are training/finetuning/RL’ing on data representative of your task.
(Side note: if I was building a vertical startup in an area where my task was not unique, I would be pretty worried about the long term viability of my startup).
Your task is unique
I would bet that most use cases (certainly most enterprise use cases) fall into this category. How AirBnb handles customer support is different from how Klarna handles customer support which is different from how Rakuten handles customer support. There is a ton of subtlety in these tasks. Sierra - a leading agent company in the customer support space - is not building a single customer support *agent*, but rather a customer support agent *platform*:
The Sierra Agent SDK enables developers to use a declarative programming language to build powerful, flexible agents using composable skills to express procedural knowledge
They need to do this because each company’s customer support experience is unique enough where a generic agent is not performant enough.
One example of an agent that is a simple tool calling loop using a model trained on a specific task: OpenAI’s Deep Research. So it can be done, and it can produce amazing agents.
If you can train a SOTA model on your specific task - then yes, you probably don’t need a framework that enables arbitrary workflows, you’ll just use a simple tool calling loop. In this case, agents will be preferred over workflows.
A very open question in my mind is: how many agent companies will have the data, tools, or knowledge to train a SOTA model for their task? At this exact moment, I think only the large model labs are able to do this. But will that change? Will a small vertical startup be able to train a SOTA model for their task? I am very interested in this question. If you are currently doing this - please reach out!
Your task is not unique
I think some tasks are generic enough that the large model labs will be able to provide models that are good enough to do the simple tool-calling loop on these non-generic tasks.
OpenAI released their Computer Use model via the API, which is a model finetuned on generic computer use data aiming to be good enough at that generic task. (Side note: I don’t think it is close to good enough yet).
Code is an interesting example of this. Coding is relatively generic, and coding has definitely been a break out use case for agents so far. Claude code and OpenAI’s Codex CLI are two examples of coding agents that use this simple tool calling loop. I would bet heavily that the base models are trained on lots of coding data and tasks (see evidence here that Anthropic does this).
Interestingly - as the general models are trained on this data, how much does the exact shape of this data matter? Ben Hylak had an interesting tweet the other day that seemed to resonate with folks:
models don't know how to use cursor anymore.they're all being optimized for terminal. that's why 3.7 is and o3 are so awful in Cursor, and so amazing outside of it.
This could suggest two things:
- Your task has to be very very close to the task the general models are trained on. The less similar your task is, the less likely it is that the general models will be good enough for your use case.
- Training the general models on other specific tasks may decrease performance on your task. I’m sure there is just as much (if not more) data similar to Cursor’s use case used to train the new models. But if there is this influx of new data of a slightly different shape, it outweighs any other type of data. This implies it is currently hard for the general models to be really amazing at a large number of tasks.
💡
Even for applications where agents are preferred to anything workflow-like, you will still benefit features of a framework that don’t have to do with low level workflow control: short term memory storage, long term memory storage, human-in-the-loop, human-on-the-loop, streaming, fault tolerance, debugging/observability.
What did OpenAI get wrong in their take?
If we revisit OpenAI's stance, we find it to be premised on false dichotomies that conflate different dimensions of "agentic frameworks" in order to inflate the value of their singular abstraction. Specifically, it conflates “declarative vs imperative” with “agent abstractions” as well as “workflows vs agents”.
💡
Ultimately it misses the mark on what the main challenge is for building production agentic systems and the main value that should be provided by a framework, which is: a reliable orchestration layer that gives developers explicit control over what context reaches their LLMs while seamlessly handling production concerns like persistence, fault tolerance, and human-in-the-loop interactions.
Let's break down specific parts I take issue with:
”Declarative vs non-declarative graphs”
LangGraph is not fully declarative - but it’s declarative enough so that’s not my main gripe. My main gripe would be that “non-declarative” is doing a lot of work and misleading. Normally when people criticize declarative frameworks they would prefer a more imperative framework. But Agents SDK is NOT an imperative framework. It’s an abstraction. A more proper title would be “Declarative vs imperative” or “Do you need an orchestration framework” or “Why agent abstractions are all you need” or “Workflows vs Agents” depending on what they want to argue (they seem to argue both below).
”this approach can quickly become cumbersome and challenging as workflows grow more dynamic and complex”
This doesn’t have anything to do with declarative or non-declarative. This has everything to do with workflows vs agents. You can easily express the agent logic in Agents SDK as a declarative graph, and that graph is just as dynamic and flexible as Agents SDK.
And on the point of workflows vs agents. A lot of workflows do not require this level of dynamism and complexity. Both OpenAI and Anthropic acknowledge this. You should use workflows when you can use workflows. Most agentic systems are a combination. Yes, if a workflow is really dynamic and complex then use an agent. But don’t use an agent for everything. OpenAI literally says this earlier in the paper.
”often necessitating the learning of specialized domain-specific languages”
Again - Agents SDK is not an imperative framework. It is an abstraction. It also has a domain specific language (it’s abstractions). I would argue that having to learn and work around Agents SDK abstractions is, at this point in time, worse than having to learn LangGraph abstractions. Largely because the hard thing about building reliable agents is making sure the agent has the right context, and Agents SDKs obfuscates that WAY more than LangGraph.
"more flexible"
This is just strictly not true. It’s the opposite of the truth. Everything you can do with Agents SDK you can do with LangGraph. Agents SDK only lets you do 10% of what you can do with LangGraph.
“code-first”
With Agents SDK you write their abstractions. With LangGraph you write a large amount of normal code. I don’t see how Agents SDK is more code first.
”using familiar programming constructs”
With Agents SDK you have to learn a whole new set of abstractions. With LangGraph you write a large amount of normal code. What is more familiar than that?
”enabling more dynamic and adaptable agent orchestration”
Again - this doesn’t have to with declarative vs non-declarative. This has to do with workflows vs agents. See above point.
Comparing Agent Frameworks
We've talked about a lot of different components of agent frameworks:
- Are they flexible orchestration layer, or just an agent abstraction?
- If they are a flexible orchestration layer, are they declarative or otherwise?
- What features (aside from agent abstractions) does this framework provide?
I thought it would be fun to try to list out these dimensions in an spreadsheet. I tried to be as impartial as possible about this (I asked for - and got - a lot of good feedback from Twitter!).
This currently contains comparisons to Agents SDK, Google's ADK, LangChain, Crew AI, LlamaIndex, Agno AI, Mastra, Pydantic AI, AutoGen, Temporal, SmolAgents, DSPy.
If I left out a framework (or got something wrong about a framework) please leave a comment!
💡
You can find a living version of the spreadsheet here.
Conclusion
- The hard part of building reliable agentic systems is making sure the LLM has the appropriate context at each step. This includes both controlling the exact content that goes into the LLM, as well as running the appropriate steps to generate relevant content.
- Agentic systems consist of both workflows and agents (and everything in between).
- Most agentic frameworks are neither declarative or imperative orchestration frameworks, but rather just a set of agent abstractions.
- Agent abstractions can make it easy to get started, but they can often obfuscate and make it hard to make sure the LLM has the appropriate context at each step.
- Agentic systems of all shapes and sizes (agents or workflows) all benefit from the same set of helpful features, which can be provided by a framework, or built from scratch.
- LangGraph is best thought of as a orchestration framework (with both declarative and imperative APIs), with a series of agent abstractions built on top.
関連記事
LangSmith のノーコードエージェントビルダーの紹介
LangChain が提供する LangSmith に、プログラミング不要で AI エージェントを構築できる新機能が導入された。
深層エージェントにおけるコンテキスト管理
LangChain Blog は、複雑なタスクを処理する深層エージェントの性能向上のために、コンテキストを効果的に管理・最適化する手法について解説している。
マルチエージェントシステムをいつどのように構築するか
LangChain は、複数の AI エージェントが協調して複雑なタスクを解決するマルチエージェントシステムの設計手法と実装タイミングについて解説している。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み