n8nが衰退した理由： 線形LLMチェーン（n8nスタイル）では、次のステップは主に前のステップの出力しか見ません。その出力は制限されています。 エージェントループでは、各ツール呼び出しの前に、増加し続ける入力トランスクリプト（目標、以前の呼び出し、結果）が前段に置かれ、これははるかに大きなウィンドウに収まり、しばしばキャッシュされます。 n8nスタイルのチェーンは、モデルを信頼できず、モデルが保持できるコンテキストが限られていた時代のために構築されました。ジョブをノードに事前に分割することで、各ステップを小さく、決定論的で検査可能にしました。 この前提は時代遅れになりました。現代のモデルは100万トークン程度まで読み取ることができますが、1ターンあたりの出力は依然としてはるかに少なく（通常は約64k–128k）、です。 したがって、ノードチェーンは状態を繰り返し破棄します。ノードN+1は、ノードNが生成できたものだけを受け継ぎ、完全な作業セットは受け継ぎません。 エージェントループでは、モデルが1つの共有コンテキストを維持し、ツール呼び出しとその結果をそれに追加します。各呼び出しは狭い引き渡しではなく、広いキャッシュされたプレフィックスに基づいて条件付けられます。 トレーサビリティは古いパターンを救えません。「どのノードが悪い値を書き込んだか？」という質問は、「どのツール呼び出しが悪い値を書き込んだか？」という質問と同じです。 どちらも帰属の問題です。グラフはステップを明確にしますが、悪いペイロードが既にストリームに存在していた場合、事実をより信頼できるものにはしません。 アナロジー： ノードチェーンはメールパイプラインです。ライターは簡潔な指示を送信し、アーティストはその指示だけを見ます。エディターは到着した内容だけを見ます。誰も同じ机を共有しません。 エージェントは黒板です。ライター、アーティスト、エディターはすべて同じ黒板に読み書きします。黒板が状態です。ツールは封筒ではなく、その黒板上の手です。 --- 明確にしておくと、n8nという製品自体が衰退したわけではありません。衰退したのは線形LLMチェーンです。 n8nはエージェントをラップし、ワークフローをツールとして扱うことができます。 しかし、それはユーザーが通常使用していた方法ではありません。n8nを熱狂的に推奨した大多数のユーザーは、それを線形LLMチェーンのように使っていました。 モデルの能力が向上し、opencodeのようなツールが登場すると、ユーザーはほとんどのパターンでn8nの必要性を感じなくなりました。