NVIDIA NeMo Agent Toolkit MemoryがAmazon S3 Vectorsへ移行、ただし成果を左右するのは依然として検索品質

AWSがAmazon S3 VectorsとAmazon EKSを使う3部構成の実装を公開し、NVIDIAは永続的なエージェントメモリの新たな選択肢を得た。NVIDIA NeMo Agent Toolkit memoryの統合では、専用ベクターデータベースを、エージェントがセッションをまたいで共有できるマネージドベクターストレージに置き換える。

AWSは2026年10月1日にこの実装を公開した。NVIDIAのオープンソースエージェントフレームワークをカスタムS3 Vectorsプロバイダーに接続し、得られたワークフローをKubernetes上にデプロイする。焦点となるのは運用面だ。チームは耐久性が高くインフラ負荷の小さいストレージを得る一方で、記憶の選別、分離、評価、削除に関するポリシーは引き続き自ら担う。

この違いは重要である。永続メモリは、本番エージェントにおけるアプリケーション状態の一部になりつつあるためだ。Redis、Zep、Mem0などの特化プロバイダーは、メモリに特化したより豊富な機能を提供する。一方AWSは、スケール、一貫性、AWSのアクセス制御が最重要となる場合、オブジェクトストレージが永続的な検索レイヤーになり得ると主張している。

AWS、NVIDIA NeMo Agent Toolkit MemoryをS3ワークロードへ

今回の発表は、アーキテクチャ上の提案を、開発者が確認、デプロイ、テストできる具体的な実装へと転換するものだ。

このAWS実装は、3つの製品を接続する。NVIDIA NeMo Agent Toolkit、すなわちNATはエージェントのオーケストレーションと評価を担う。Amazon S3 Vectorsは検索可能なメモリを保存する。Amazon EKSはKubernetesの制御下でエージェントサービスを実行する。

NATは、エージェントワークフローの構築、プロファイリング、評価、最適化のためのオープンソースフレームワークだ。LangChain、LlamaIndex、CrewAI、Strands Agents、またはカスタムコードに基づくエージェント実装と連携できる。

そのメモリサブシステムは、単一のモデル呼び出しを超えて情報を保存する。この情報には、会話履歴、ユーザーの嗜好、過去の発見、手続き的知識などが含まれ得る。別のエージェントがコンテキストを必要とする際、プロバイダーが関連エントリーを検索する。

このフレームワークは、項目の追加、メモリの検索、項目の削除という3つの基本操作を備えたMemoryEditorインターフェースを公開している。各項目には、会話データ、タグ、メタデータ、ユーザー識別子、メモリのテキスト表現を含められる。

この抽象化により、開発者はその上位にあるエージェントを再設計せずにバックエンドを追加できる。AWSはこのインターフェースを s3vectors_memoryというカスタムプラグインで実装しており、NATはYAML設定を通じてこれを検出する。

リファレンス設計では、1つのベクターバケットと1つのベクターインデックスを作成する。ベクターバケットはベクターデータ専用に設計されたS3リソースであり、インデックスは類似度検索のために埋め込みを整理する。

この例では、1,024次元とコサイン類似度を設定している。これらの選択は、各メモリを意味の数値表現に変換するAmazon Titan Text Embeddings V2に対応する。

プロバイダーはAmazon Bedrockを介してテキストを埋め込みモデルに送る。その後、生成されたベクターを、起点と許可されたスコープを示すメタデータとともに保存する。

エージェントがメモリを検索する際、プロバイダーはクエリを埋め込み、S3 Vectorsの類似度APIを呼び出す。返されたレコードをNATのMemoryItemオブジェクトに変換してから、ワークフローへ渡す。

この実装は、エージェントレベルの制限もメタデータフィルターへ変換する。これには、agent_id、memory_type、ticker、team_id、user_id、およびレコードが共有されているかどうかを含められる。

このフィルタリング工程は、基本的な類似度検索より重要だ。意味的に関連するメモリであっても、それが別の顧客、別のエージェントロール、あるいは古くなった分析タスクに属するなら誤りとなる。

AWSは、完全なメモリ内容をフィルタリング不可のメタデータとして扱う。システムは一致するベクターとともにそのテキストを返すが、内容そのものをインデックス化してフィルタリング可能なメタデータの許容量を消費しない。

これは、大きな参照フィールドに関するAWSのガイダンスと一致する。開発者は、ID、時刻、カテゴリ、所有権など、検索を制御するコンパクトなフィールドのためにフィルターを温存できる。

サンプルはNVIDIA NeMo Agent Toolkit 1.6およびPython 3.11または3.12でテストされた。また、既存のEKSクラスター、Docker、kubectl、Bedrockへのアクセス、S3 Vectorsリソースに対する権限も前提としている。

この前提条件の一覧から、この発表は単なるプラグアンドプレイのコネクター以上のものだと分かる。すでにAWSとKubernetesの中でエージェントを運用する意思のあるチーム向けの、リファレンスアーキテクチャである。

永続メモリがマルチエージェントのリサーチ手法を変える

共有メモリにより専門エージェントは過去の作業を再利用できるが、取得されたコンテキストはチームが統制すべき依存関係にもなる。

AWSは投資リサーチのワークフローでこの設計を示している。3つの専門エージェントが、リサーチ、分析、統合の作業を分担する。

リサーチエージェントは市場情報、決算資料、ニュースを収集する。分析エージェントは定量的なパターンを探す。統合エージェントはこれらの発見をレポートにまとめる。

永続メモリがなければ、各実行は過去の作業に関する限られた知識から始まる。エージェントは同じ検索を繰り返したり、以前の結果を再計算したり、一時的なコンテキストの違いによって一貫しない結論を出したりする可能性がある。

永続ストアはこの振る舞いを変える。リサーチエージェントは、ティッカー、メモリ種別、ソースコンテキスト、共有状態とともに観察結果を保存できる。別の権限を持つエージェントは、意味的類似性とメタデータフィルターを通じて後から取得できる。

セマンティック検索は、完全一致のキーワードを必要とせず、意味に基づいて検索する。そのため、異なる表現を使った保存済みの観察結果と、利益率低下に関する質問を対応付けられる。

このアプローチは、特定のモデルのコンテキストウィンドウからもメモリを切り離す。コンテキストウィンドウとは、モデルが1回のリクエストで処理できる入力量の上限である。永続レコードは、そのリクエストの終了後も利用可能な状態で残る。

このアーキテクチャは、保存されたすべてのレコードをすべてのプロンプトに含めることを意味しない。検索では、エージェントが使い方を判断する前に、一般にtop-k結果と呼ばれる少数の候補を選ぶ。

AWSの例では、デフォルトのtop-k値を5に設定している。この値は設定上の選択であり、普遍的な最適値ではない。結果セットを小さくすればノイズを減らせる一方、より大きなセットはトークン消費と注意散漫の可能性を代償に網羅性を高められる。

NATの自動メモリラッパーは、モデルに明示的なメモリツールの呼び出しを求めることなく、情報を取り込み、取得できる。これによりプロンプトの複雑性は下がるが、重要な挙動がシステム設定へ移ることにもなる。

NVIDIAのメモリインターフェースは、こうしたプロバイダーのための契約を提供する。ただし、どの事実が長期保存に値するか、また古いメモリがいつ安全でなくなるかは決めない。

エージェント型リサーチシステムを構築するチームにとって、これは新しいエンジニアリング層を生む。メモリの抽出、重複の統合、矛盾の解消、古い主張の削除に関するルールが必要になる。

投資の例は、3つの有用なメモリクラスを示している。エピソード記憶は、過去の実行中に起きた出来事を記録する。意味記憶は、事実や関係を保存する。手続き記憶は、有効な方法や一連の行動を保持する。

これらのカテゴリーは、それぞれ異なる保持ポリシーを支えられる。検証済みの提出日付は何年も有用であり得る一方、市場価格や速報ニュースの解釈はすぐに期限切れになることがある。

また、異なるアクセスルールも必要になり得る。分析手法はチーム内で共有できるかもしれない。一方、あるユーザーのポートフォリオ詳細は、別のユーザーのクエリが意味的に似ていても分離されたままであるべきだ。

ここでNVIDIA NeMo Agent Toolkit memoryは、ストレージ機能ではなくアプリケーション設計の課題になる。バックエンドは一致するレコードを返せるが、その一致が最新で、認可され、有用かどうかを定義するのはアプリケーションだ。

この課題は、異なる規模でのパーソナルナレッジマネジメントに似ている。より多くの情報を記録しても、より良い想起が自動的に得られるわけではない。システムは出所を保ち、適切な瞬間に適切な証拠を取得しなければならない。

この課題のユーザー向け側面を探るチームは、所有権とコンテキストも保存情報の有用性を左右するパーソナルナレッジベースと比較できる。

AWSの設計は、エージェントチームに再利用可能なストレージ基盤を提供する。その真の価値は、その基盤の上に重ねられるポリシーに左右されるだろう。

S3 Vectors、専用ベクターデータベースを標準とする考え方に挑む

AWSはS3 Vectorsを、あらゆる低レイテンシー検索システムの完全な代替ではなく、耐久性の高いメモリ層として位置付けている。

NATはすでに、Mem0、MemMachine、Redis、Zepを含むメモリプロバイダーをサポートしている。これらの選択肢は、インメモリデータインフラから、メモリの抽出と管理を中心に設計されたサービスまで、エージェントメモリへの異なるアプローチを表している。

S3 Vectors統合は、別の経路を追加する。開発者はNATのオーケストレーションインターフェースを維持しながら、プロビジョニングされたベクターサーバーを必要としないストレージに埋め込みを配置できる。

AWSによれば、S3 Vectorsは強整合性のある書き込みを提供する。書き込みが成功すると直ちに検索可能となるため、複数のエージェントが同じインデックスを介して協調する際に重要となる。

結果整合性は、難しい障害モードをもたらす。あるエージェントが重要な発見を保存しても、別のエージェントがそのメモリが見えるようになる前に作業を開始する可能性がある。

強整合性は、その協調上の隔たりを小さくする。エージェントが保存された結論に同意することを保証するわけではないが、最新の正常な書き込みを取得できることは保証する。

スケールもAWSの主張の一部だ。文書化されたS3 Vectorsの制限では、1つのインデックスに最大20億ベクター、1つのベクターバケットに10,000インデックスを許容している。

このサービスは、1から4,096までのベクター次元をサポートする。各ベクターには、最大2 KBのフィルタリング可能なメタデータを含め、合計で最大40 KBのメタデータを付与できる。

こうした制限は、コンパクトな埋め込みと構造化された属性から成る大規模コレクションに適している。同時に、各ベクターに無制限のアプリケーション状態を付与するのではなく、メタデータを慎重に設計することをチームに求める。

S3 Vectorsは、コサイン距離とユークリッド距離の指標を提供する。選択した指標と次元数はインデックス作成後に変更できないため、モデル移行では新しいインデックスと再埋め込みのプロセスが必要になる可能性がある。

この不変性には注意を払うべきだ。埋め込みモデルは進化し、出力次元や推奨される距離計算が異なる場合がある。長期運用するエージェントシステムでは、最初のインデックスが不可欠になる前に、バージョニングと移行計画が必要となる。

AWSは、クエリレイテンシーを低頻度アクセスでは1秒未満、より頻繁なアクセスでは最短100ミリ秒としている。この特性は、あらゆるリアルタイム対話よりも、耐久性の高いメモリ検索に適している。

応答期限が厳しい音声アシスタントでは、より高速な提供層やキャッシュがなお必要となるかもしれない。モデル推論がすでにワークフローの大半を占める場合、非同期のリサーチエージェントは追加の1秒未満の検索を許容できることが多い。

AWSは、ハイブリッド検索、集約、ファセット検索、より高いクエリレートといった高度な検索機能が必要な場合、顧客をOpenSearchへも案内している。この区分は、S3 Vectorsがより広範なベクトルデータベースのカテゴリを置き換えるという主張を制限する。

したがって、主な競合相手は企業ではなくアーキテクチャにある。チームは、より豊富な機能を備えた専用の検索サービスを運用することも、永続的で管理負荷の低いメモリとしてマネージドのオブジェクトベース・ベクトルストレージを使うこともできる。

これは勝者総取りの選択ではない。成熟したシステムでは、S3 Vectorsを永続的な記録として使い、頻繁にアクセスされるメモリやレイテンシーに敏感なメモリには、より高速な検索レイヤーを追加できる。

NATのプロバイダー抽象化の利点は、オーケストレーション層での可搬性にある。リスクは、共通インターフェースによってバックエンド間の重要な違いが隠れてしまうことだ。

search() メソッドはコード上では均一に見えるが、再現率、フィルタリングの意味論、インデックスの挙動、スループット、障害モードは依然として異なる。開発者は自らのデータでそれらの差異を測定しなければならない。

AWSの発表は、専門的なメモリベンダーやベクトルデータベースプロバイダーに対し、追加インフラの必要性を正当化する圧力をかける。より高度な抽出、ランキング、可観測性、あるいはレイテンシーが、より良いエージェント成果につながることを示す必要がある。

同時に、この統合はAWSユーザーに対して、運用負荷の低さが検索上の妥協を隠していないことを証明するよう求める。適切なメモリがエージェントのコンテキストに現れて初めて、永続ストレージには価値が生まれる。

Amazon EKSは運用責任と引き換えに制御性を加える

EKSはエージェント層のスケーラビリティとガバナンスを実現する一方、Kubernetesアイデンティティと保存済みメモリの間にある制御はチームの責任として残す。

AWSのリファレンス実装では、リサーチエージェントをKubernetesサービスとしてデプロイしている。サンプルマニフェストは2つのレプリカで開始し、コンテナにはCPUとメモリのリクエストを定義している。

Horizontal Pod Autoscalerは、デプロイメントを1レプリカまで縮小することも、10まで拡張することもできる。サンプルは平均CPU使用率70%を目標としている。

各レプリカは同じS3ベクトルインデックスに接続する。この設計により、エージェント実行とメモリストレージが分離されるため、Podが再起動しても過去の調査結果は消去されない。

また、特定のレプリカが会話履歴の所有者になることも防ぐ。認可された任意のPodが、同じコミット済みメモリを取得できる。

このアーキテクチャは、一般にIRSAと呼ばれるIAM Roles for Service Accountsを使用する。この仕組みはKubernetesのサービスアカウントをAWSアイデンティティに関連付け、コンテナイメージ内に長期認証情報を置くことを避ける。

サンプルポリシーは、ベクトルの書き込み、クエリ、取得、削除という4つの操作を許可している。リソーススコープは指定されたメモリバケットを指す。

この権限モデルは有用なベースラインとなる。ただし本番システムでは、エージェントごとに責務やデータ境界が異なる場合、役割を分ける必要がある。

統合エージェントには読み取りアクセスだけで十分かもしれない。リサーチエージェントはレコードを追加できても、一括削除の権限は持たないようにできる。管理用メンテナンスサービスは、別のロールで有効期限処理や削除を担うことができる。

AWSのドキュメントによれば、ベクトルバケットでは常にBlock Public Accessが適用される。S3 Vectors overview は、バケットおよびインデックス向けのIAMと組織レベルの制御もサポートしている。

これらの制御によってインフラリソースを分離できる。ただし、ベクトルメタデータに埋め込まれたすべてのアプリケーションレベルのルールを自動的に強制するものではない。

複数のテナントが1つのインデックスを共有している場合、user_id または team_id のフィルタが欠けると、要求元のワークフローに無関係なメモリが露出する可能性がある。類似度検索はビジネス上の境界を理解せず、数学的に近い結果を返す。

インデックスを分ければ、より強固な分離を実現できる。AWSは、クエリがテナント単位に留まるマルチテナントワークロードにこのパターンを推奨している。

この選択には独自の管理上のトレードオフもある。インデックスを増やせば分離が向上し、クエリ負荷を分散できる可能性がある一方で、プロビジョニング、ポリシー、移行、監視の作業も増える。

チームはスループットの上限も検討すべきだ。AWSは、各インデックスで書き込みと削除を合わせて毎秒最大1,000リクエストを文書化している。

このサービスでは、インデックスごとに毎秒最大2,500ベクトルの挿入または削除も可能だ。アプリケーションは1回の書き込みリクエストで最大500ベクトルをバッチ処理できる。

読み取りについて、AWSはインデックスが毎秒数百件のクエリ、取得、リストリクエストをサポートできるとしている。サービスレートを超えると、TooManyRequestsException が返る可能性がある。

S3 vector guidance は、書き込みのバッチ化、リトライの実装、適切なワークロードの複数インデックスへの分散を推奨している。

こうした境界が小規模なリサーチチームを制約する可能性は低い。しかし、大規模な顧客基盤全体で、エージェントプラットフォームが各インタラクションごとに複数のメモリを記録する場合には重要になる。

Kubernetes Podのオートスケーリングでは、ストレージ側のリクエスト制限を取り除けない。レプリカを追加すると同時クエリが増え、スロットリングがより早く表面化することもある。

そのため、可観測性は両方のレイヤーを接続しなければならない。チームには、レイテンシー、トークン、エージェント軌跡に関するNATメトリクスに加え、EKSの健全性とS3 Vectorsのスロットリングまたはエラーデータが必要だ。

AWSがこの設計でEKSを使う理由は運用制御にある。そしてそれは、複雑性が増す要因でもある。

このルートを選ぶチームは、コンテナビルド、クラスターアップグレード、ネットワークポリシー、オートスケーリングの挙動、サービスアイデンティティを担う。サーバーレスのエージェントプラットフォームやホスト型メモリプロバイダーなら、その作業の一部を取り除ける。

比較すべき対象は、単にマネージドストレージと専用データベースではない。Kubernetes運用、埋め込み呼び出し、メモリポリシー、評価、インシデント対応を含めたシステム全体だ。

NVIDIA NeMo Agent Toolkitのメモリ設計で未証明なのは検索品質

AWSが示しているのは方向性に関する期待であり、このメモリ層がエージェントの回答を改善することを示すベンチマーク結果ではない。

この記事は、同一データセットを使ったNATの評価実行を2つ提案している。一方ではメモリを有効にし、もう一方ではメモリなしのベースラインを提供する。

NATは、精度、根拠性、トークン使用量、レイテンシーを測定できる。根拠性は回答が提供されたコンテキストに従っているかを評価し、軌跡評価はエージェント行動の連続を調べる。

AWSは、ワークフローが過去のコンテキストを再利用する場合、呼び出されたメモリが根拠性を高め、重複作業を減らし、トークン使用量を抑えると見込んでいる。また、各メモリクエリには一定のレイテンシーが加わるともしている。

同社はこれらの結果を、ベンチマーク済みではなく方向性を示すものだと明示している。その規模は、ワークロード、検索予算、反復の度合い、エージェント間の連携によって決まる。

この留保は、NVIDIA NeMo Agent Toolkitのメモリを評価するうえで中心的だ。発表内で公開された結果には、普遍的な精度向上やトークン削減を示すものはない。

取得されたレコードに検証済みで関連性の高い証拠が含まれていれば、メモリはエージェントを改善できる。一方で、ストアに誤った結論や古い解釈が含まれている場合、エラーを増幅することもある。

マルチエージェントのワークフローでは、あるエージェントの出力が別のエージェントの入力になり得るため、リスクは高まる。弱い主張でも、複数のシステムが取得して言い換えるうちに、誤った信頼性を帯びる可能性がある。

投資リサーチでは、この危険性を容易に理解できる。決算数値は改定されることがあり、ガイダンスは変化し、市場データは急速に古くなる。

したがって、メモリアイテムにはティッカーとテキスト以上の情報を含めるべきだ。有用なメタデータには、ソースの識別情報、公開時刻、観測時刻、検証ステータス、有効期限ルールが含まれる。

検索では、一次証拠とエージェント生成の解釈も区別すべきだ。引用された提出書類と、その書類に対するモデルの要約は、同じ権威性を持つべきではない。

削除も未解決の課題である。NATのプロバイダーはレコード削除をサポートし、S3 Vectorsも削除操作を公開している。それでもアプリケーション側は、どの識別子を削除すべきか、ユーザーレベルの削除要求をどう満たすかを判断しなければならない。

同じ情報が統合メモリに現れる場合、この問題はさらに難しくなる。後続のエージェントが複数のレコードを別のベクトルキーを持つ新しい要約に統合する可能性がある。

セキュリティテストはインフラアクセスだけを対象にしてはならない。攻撃者は後続エージェントを操作するよう設計されたテキストを埋め込み、永続的なプロンプトインジェクションを生み出す可能性がある。

メタデータフィルタはユーザー間の露出を減らすが、保存コンテンツの安全性を判断するものではない。システムには保存前の検証と、取得テキストがモデルプロンプトに入る方法に対する制御が必要だ。

ランキングという問題もある。基本的なベクトル類似度は意味的に近いレコードを特定するが、近さは真実性、鮮度、権威性と同義ではない。

本番の検索パイプラインでは、時間、ソース品質、タスク関連性、追加モデルを使って候補を再ランキングできる。サンプルプロバイダーは、この仕組みを意図的にシンプルに保っている。

このシンプルさによりコードは理解しやすくなる。ただし読者は、これを完成したメモリガバナンスシステムではなく基盤として扱うべきだ。

評価には、平均的なタスクスコアだけでなく敵対的なケースも必要となる。チームは、矛盾するメモリ、削除済みユーザー、古いデータ、不正なメタデータ、スロットリングされたクエリ、利用できない埋め込みエンドポイントをテストすべきだ。

また、S3プロバイダーをNATの既存メモリバックエンドと比較すべきである。メモリなしのベースラインは永続化が有益かを示すが、S3 Vectorsが最適な永続化手段かどうかは示さない。

最も有用な実験では、複数のプロバイダー間でプロンプト、モデル、データセットを一定に保つ。そのうえで、検索再現率、回答品質、レイテンシー分布、トークン消費、運用障害率を報告する。

その証拠が得られるまで、AWSが示したのは優位性ではなく実現可能性だ。この統合は、NATがプロバイダー契約を通じてS3 Vectorsを利用できることを証明している。

すべてのエージェントワークロードが永続メモリの恩恵を受けることも、すべてのアクセスパターンでオブジェクトベースのベクトルストレージが専門的なサービングシステムを上回ることも、これによって証明されたわけではない。

S3ベースのエージェントメモリが持続するかを示す3つのシグナル

次の試金石は、開発者が動作するリファレンスアーキテクチャを、測定可能でガバナンス可能な本番メモリへと変えられるかどうかだ。

第一に、メモリ品質の再現可能な評価に注目すべきだ。チームは同一のタスク、モデル、プロンプトを使用し、メモリを有効にした実行とメモリなしの実行を比較した結果を公開すべきである。

これらの結果には平均精度以上の情報が必要だ。検索精度、古いメモリによる失敗、p95レイテンシー、トークンの変化、エージェント作業の重複率を含めるべきである。

一貫した改善の証拠が得られれば、永続的な共有メモリがマルチエージェント連携を改善するというAWSの主張は強まる。結果が混在すれば、ストレージバックエンドよりもメモリ選択のほうが重要であることを示すだろう。

第二に、NVIDIAとAWSがプロバイダー体験をどう発展させるかを注視したい。現行パターンでは、カスタムプラグインコード、Bedrockの埋め込み呼び出し、メタデータ設計、YAML設定、コンテナパッケージング、IAM、EKSデプロイが必要となる。

公式に保守される統合、再利用可能なパッケージ、テスト済みのデプロイメントテンプレートがあれば、導入時の摩擦は減る。チームが埋め込みモデルやインデックススキーマを変更する際には、より良い移行サポートも役立つ。

現在のインデックス設定では、次元数と距離メトリックが作成時に固定される。本番ユーザーには、文書化されたバージョニング、デュアルライト、バックフィル、切り替えのパターンが必要だ。

第三に、本番チームがメモリをどう分割し、ガバナンスするかを注視すべきだ。決定的なシグナルは、メタデータフィルタを備えた共有インデックスを選ぶのか、より強固なテナント分離のために個別インデックスを選ぶのかである。

実際のデプロイメントは、保持、削除、来歴、汚染されたメモリの検出に関する実用的な戦略を明らかにするはずだ。また、同時エージェントトラフィック下でもS3 Vectorsが許容可能なレイテンシーに収まるかどうかも示すだろう。

AWSのリファレンスは、永続的なエージェントメモリをマネージドベクターストレージへ移すことに説得力のある根拠を示している。開発者にとって具体的なプラグイン境界、デプロイモデル、評価の出発点を提供するものだ。

より大きな示唆は、メモリがエージェントフレームワークそのものから切り離されつつあることにある。オーケストレーションはNVIDIA NeMo Agent Toolkitに残しながら、状態は独立してガバナンスできるサービスに置ける。

この分離により、システムのスケールや置き換えが容易になる可能性がある。一方で、意味的に類似したレコードを取得することが、正しく記憶することと同じだとチームが想定した場合、隠れた依存関係を生むおそれもある。

NVIDIA NeMo Agent Toolkitのメモリ機能を評価する開発者は、まず範囲を限定したワークフローとラベル付きテストセットから始めるべきだ。メモリなしの場合、および少なくとも1つの代替プロバイダーと比較する。

その後、アクセスを拡大する前に、分離、削除、古いレコード、敵対的コンテンツをテストする。これらの検証に成功すれば、S3 Vectorsは単なる低コストな永続化を超える。セッションやレプリカをまたいで稼働するエージェントのための、信頼できる共有メモリレイヤーとなる。