ジェフリーズ、AI で取引業務を最適化
Jefferies は AWS と Strands Agents を活用し、コーディング不要でリアルタイム分析を可能にする AI 取引アシスタントを導入し、前室の意思決定プロセスを劇的に最適化した。
キーポイント
エージェント型 AI の実装と課題解決
Jefferies は従来の IT チームへの依存やコーディング要件を排除するため、Strands Agents SDK を活用したドメイン特化型のエージェントを構築し、トレーダーが自然言語でリアルタイムデータ分析を行える環境を実現した。
AWS ベースの技術スタック
大規模言語モデル(LLM)と Amazon Bedrock、Bedrock Knowledge Bases を基盤とし、Model Context Protocol (MCP) 標準を用いて多様なデータソースやツールを安全かつ統一的に接続するアーキテクチャを採用した。
意思決定のスピード向上とギャップ解消
数百万行に及ぶデータを跨ぐ可視化の難易度を下げ、データ利用と意思決定の間のタイムラグを短縮することで、市場動向や顧客行動への即応性を飛躍的に高めた。
重要な引用
traders need real-time insights into client behavior, trade patterns, and market trends from vast amounts of data to make split-second decisions
The process can take days or weeks. The result is a widening gap between the data available and the decisions it should be informing.
put the power of real-time data analysis directly in traders’ hands without the requirement of coding, waiting in IT queues
影響分析・編集コメントを表示
影響分析
この事例は、AI エージェント技術が単なる実験段階から、金融業界のような厳格な規制と高速性が求められる現場で本格的に運用される転換点を示しています。特に MCP のような標準プロトコルを活用することで、複雑なデータ統合の障壁を下げた点は、他社への模倣可能性が高く、業界全体の AI 導入スピードを加速させる契機となるでしょう。
編集コメント
Jefferies の事例は、AI エージェントが「コードを書く」ことから「自然言語で指示を出す」へとユーザー体験をシフトさせる決定的な証拠となっています。MCP の採用により、異種システム間の接続コストが下がり、実装のハードルが劇的に低下した点が高く評価されます。
投資銀行のフロントオフィス取引部門を管理する方ならご存知の通り、最大の課題は「いかにして膨大なデータからリアルタイムで顧客行動や取引パターン、市場トレンドを把握し、一瞬のうちに判断を下すか」です。しかし、現場のトレーダーが一日中そのためのシステム構築に時間を割けるわけもなく、ましてやコーディングスキルを持つ人も限られています。また、数百万行ものデータが複数の可視化ツールに散在しているため、全体像を把握するのも容易ではありません。
従来の手法では、分析には専門家に頼り、カスタムダッシュボードの作成には IT チームとの連携が必要でした。このプロセスには数日乃至数週間を要し、利用可能なデータと意思決定の間に大きな隔たりが生じていました。
グローバルなフルサービス投資銀行であるジェファリーズ(Jefferies)は、この課題を「エージェント型 AI」を活用して株式取引部門の運用を最適化する機会と捉えました。AWS 上で構築したエージェント型 AI トレーディングアシスタントにより、コーディングや IT チームへの待機を不要とし、精度を損なうことなく、リアルタイムデータ分析の力を直接トレーダーの手元に届けることを実現しました。
本稿では、Jefferies がこれらの課題をどのように克服したかについて解説します。その解決策は、Strands Agents を基盤としたものです。これは AI エージェントを構築するための SDK で、基盤モデル(FMs)や外部ツールへの呼び出しを調整することで、推論・計画・実行を実現するエージェントを可能にします。
このソリューションでは、大規模言語モデル (LLM) や Amazon Bedrock、さらに Amazon Bedrock Knowledge Bases を活用しています。また、AI エージェントが統一されたインターフェースを通じて多様なデータソースやツールに安全に接続できるよう支援するオープン標準である Model Context Protocol (MCP) も採用されています。
ここでは、ソリューションの概要、基盤技術スタックを選定した理由、得られた教訓、そして Jefferies にもたらされたビジネスへの影響について取り上げます。
フロントオフィス・トレードアシスタントは、資本市場の株式トレーダーがデータとどう向き合うかというあり方そのものを変革するものです。このソリューションの中核をなすのは、自然言語によるテキスト対話を通じてトレーダーと対話を推進するドメイン特化型のエージェントです。MCP ツール群によって、このエージェントは取引データリポジトリや金融情報交換(FIX)メッセージファイル、インメモリデータベースといったデータソースへと接続されます。
トレーダーがトレードアシスタントに問い合わせると、Amazon Bedrock が LLM(Anthropic Claude)を起動し、自然言語による意図を解釈。対応する SQL を生成して基盤となるデータソースで実行し、回答を引き出します。対話型インターフェースを採用しているため、トレーダーはトピックを掘り下げていきながら、会話を通じてデータの洞察を探求できます。セッション全体を通じて文脈を維持することで、より深い分析に向けた関連性の高い洞察や提案を提供し続けます。
ソリューションの仕組み
本ソリューションは、以下のアーキテクチャ図に示す 8 つのステップを通じて、ジェフリーズの既存取引インフラと統合されます。セキュリティ面では、Amazon Bedrock Guardrails を活用し、コンテンツのモデレーションや個人識別情報(PII)のフィルタリングを実施して社内ポリシーに準拠させます。さらに、行レベルでのデータ権限管理により、インテリジェントなアクセス制御を通じて顧客機密データへの誤ったアクセスを防ぎます。また、監査証跡として会話ログを保持し、コンプライアンス要件にも対応しています。
ユーザーとの対話は、組み込み AI アシスタント・ウィジェットを搭載したジェフリーズのフロントエンド取引インターフェースから始まります。トレーダーが質問を発すると、そのリクエストは綿密に設計されたワークフローを経て処理されます。

- UI ウィジェット:まず、トレーダーはジェファーリーズのオンプレミス型ビジネスインテリジェンスシステム「Global Flow Monitor (GFM)」にログインします。GFM へのログインが完了すると、Trade Assistant Agent と対話するための UI ウィジェットが表示されます。
- 認証サービスは Amazon Elastic Kubernetes Service (Amazon EKS) を利用しています。このサービスにより、許可されたトレーダーのみが機密性の高い取引データにアクセスできることを保証します。
- Bot Service はユーザーセッションの構築と管理を担当し、複数の問い合わせにわたって文脈を維持します。
- クエリエージェント (Strands) は、本ソリューションにおけるインテリジェントなオーケストレーション層として機能します。トレーダーが自然言語で質問すると、まず Amazon Bedrock Knowledge Bases が検索対象となり、Amazon Titan Embeddings を用いた意味論的検索によって、関連するデータベーススキーマ、テーブル間の関係性、およびクエリパターンを特定します。この文脈を基に Claude Sonnet がトレーダーの意図を推論し、構文が正しい SQL クエリを生成します。その後、エージェントは利用可能な Model Context Protocol (MCP) ツールを評価し、リアルタイムのポジション情報を扱うインメモリグリッドか、時系列分析のための履歴データストアか、実行に最適なデータソースを選択します。
- Amazon Bedrock は、クエリエージェントに対して LLM へのアクセスを提供し、プランニングとステップの実行を可能にします。LLM の高度な推論機能により、自然言語の理解、SQL の生成、そして多段階のツールオーケストレーションが実現されています。チームはまた、Trade Assistant が進化していく中で異なる LLM を選択できる柔軟性も Amazon Bedrock 選定の理由の一つとしています。
- Amazon Bedrock Knowledge Bases は、管理された Retrieval Augmented Generation (RAG) パイプラインを提供します。ここでは、基盤となるデータモデルのメタデータ(テーブルスキーマ、カラム定義、クエリパターン)の埋め込み表現が保存されます。クエリエージェントがトレーダーからの質問を受け取ると、Knowledge Base から関連するスキーマ文脈を取得し、正確な SQL 構築を支援します。
- クエリエグゼキューターは、クエリエージェントによって適切なデータソースが特定され、SQL クエリが作成された後に、基盤となるデータを照会します。クエリエグゼキューターはユーザーのリクエストをインターセプトし、SQL フィルタを注入することで、データアクセスにおける行レベルのセキュリティを提供します。表示するビジュアライゼーションは LLM が選択し、Markdown UI ライブラリを使用してレンダリングしています。
- データストア:クエリエグゼキューターが実際に照会するデータソース群です。インメモリ、SQL データベース、および取引や執行の基盤データを格納した FIX メッセージなどが含まれます。
では、Strands Agents と MCP ツールベースアーキテクチャを採用した背景にある理由について探っていきましょう。
Strands Agents
Strands Agents は、数行のコードで AI エージェントを構築・実行するためのオープンソース SDK です。このフレームワークはモデル駆動型のアプローチを採用しており、シンプルなユースケースから複雑なケースまで、ローカル開発から本番環境へのデプロイまで幅広く対応しています。
Strands は、LLM(大規模言語モデル)が持つ「計画立案」「思考の連鎖」「ツールの呼び出し」「自己省察」といった能力を活用することで、エージェント開発を大幅に簡素化します。開発者はコード上でプロンプトと使用するツールのリストを定義するだけでエージェントを作成でき、ローカルでテストした後にクラウドへデプロイできます。Strands はモデルの高度な推論機能を利用して、エージェントが次に取るべきステップを計画し、必要なツールを実行します。
より複雑なユースケースでは、開発者は Strands を使ってエージェントの動作をカスタマイズすることも可能です。例えば、ツールの選択ロジックを指定したり、コンテキスト管理の方法を調整したり、セッションの状態やメモリをどこに保存するかを選んだりできます。また、複数のエージェントが連携するマルチエージェントアプリケーションも構築できます。
Model Context Protocol (MCP) ツール
本ソリューションは、各データソースを個別のツールとして公開し、Strands エージェントが呼び出せるようにする「Model-Context-Protocol(MCP)」ベースのアーキテクチャを採用しています。この設計には、システムの長期的な成功を支える3 つの大きなメリットがあります。
第一に、拡張性です。新しいデータソースを追加する際も、コアとなるアーキテクチャを再構築する必要はなく、単に追加ツールとして登録するだけで済みます。これは将来の機能拡大を見据えてチームが意図的に選んだ設計判断です。
第二に、関心の分離(セパレーション・オブ・コンサーン)の実現です。各システムとの連携ロジックを個別のツール内にカプセル化することで、全体としてのアーキテクチャは保守性とテスト容易性が向上します。
第三に、柔軟性です。Strands エージェントはクエリの内容に応じて使用するツールを動的に選択できるため、複数のデータソースにまたがるワークフローもスムーズに実現できます。
複数ソースからのデータ処理

本ソリューションは、直感的で使いやすいユーザー体験を提供します。トレーダーは画面に表示されたような質問を入力するだけで済みます。「米国での取引におけるセクター別の内訳を教えて」といった問いに対し、裏側では AI モデル(LLM)が適切な SQL クエリを自動生成。そのクエリを実行して、インメモリデータグリッド上にホストされている関連データソースから即座に結果を取得し、表示します。
トレードアシスタントは単なるデータ検索の枠を超えています。テキストによる問い合わせを SQL に変換し、チャートやグラフで構成される動的なビジュアルストーリーを生成できるのです。
例えば、今日のセクター別取引と昨日の状況を比較する必要がある場合、アシスタントは自動的に色分けされた凡例付きの円グラフを作成します。これにより、トレンドや異常値を素早く見極めることが可能になります。
教訓
フロントオフィス向けトレードアシスタントエージェントの実現に向けた道のりを通じて、ジェファーリーズ(Jefferies)チームは、エンタープライズ AI の戦略と実装ロードマップに大きな影響を与えるいくつかの重要な教訓を発見しました。これらの知見は、大規模なアジェンシー AI アプリケーションを構築する金融市場組織にとって貴重な指針となります。
第一に、チームはハルシネーション(幻覚現象)のリスクを回避するため、LLM に視覚化の生成を任せることを意図的に避けました。代わりに、自然言語の理解とクエリ生成を LLM が担当し、実際のチャートやグラフの描画は専用の可視化エンジンが担うハイブリッドなアプローチを採用しました。
この関心の分離により、トレーダーが求める対話型インターフェースを維持しつつ、データの正確性を保つことに成功しています。
第二に、チームは応答速度を最大化するため、インメモリデータベースを活用しました。トレーダーは、顧客の行動や取引パターン、市場動向について瞬時の洞察を必要とします。もしこのアーキテクチャ上の選択を行っていなければ、基盤となるデータセットへのクエリがリアルタイムの取引判断にとって許容できない遅延を引き起こしていたでしょう。
3 つ目に、チームはユーザーの行動が変化するものだと予測するようになりました。実際の運用では、その動きは動的であることが証明されました。トレーダーたちは予期せぬ方法でシステムと対話し、そのパターンも時間とともに変化しました。こうした変化する行動にすばやく適応するためには、観測性の強化とユーザーフィードバックループへの投資が不可欠でした。
最後に、チームは意図的な言語戦略を採用しました。豊富な人工知能(AI)および機械学習(ML)エコシステムを背景に、LLM との対話や迅速な実験には Python を活用しています。一方、複雑なビジネス処理については、高性能データ処理と既存の取引システムとの統合に適したパフォーマンス特性を活かすため、Java を採用しました。
ビジネスへの影響
導入以来、トレード・アシスタント・ソリューションはグローバルな営業・取引部門全体で明確な効率化をもたらしました。これによりトレーダーは手作業でのデータ処理に費やす時間を減らし、顧客との関係構築や戦略的な意思決定に集中できるようになっています。この効率化は競争優位性へと直結しており、取引デスクではより多くのリソースを新規顧客のオンボーディングや既存顧客との関係深化に充てることが可能になりました。
本ソリューションは、MCP ツールを活用して構造化データ、非構造化データ、インメモリデータを柔軟にアクセスし、クライアントの問い合わせに応じて動的にグラフやチャートを生成することで、一人ひとりの顧客に合わせた体験を提供します。取引デスクの外でも、これまで反復的なダッシュボード作成に費やされていた IT 部門のリソースと時間を大幅に削減し、技術チームがより付加価値の高い戦略的プロジェクトに注力できる環境を整えました。
特筆すべきは、自然言語による問い合わせで数百万行に及ぶ株式取引データを安全に照会できるようになった点です。これによりデータへのアクセスが民主化され、直感や遅れた報告書ではなく、リアルタイムの分析に基づいて意思決定を行うデータドリブンな文化が醸成されています。
今後の展望
ジェフリーズのロードマップは、このエージェント型 AI アプローチのスケーラビリティと野心的な計画を示しています。チームは今後、Trade Assistant を複数の商品タイプや取引部門向けにグローバル展開する予定で、自然言語処理(NLP)を活用したコード生成ツールにより監査機能を強化します。また、企業向け AI システムには Amazon Bedrock AgentCore の機能も追加される見込みです。これらの投資は、組織全体に AI 活用能力を広げるという決意の表れです。
既存の株式事業用ビジネスインテリジェンス(BI)アプリケーションとの統合や、構造化データ、非構造化データ、メモリ内データを横断してクエリを実行できる機能により、ジェフリーズは AI を駆使した取引革新の最前線に立っています。
結論
本稿では、ジェフリーズと AWS の連携により構築された「エージェント型 AI 取引アシスタント」が、グローバルな販売・取引業務における株式データの扱い方をどう変革したかを紹介しました。この「ジェフリーズ株式取引アシスタント」は、エージェント型 AI が資本市場をどのように再定義しているかを象徴しています。単なる会話を通じて高度な洞察を引き出すデータサイエンティストへとトレーダーを変容させ、競争優位性を生み出しています。
これらのエージェント型 AI システムは、文脈を理解し、対話から学習し、ユーザーがより良い結果を得られるよう先回りして導く、知能の高いパートナーとして機能します。受動的なデータ検索から能動的なインテリジェンスへの転換は、取引業務における新たな時代の幕開けを告げるものです。この技術がグローバルに拡大し、資産クラスも横断して応用されるにつれ、フロントオフィスの競争優位性を今後長年にわたり再定義していくことが期待されています。
ご自身でエージェント型 AI アプリケーションの構築を始めたい場合は、「Strands Agents」の探索や、本ソリューションで採用された MCP 統合パターンに関する詳細情報の確認、あるいは AWS アカウントチームへお問い合わせいただき、ユースケースに合わせたエンゲージメントについてご相談ください。
著者紹介

サンジャイ・ナグラジ氏
サンジャイ氏は、株式フロントオフィスにおけるソリューション提供を率いる技術リーダーです。主な取り組みとして、クラウド上で利用可能なサービスを活用し、ハイブリッド型ソリューションを実現することが挙げられます。

Vipul Parekh氏
Vipul氏はAWSのシニアカスタマーソリューションマネージャーとして、FinTechおよび資本市場の顧客がクラウド上でビジネス変革を加速させるための支援を行っています。生成AIのアムバサダーであり、AWS AI/ML技術コミュニティの一員でもあります。AWS入社前は主要な金融サービス機関で多様な役割を果たし、変革プロジェクトを率いてきました。

Saby Sahoo氏
Saby氏はAWSのシニアソリューションアーキテクトです。ITソリューション、データ分析、AI/ML/生成AIの設計と実装において、20年以上の実績を有しています。
原文を表示
If you manage a front office trading desk at investment banks, you know the challenge: traders need real-time insights into client behavior, trade patterns, and market trends from vast amounts of data to make split-second decisions. However, they rarely have the time during the day, nor the coding ability, to build and maintain systems capable of delivering those insights. With millions of rows of data spread across multiple visualization tools, achieving end-to-end visibility is difficult. Traditional approaches force traders to rely on subject matter experts for analysis and collaborate with IT teams to build custom dashboards. The process can take days or weeks. The result is a widening gap between the data available and the decisions it should be informing.
Jefferies, a global full-service investment banking firm, recognized this challenge as an opportunity to apply agentic AI to optimize how its equities trading desks operate. By building an agentic AI trade assistant on AWS, Jefferies set out to put the power of real-time data analysis directly in traders’ hands without the requirement of coding, waiting in IT queues, and with no compromise on accuracy.
In this post, we explore how Jefferies overcame these challenges with a solution built on Strands Agents, an agent harness SDK for building AI agents that can reason, plan, and act by orchestrating calls to foundation models (FMs) and external tools. The solution uses large language models (LLMs), Amazon Bedrock, and Amazon Bedrock Knowledge Bases. It also uses Model Context Protocol (MCP), an open standard that helps AI agents securely connect to diverse data sources and tools through a unified interface. We cover the solution overview, the rationale for selecting the underlying technology stack, lessons learned, and the business impact the solution created at Jefferies.
Solution overview

The Front Office trade assistant represents a shift in how Capital Markets’ Front Office Equity traders interact with data. At the core of the solution is a domain-specific agent that drives conversation with traders through natural language text. A set of MCP tools lets the agent connect with data sources, including trade data repositories, Financial Information Exchange (FIX) message files, and in-memory databases. When a trader submits a query to the trade assistant, Amazon Bedrock invokes an LLM (Anthropic Claude) to interpret the natural language intent, generate the corresponding SQL, and run it against underlying data sources to surface the response. The solution has a conversational interface, which allows traders to drill down on topics and explore data insights conversationally. The solution maintains conversation context to provide relevant insights and suggestions for deeper analysis over the entire lifetime of the session.
How the solution works
The solution integrates with Jefferies’ existing trading infrastructure through an eight-step process depicted in the following architecture diagram. From a security perspective, the solution uses Amazon Bedrock Guardrails to provide content moderation, personally identifiable information (PII) filtering to align the solution with Jefferies policies, and row-level data entitlements to help prevent accidental access to customer-sensitive data through intelligent access controls. It also uses conversation logging for audit trails to meet compliance requirements.
The user interaction begins with the Jefferies front-end trading interface, which now includes an embedded AI assistant widget. When a trader poses a question, the request flows through a carefully orchestrated workflow.

- UI Widget: First, the trader logs in using their credentials on Jefferies’ on-premises Business Intelligence system: Global Flow Monitor (GFM). Once a trader logs into GFM, they have a UI widget to interact with the Trade Assistant Agent.
- The Authentication Service uses Amazon Elastic Kubernetes Service (Amazon EKS). The service verifies that only allowed traders can access sensitive trading data.
- Bot Service builds and manages the user session, maintaining context across multiple queries.
- The Query Agent (Strands) serves as the intelligent orchestration layer of the solution. When a trader poses a natural language question, the agent first queries the Amazon Bedrock Knowledge Bases, which uses Amazon Titan Embeddings for semantic retrieval to surface relevant database schemas, table relationships, and query patterns. With this context, Claude Sonnet reasons over the trader’s intent and generates a syntactically correct SQL query. The agent then evaluates its available Model Context Protocol (MCP) tools to determine the right data source for execution, whether that’s the in-memory grid for real-time positions or a historical data store for time-series analysis.
- Amazon Bedrock provides the Query Agent with access to an LLM for planning and executing the agent’s steps. The LLM’s advanced reasoning capabilities enable natural language understanding, SQL generation, and multi-step tool orchestration. The team also chose Amazon Bedrock for its flexibility to choose different LLMs as the trade assistant evolves.
- Amazon Bedrock Knowledge Bases provides a managed Retrieval Augmented Generation (RAG) pipeline that stores embedded representations of the underlying data model metadata (table schemas, column definitions, and query patterns). When the Query Agent receives a trader’s question, it retrieves relevant schema context from the Knowledge Base to inform accurate SQL construction.
- Query Executor queries the underlying data once the Query Agent identifies the right data source and creates the SQL query. The query executor intercepts user requests and injects SQL filters to provide row-level security for data access. The LLM chooses the visualization to display, and we used a markdown UI library to render the visualizations.
- Data Stores: The actual data sources queried by the Query Executor, including in-memory, SQL databases, and FIX messages that contain the underlying trade and execution data.
Let’s explore the rationale behind our selection of Strands Agents and MCP tools-based architecture.
Strands Agents
Strands Agents is an open source agent harness SDK that takes a model-driven approach to building and running AI agents in a few lines of code. Strands scales from straightforward to complex agent use cases, and from local development to deployment in production. It simplifies agent development by embracing the capabilities of LLMs to plan, chain thoughts, call tools, and reflect. With Strands, developers can define a prompt and a list of tools in code to build an agent, then test it locally and deploy it to the cloud. Strands plans the agent’s next steps and executes tools using the advanced reasoning capabilities of models. For more complex agent use cases, developers can customize their agent’s behavior in Strands. For example, you can specify how tools are selected, customize how context is managed, choose where session state and memory are stored, and build multi-agent applications.
Model Context Protocol (MCP) tools
The solution implements a Model-Context-Protocol (MCP) tool-based architecture where each data source is exposed as a distinct tool that Strands Agents can invoke. This approach delivers three advantages that position the system for long-term success. First, the approach provides extensibility by enabling new data sources to be added as additional tools, requiring no restructuring of the core architecture, a design choice the team made deliberately to accommodate future functional expansion. Second, it provides separation of concerns by encapsulating the logic for interacting with each specific system within its own tool, which makes the overall architecture more maintainable and testable. Third, the design offers flexibility by allowing the Strands Agent to dynamically select which tools to use based on each query, enabling workflows that span multiple data sources.
Multi-source data processing

The solution provides an intuitive user experience. A trader can type a question like the one on the screen: “Give me the sector breakdown for trading in the U.S.” Behind the scenes, the assistant uses an LLM to generate the appropriate SQL query, runs it against the relevant data sources hosted in our in-memory data grid, and retrieves the results instantly.
The trade assistant goes beyond simple data retrieval. It can generate dynamic visualizations, converting text queries into SQL that produces visual stories with charts and graphs. When traders need to compare today’s sector trading with yesterday’s activity, the assistant automatically generates pie charts with color-coded legends, making it straightforward to spot trends and anomalies quickly.
Lessons learned
Throughout the journey to deliver the Front Office trade assistant agent, the Jefferies team uncovered several key lessons that shaped its enterprise AI strategy and implementation roadmap. These insights serve as valuable guidance for capital markets organizations building agentic AI applications at scale.
First, the team mitigated the risk of hallucinations by deliberately not relying on LLMs to generate visualizations. Instead, they implemented a hybrid approach in which the LLM handles natural language understanding and query generation while dedicated visualization engines render the actual charts and graphs. This separation of concerns preserves data accuracy while maintaining the conversational interface traders expect.
Second, the team used in-memory databases to maximize response times. Traders require split-second insights into client behavior, trade patterns, and market trends. Without this architectural choice, queries against the underlying dataset would have introduced unacceptable latency for real-time trading decisions.
Third, the team learned to expect user behavior to evolve. Real-world usage proved dynamic. Traders interacted with the system in unexpected ways, and their patterns shifted over time. Investing in observability and user feedback loops proved essential for adapting quickly to these changing behaviors. Finally, the team adopted a deliberate language strategy. They relied on Python for LLM interactions and rapid experimentation, given its rich artificial intelligence and machine learning (AI/ML) landscape. They implemented complex business processing in Java to capitalize on its performance characteristics for high-throughput data processing and integration with existing trading systems.
Business impact
Since launch, the trade assistant solution has delivered measurable efficiency gains across global sales and trading operations, allowing traders to redirect time toward client relationships and strategic decision-making rather than manual data wrangling. These efficiency gains translate directly into a competitive advantage, as trading desks can now dedicate more capacity to onboarding clients and deepening existing relationships. The solution delivers a personalized experience by adapting to each client’s query using MCP tools to access structured, unstructured, and in-memory data sources and dynamically generating graphs and charts in response. Beyond the trading desk, the solution has materially reduced the IT time and effort previously consumed by repetitive dashboard creation, freeing technology teams to focus on higher-value strategic initiatives. Perhaps most notably, the ability to securely query millions of rows of equities trading data using natural language has democratized data access. This fosters a data-driven culture where decisions are informed by real-time analytics rather than intuition or delayed reports.
Looking ahead
Jefferies’ roadmap signals the scalability and ambition of this agentic AI approach. The team plans to roll out the Trade Assistant globally for multiple product types and desks, enhance audit capabilities with code generation tools that use natural language processing (NLP), and add Amazon Bedrock AgentCore features to their enterprise AI system. These investments show a commitment to expanding AI-powered capabilities across the organization. The integration with existing Equities business intelligence (BI) applications and the ability to query multiple structured, unstructured, and in-memory data sources positions Jefferies at the forefront of AI-driven trading innovation.
Conclusion
In this post, we walked through how Jefferies and AWS collaborated to build an agentic AI trade assistant that transforms how traders interact with equities data across global sales and trading operations. The Jefferies Equities Trade Assistant exemplifies how agentic AI is reshaping capital markets by turning every trader into a data scientist capable of extracting sophisticated insights through simple conversation. These agentic AI systems act as intelligent collaborators that understand context, learn from interactions, and proactively guide users toward better outcomes. The shift from reactive data retrieval to proactive intelligence marks a new era in trading operations. As this technology scales globally and across asset classes, it promises to redefine competitive advantage in front office operations for years to come.
To get started building your own agentic AI applications, explore Strands Agents, learn more about the MCP integration patterns used in this solution, or contact your AWS account team to discuss engagement tailored to your use case.
About the authors

Sanjay Nagraj
Sanjay is a technology leader leading the delivery of solutions in Equities Front Office. Key initiatives include leveraging the services available on the cloud to deliver hybrid solutions.

Vipul Parekh
Vipul is a Senior Customer Solutions Manager at AWS, guiding FinTech and capital markets customers in accelerating their business transformation journey on the cloud. He is a generative AI ambassador and a member of the AWS AI/ML technical field community. Prior to joining AWS, Vipul played various roles in top financial services organizations, leading transformations.

Saby Sahoo
Saby is a senior solutions architect at AWS. Saby has 20+ years of experience in the design and implementation of IT solutions, data analytics, and AI/ML/GenAI.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み