最近発見した最も興味深いAIエージェントプロジェクトは何ですか？

最近、私にとって最も興味深い方向性は、エージェント自体よりもエージェントインフラストラクチャです。

計画や記憶は素晴らしいですが、実際のボトルネックはコネクタ層にあるようです。OAuth、トークン、APIスコープ、ローカルシークレット、安全な実行、リトライ、そしてエージェントが実際のサービスを、資格情報を漏洩したりワークフローを壊したりせずに使用できるようにすることです。

新しいフレームワークほど派手ではありませんが、おそらくエージェントを実際に役立つものにするためには、はるかに近いものです。

AIエージェントのあり方についての私の見方を変えることで、それらに対する視野が広がりました。私はそれらをエージェントというよりも従業員として見るようになり始めています。その視点に固定することで、特にクライアント向けに、それらを異なる方法で設定せざるを得なくなりました。今では「この新入社員に私やクライアントのために何をしてもらいたいか？」という質問から始めます。エージェントをリモートワーカーとして見ることで、すべてが変わります：彼らにどのようにコミュニケーションを取ってほしいか？会社や私について、仕事を理解するのに役立つどんな情報を伝えられるか？「採用された」タスクを学び始めるために、どんなプロセスやファイルを与えられるか？

あるケースでは、会社のメール、ハンドブック、いくつかのスプレッドシートでオンボーディングされたエージェントが、今では上司に入札スプレッドシートを送り、必要な質問をして明確にすることができます。毎週、給与計算に自分の時間を報告することさえします。別のケースでは、ウェブサイトを作成・改善するために雇われたAIエージェントに、目標が与えられ、これ以上のインプットは期待せず、その分野で最高のウェブサイトにするように指示されました。毎日ウェブサイトに取り組み、トラフィックの多いトピック、トラフィック不足の場合のSEO改善、訪問者からのメールへの返信など、何に取り組むべきかを知るためにインプットを評価します。

AIエージェントとCODEX、Claude Codeなどの既存の半自律ツールを区別するのであれば、これらのAIエージェントはどのように異なる使い方をされるべきでしょうか？私は、それらを異なる方法で（より大きな利益を想定して）使うためには、それらを異なる方法で扱い、見る必要がある、つまり熱心で学習の早い人のように扱う必要があるという方向に進んでいます。

私はこの1年間、まさにこの分野のインフラストラクチャ側で活動してきました。（完全な開示：私はPipesHubというオープンソースプロジェクトを構築しています）。

問題を別の方法で解決するというあなたの指摘について—私たちは、現在誰もがより優れた推論フレームワークとエージェントループの構築に夢中になっていることに気づきました。しかし、最も賢いエージェントでさえ、非常に基本的な理由で本番環境で完全に崩壊することがわかりました。それは、乱雑でサイロ化された企業データに簡単にアクセスしたり、理解したりできないことです。

私たちは、エージェントが基本的な質問に答えるためだけにカスタムデータパイプラインを構築することに非常に不満を感じ、使用しているフレームワークの下に配置される専用のコンテキストおよび検索レイヤーを構築することにしました。

私たちのアーキテクチャの転換は、「ベクターDBを使ってチャンクをプロンプトにダンプする」アプローチを捨てることでした。ベクター検索と並べてナレッジグラフを配線しました。これにより、エージェントは自身の検索を駆動します—ハードなメトリクスや関係性が必要な場合はグラフにアクセスし、広範なコンテキストが必要な場合はドキュメントを取得します。

全体の目標は、初回価値実現までの時間を可能な限りゼロに近づけることでした。コアエンジンをオープンソース化したので、開発者はリポジトリを取得してローカルでアーキテクチャを立ち上げ、テストできます。

もし皆さんが自律システムのメモリとデータインフラストラクチャ側を掘り下げているなら、リポジトリを覗いてみて、このコンテキストへのアプローチが理にかなっているかどうか教えてください。