Supercharging eBay: Agentic AI with Context-Aware Routing & MCPs Transforming Support, Migrations

Supercharging eBay: Agentic AI with Context-Aware Routing & MCPs Transforming Support, Migrations — Ai4

Ai4

AI-assisted summary of Supercharging eBay: Agentic AI with Context-Aware Routing & MCPs Transforming Support, Migrations — original source. Check the original for full context.

Source published:

Detailed notes

## Background Published on YouTube by the Ai4 channel on August 27, 2025, this presentation features Ramesh Periyathambi, Distinguished Engineer at eBay Inc., exploring the company's internal Agentic AI platform. The session covers how eBay leverages context-aware routing, Model Context Protocol (MCP) integrations, and autonomous workflows to streamline tech support, accelerate legacy code migrations, and enhance enterprise operations.

## TL;DR eBay transitioned from basic knowledge-base chatbots to a sophisticated multi-agent platform aimed at eliminating developer friction and reducing ticket turnaround times from 24 hours to minutes. Powered by automated probing agents and a two-stage context-aware routing architecture, the system autonomously resolves over 21% of internal support inquiries while reclaiming thousands of developer focus hours. The agentic framework also drives large-scale code modernization—delivering a 3x productivity boost on framework migrations and contract-first OpenAPI generation—while expanding into finance, legal compliance, and secure MCP-based tool orchestration.

## Atmosphere & style The talk carries the crisp, authoritative tone of a pragmatic enterprise engineering keynote focused on real-world production impact rather than theoretical hype. Delivered with steady pacing and concrete telemetry, the presentation transitions smoothly from macro-level organizational economics to granular architectural schematics. The speaker's delivery is candid and reflective, seamlessly blending relatable developer anecdotes with a systematic breakdown of cutting-edge agent orchestration.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=4s) eBay transitioned from a basic internal RAG chatbot to an enterprise agentic AI platform offering both no-code authoring and custom Spring AI implementations across massive scale. - [03:06](https://www.youtube.com/watch?v=RFxfEV_siMM&t=186s) Internal studies identified that manual support tickets averaged a 24-hour turnaround, causing developers to waste 92 minutes of productive focus per question across repeated context switches. - [05:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=304s) Support requests are processed through stateful graph workflows incorporating modular classification, retrieval, domain execution, and automated self-critique nodes. - [06:34](https://www.youtube.com/watch?v=RFxfEV_siMM&t=394s) Context-aware routing leverages automated probing agents to enrich noisy metadata, paired with vector candidate retrieval and dynamic few-shot Chain-of-Thought LLM ranking. - [09:32](https://www.youtube.com/watch?v=RFxfEV_siMM&t=572s) eBay models support ROI on a baseline manual cost of 112 minutes per ticket, with over 21% of all enterprise support requests now resolved fully autonomously by AI. - [11:44](https://www.youtube.com/watch?v=RFxfEV_siMM&t=704s) Large-scale legacy code migrations achieved a 3x productivity boost and over 80% OpenAPI spec accuracy by using dynamic per-file prompt assembly instead of model fine-tuning. - [14:16](https://www.youtube.com/watch?v=RFxfEV_siMM&t=856s) Agentic workflows extend into business operations, including finance agents interfacing with ERP systems like SAP Ariba and legal agents automating PII redaction and eDiscovery. - [17:48](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1068s) Finance agents consolidate multi-layered dependencies across parent tickets, contracts, and sub-items to highlight actual workflow bottlenecks rather than returning basic status codes. - [19:05](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1145s) A pragmatic hybrid architecture pairs third-party Glean connectors for standardized enterprise apps with custom in-house agent frameworks for proprietary eBay data and APIs. - [20:21](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1221s) Probing agents systematically interview newly registered agents to infer functional capabilities, while explicit user feedback continuously refines routing precision. - [22:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1324s) Automated diagnostic agents integrate directly into CI/CD delivery pipelines, correlating multi-tier telemetry and logs to pinpoint root causes without manual developer log diving. - [23:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1384s) Enterprise Model Context Protocol (MCP) adoption is secured through a centralized MCP Gateway that standardizes authentication, token management, and policy enforcement across tools.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=4s) eBay's Massive Scale and the Evolution to Agentic AI

To understand the engineering challenges and opportunities at eBay, one must first appreciate the staggering scale at which the platform operates. eBay currently hosts over 2.3 billion live listings—a number so vast that it equates to roughly one item for every third person on Earth. The marketplace supports 134 million active buyers and sellers, generating $74.7 billion in total gross merchandise volume last year while drawing upon nearly three decades of accumulated e-commerce data and domain knowledge. Engaging the audience with a quick show of hands on who had recently bought or sold on eBay, the stage was set to explore how modern AI fits into such an expansive ecosystem.

The journey began with an initial deployment of a simple internal chatbot designed to give eBay employees fast, grounded, and reliable answers from company knowledge bases. Built with a modular architecture that cleanly decoupled data ingestion pipelines from retrieval and response generation, this early setup laid the technical foundation for future routing and orchestration layers. Over time, this single chatbot was re-architected into a full-fledged agentic AI platform offering two distinct onboarding paths for internal teams: a no-code configuration interface for rapid deployment, and a custom code solution built directly on top of eBay’s proprietary frameworks and Spring AI modules.

- **Scale Benchmarks**: 2.3 billion live listings, 134 million active users, and $74.7 billion in annual sales backed by 30 years of e-commerce data. - **Architectural Shift**: Transitioned from a modular RAG knowledge chatbot to a dual-track agentic platform supporting both no-code authoring and custom Spring AI-based implementations.

---

[03:06](https://www.youtube.com/watch?v=RFxfEV_siMM&t=186s) Tech Support Bottlenecks: Calculating the Cost of Developer Friction

Tech support was selected as the first and most critical proving ground for the agentic platform based on a simple operating philosophy: "Every developer who wastes a single minute equals wasted innovation." Before introducing AI agents, internal telemetry and surveys revealed significant friction across engineering teams. The baseline average turnaround time for resolving a developer support ticket sat at 24 hours. During that waiting window, an engineer checked for updates or alternative workarounds at least four separate times.

Coupled with industry research demonstrating that it takes an engineer approximately 23 minutes to recover focus after a context switch or disruption, the total hidden cost became clear. Four interruptions at 23 minutes each meant developers were losing an average of 92 minutes of productive focus time per support question. The agentic initiative's primary goal was to reclaim these lost 92-minute blocks and return that time directly to engineering teams.

- **Pre-AI Support Latency**: 24-hour average response time per support ticket. - **Context-Switching Impact**: 4 status checks per day $\times$ 23 minutes recovery time = 92 minutes of wasted developer focus per question. - **Mission**: Eliminate developer context switches by automating resolution paths across hundreds of specialized agents.

---

[05:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=304s) Inside the Support Graph Architecture and Response Execution

Today, eBay runs hundreds of specialized tech support agents, each fine-tuned to handle a narrow, well-defined slice of the software development lifecycle. When an incoming support inquiry arrives, it is directed to a specialized domain agent—such as a dedicated Framework Agent—which executes a stateful graph workflow. Within this graph, distinct nodes carry out modular tasks including intent classification, retrieval-augmented generation (RAG), or specialized domain logic tailored to specific operational domains like deployments and code migrations.

In practical execution, when a developer submits an issue to a deployment node within the Framework Agent, the system autonomously synthesizes a response, subjects the generated output to an automated self-critique step, and delivers a verified resolution within minutes instead of hours. The platform has seen adoption surge to thousands of active developers per month, drastically compressing end-to-end resolution cycles from a full day down to a matter of minutes.

```mermaid flowchart TD accTitle: Tech Support Graph Workflow accDescription: Flowchart illustrating how a developer support question is routed through specialized nodes in an agent workflow.

subgraph InputStage["Inbound Support Request"] A["Developer Query"] --> B["Context-Aware Router"] end

subgraph AgentExecution["Framework Agent (Graph Workflow)"] B --> C["Classification Node"] C --> D["RAG Retrieval Node"] D --> E["Domain Logic Node\n(Deployment / Migration)"] E --> F["Self-Critique & Validation"] end

subgraph OutputStage["Resolution Delivery"] F --> G["Verified Automated Response\n(Delivered in Minutes)"] end ```

- **Modular Graph Nodes**: Tasks are split into discrete graph steps covering classification, targeted knowledge retrieval, domain-specific execution, and self-critique. - **Turnaround Reduction**: Ticket wait times dropped from 24 hours down to sub-minute or multi-minute automated completions.

---

[06:34](https://www.youtube.com/watch?v=RFxfEV_siMM&t=394s) Context-Aware Routing: Solving the Dynamic Agent Discovery Problem

As platform adoption accelerated and hundreds of agents were created across different teams, directing incoming requests to the appropriate agent became a major bottleneck. The platform required an intelligent "traffic cop" capable of handling a dynamic, rapidly expanding agent pool filled with noisy, heterogeneous metadata. To solve this, eBay implemented a multi-tier context-aware routing framework that combines automated metadata enrichment with a two-stage selection pipeline.

```mermaid flowchart LR accTitle: Context-Aware Agent Routing Pipeline accDescription: Two-stage routing architecture showing metadata enhancement, embedding-based candidate generation, and LLM ranking.

subgraph Ingestion["1. Metadata Preparation"] A["New Agent Added"] --> B["Probing Agent\n(Enriches Noisy Metadata)"] end

subgraph Selection["2. Two-Stage Routing"] C["User Query"] --> D["Candidate Generation\n(Top-K Embedding Search)"] B -.-> D D --> E["LLM Router\n(Dynamic Few-Shot + CoT)"] end

subgraph Consensus["3. Final Selection"] E --> F["Self-Consistency\nEnsemble"] F --> G["Ranked & Scored\nTarget Agent"] end ```

The routing lifecycle begins with a specialized probing agent that cleans and augments the raw metadata of newly registered agents. When a developer submits a query, the system first executes candidate generation, using vector embeddings to retrieve the top-K candidate agents. Next, an LLM-based router performs in-context classification by pulling dynamic few-shot examples from a vector database, invoking an explicit Chain of Thought (CoT) prompt for detailed comparative analysis, and applying self-consistency ensembling to ensure robust scoring. Ablation studies demonstrated that omitting either the dynamic few-shot examples or self-consistency ensembling caused noticeable drops in routing accuracy compared to the baseline semantic router.

- **Probing Agent**: Enriches and cleans unstructured metadata as agents are dynamically registered into the pool. - **Two-Stage Routing**: Vector similarity reduces the search space to a top-K candidate list, followed by LLM-driven ranking. - **Prompt Strategies**: Employs dynamic few-shot retrieval from vector memory, explicit Chain of Thought reasoning, and self-consistency voting to outperform basic semantic embeddings.

---

[09:32](https://www.youtube.com/watch?v=RFxfEV_siMM&t=572s) Quantifying AI ROI: Resolution Metrics and Developer Time Saved

To objectively measure the developer hours saved by deploying AI in tech support, eBay established a structured mathematical model. Under the traditional manual baseline, each support ticket consumed 112 minutes of combined organizational effort: the 92 minutes of lost developer focus time plus an average of 20 minutes of dedicated support engineer effort (which varies across operational channels and categories). Total time saved is calculated by multiplying this 112-minute baseline by the absolute volume of tickets resolved automatically by AI.

$$\text{Total Manual Time per Ticket} = 92\text{ min (Developer Friction)} + 20\text{ min (Support Engineer Effort)} = 112\text{ min}$$

$$\text{Total Time Saved} = 112\text{ min} \times \text{Volume of AI-Resolved Tickets}$$

Resolution is evaluated through two distinct channels: explicit feedback, where the engineer manually confirms the answer resolved their issue, and implicit feedback, where an LLM judge evaluates the conversation against multiple quality criteria. For implicit evaluation, an interaction is classified as resolved if it achieves a composite score threshold of $\ge 7$. Currently, more than 21% of all tech support requests across eBay are resolved end-to-end by AI, returning thousands of engineering hours back to product development.

- **Baseline Total Cost**: 112 minutes of organizational effort per ticket (92 minutes developer downtime + 20 minutes support engineer handling). - **Dual Resolution Tracking**: Supports explicit user confirmation and implicit LLM-judged evaluation based on a composite score of $\ge 7$. - **Adoption Impact**: Over 21% of total enterprise tech support inquiries are completely resolved without human intervention.

---

[11:44](https://www.youtube.com/watch?v=RFxfEV_siMM&t=704s) Large-Scale Code Migrations: OpenAPI Specs and Framework Modernization

Beyond day-to-day support queries, eBay applied agentic workflows to large-scale legacy codebase modernization, focusing on two major technical challenges: contract-first API migrations and major framework upgrades (such as migrating legacy Spring applications to Spring Boot). For contract migrations, a supervisor agent coordinates a fleet of sub-agents that parse legacy source code, auto-generate OpenAPI specifications, and validate the resulting contracts against strict internal standards.

When tackling framework migrations, initial experiments with fine-tuned models were superseded by a more flexible, per-file specialized prompt assembly strategy. For each source file, the system dynamically constructs a runtime prompt incorporating file-specific templates and targeted few-shot examples before dispatching it to the LLM. Deployed across IDEs, command-line interfaces, and cloud environments via Model Context Protocol (MCP) integrations, this approach has served over 900 users, delivering a 3x productivity boost on framework upgrades and achieving over 80% correctness on automated OpenAPI specification generation.

- **Contract-First Automation**: Supervisor agent directs sub-agents to parse legacy repositories, generate OpenAPI specs, and enforce eBay schema standards. - **Prompt Strategy Finding**: Dynamic per-file prompt assembly paired with few-shot examples proved more effective and maintainable than model fine-tuning. - **Migration Performance**: 3x developer productivity acceleration across 900 engineers, with an OpenAPI spec accuracy rate exceeding 80%.

---

[14:16](https://www.youtube.com/watch?v=RFxfEV_siMM&t=856s) Expanding Beyond Tech: Finance, Legal Workflows, and MCP Architecture

The agentic platform has expanded beyond software engineering into business operations, notably finance and legal compliance. In finance, specialized agents handle workflows around corporate travel, purchase orders (POs), contracts, and payroll. The Travel and Purchase Order agent has become the second most utilized no-code agent across the enterprise, managing roughly 5,000 annual tickets by interfacing directly with live ERP systems like SAP Ariba, with future integrations planned for SAP Concur and additional fintech data sources.

In the legal domain, agents automate document compliance and redaction workflows by automatically stripping personally identifiable information (PII) and flagging unauthorized brand logos to shorten human review cycles. Additionally, an eDiscovery and document retrieval agent scans thousands of internal records to extract specific legal artifacts, substantially reducing outside counsel costs and billable lawyer hours.

Underpinning this entire agentic ecosystem is eBay’s implementation of internal Model Context Protocol (MCP) servers built to Anthropic’s open standard. Serving as a unified data fabric, MCP enables both local tools (such as local GitHub MCP servers that execute autonomous branch and code operations) and custom remote integrations (such as an internal API discovery MCP server) to expose tools and context seamlessly to any agent across the enterprise.

- **Finance Workflows**: Handles ~5,000 annual travel and PO tickets via live SAP Ariba data integrations, standing as the platform's second most active no-code agent. - **Legal Automation**: Automates PII redaction, unapproved logo detection, and large-scale eDiscovery document retrieval to curtail legal and audit expenses. - **MCP Foundation**: Utilizes Anthropic-standard local (e.g., GitHub action automation) and remote (e.g., internal API discovery) MCP servers as a standardized data fabric across all agents.

[17:48](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1068s) Value of Finance Agents in Complex Ticket and Invoice Workflows

Opening the floor for questions, Ramesh responds to an inquiry regarding why employees cannot simply look up an invoice status themselves rather than relying on a dedicated finance agent. He explains that enterprise finance workflows are rarely as simple as viewing a single status field. Invoices are frequently bound to complex contracts, dependencies, and multiple sub-tickets containing extensive contextual information. While a straightforward "resolved" status is simple enough, workflows that are stalled or in progress require a holistic view to understand where bottlenecks are occurring and what is driving the delay.

An agent can traverse and absorb all of this surrounding data simultaneously across the main ticket and its related sub-contracts, aggregating everything into a single, comprehensive status report. Instead of forcing an employee to manually track down and cross-reference multiple disparate records, the agent provides full visibility into the exact stage where the workflow is held up.

- Enterprise finance workflows involve multi-layered dependencies, linking parent tickets to various sub-tickets, vendor contracts, and invoice items. - AI agents aggregate distributed data into a consolidated status summary, highlighting blockers rather than returning a raw status code.

---

[19:05](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1145s) Hybrid Architecture: Balancing Glean Connectors with In-House Frameworks

Addressing whether eBay relies on third-party commercial vendors or builds in-house tools, Ramesh notes that the company actively pursues a hybrid approach. eBay evaluates and adopts vendor solutions, using Glean for enterprise search and off-the-shelf data connectors, while concurrently developing custom internal frameworks. The decision to use a vendor versus an internal agent is driven entirely by the specific use case, data locality, and time-to-market considerations rather than dogma over "which solution is the best."

When enterprise systems can be easily connected using Glean's pre-built connectors, eBay takes advantage of them to accelerate delivery. Conversely, when interacting with proprietary internal data sources, internal APIs, or specialized Model Context Protocol (MCP) servers that demand custom authentication logic, eBay builds directly on its internal framework.

```mermaid flowchart TD accTitle: eBay Hybrid AI Architecture accDescription: Flow showing how data requests are split between Glean connectors and eBay's custom MCP framework based on data location.

subgraph Ingestion["Request & Source Evaluation"] Req["User Request / Query"] --> Route{"Data Source Location"} end

subgraph Vendor["Vendor Integration"] Route -->|"Standard Enterprise App"| Glean["Glean Connectors"] Glean --> EntData["Enterprise Systems"] end

subgraph Internal["In-House Framework"] Route -->|"Proprietary eBay Data / APIs"| Custom["eBay Custom Framework"] Custom --> MCP["MCP Gateway & Internal Auth"] MCP --> CoreData["Internal Systems & Services"] end ```

- System selection is dictated by where the data resides and which solution delivers the fastest time-to-market. - Glean is utilized for standardized enterprise SaaS and document connectors across the organization. - In-house agent frameworks are reserved for proprietary APIs, domain-specific logic, and custom Model Context Protocol infrastructure.

---

[20:21](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1221s) Automated Metadata Enhancement and Two-Stage Routing

When asked how the platform handles metadata enhancement and routing, Ramesh explains the role of an automated "probing agent." When developers onboard new agents to the platform, their initial descriptions are often vague or poorly documented despite having fully functioning code. To bridge this gap, the platform deploys a probing agent that runs a battery of predefined questions against the newly onboarded agent. By analyzing the agent's responses and encapsulated behavior, the system automatically generates high-quality metadata and maps out its true capabilities.

This enhanced metadata powers eBay's two-stage routing pipeline as the ecosystem scales to hundreds of agents. When a user submits a prompt, the system first executes a fast candidate generation phase to retrieve the top-K candidate agents capable of handling the query. It then applies a deep LLM ranking step to inspect the candidates and pick the optimal agent for execution. Once the chosen agent delivers its answer, the platform captures explicit user feedback to continuously improve the routing model in a closed feedback loop.

```mermaid flowchart LR accTitle: Agent Metadata Generation and Two-Stage Routing accDescription: Diagram showing probing agent onboarding followed by two-stage candidate retrieval and deep LLM ranking.

subgraph Onboarding["Agent Onboarding"] NewAgent["New Agent"] --> Probe["Probing Agent"] Probe --> Meta["Generated Metadata Store"] end

subgraph Routing["Two-Stage Query Routing"] UserQ["User Query"] --> CandGen["1. Top-K Candidate Generation"] Meta -.-> CandGen CandGen --> LLMRank["2. Deep LLM Re-ranking"] LLMRank --> Exec["Agent Execution"] Exec --> Feedback["User Feedback Loop"] Feedback -.-> CandGen end ```

- Probing agents automatically interview newly registered agents with standardized test prompts to extract accurate functional capability descriptions. - The two-stage routing architecture combines initial broad candidate generation (top-K retrieval) with secondary deep LLM re-ranking. - Explicit user satisfaction signals feed back into the routing pipeline to refine agent selection accuracy over time.

---

[22:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1324s) AI Agents for Production and Pipeline Debugging

In response to an audience question about production support, Ramesh confirms that eBay deploys specialized agents for production troubleshooting and CI/CD delivery pipeline failures. These agents integrate directly with eBay's internal telemetry and monitoring systems, parsing and correlating logs across multiple architectural layers to locate root causes.

When test suites fail or deployment pipelines halt, the debugging agents isolate the exact failure points and surface relevant diagnostic summaries directly inside the delivery pipeline interface. Ramesh contrasts this with his early engineering career, noting: "when I was a developer like 10 years back I had to go through every single layer to really find where the issue is." Automating multi-layer log correlation drastically cuts down the mean time to resolution for operational regressions.

- Dedicated diagnostic agents hook directly into internal monitoring platforms to analyze multi-tier system logs. - Automated error surfacing provides immediate failure attribution directly inside CI/CD delivery pipelines without manual log hunting.

---

[23:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1384s) Securing Model Context Protocol (MCP) Servers via Custom Gateway

Addressing the mechanics of security and authentication for Model Context Protocol (MCP) servers, Ramesh describes eBay's implementation of a centralized internal MCP Gateway. Because standard MCP specifications require integration with corporate access controls, eBay built an abstraction layer that wraps internal authentication and authorization protocols.

This MCP Gateway encapsulates security policies, token management, and permission validation, enabling developers to expose proprietary data sources and APIs as agent tools safely. By centralizing authentication at the gateway level, individual teams can onboard services into the agentic ecosystem without having to implement custom auth mechanisms for each standalone MCP server.

- A custom eBay MCP Gateway abstracts enterprise authentication and authorization across all registered tool servers. - The gateway architecture standardizes secure onboarding of internal APIs, enforcing enterprise access policies before agent tools execute.

## Notable quotes > [03:06](https://www.youtube.com/watch?v=RFxfEV_siMM&t=186s) Every developer who wastes a single minute equals wasted innovation. — Ramesh Periyathambi

> [22:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1324s) when I was a developer like 10 years back I had to go through every single layer to really find where the issue is. — Ramesh Periyathambi

## Mentioned Ai4, Anthropic, eBay, GitHub, Glean, Model Context Protocol (MCP), OpenAPI, Ramesh Periyathambi, SAP Ariba, SAP Concur, Spring AI, Spring Boot

## Video description Ramesh Periyathambi, Distinguished Engineer, eBay Inc

Abstract

eBay is heavily investing in AI to enhance developer and employee productivity. What if every support ticket could be routed to the right agent and resolved in seconds, instead of waiting for hours? In this session, I will demonstrate how our team at eBay extended our chatbots into an Agentic AI platform that is transforming tech support. With hundreds of agents automating our support processes, I’ll explain how context-aware routing enabled agentic AI orchestration.

We’ll dive deep into our tech support metrics, including research and survey findings that revealed developers wasted an average of 92 minutes waiting for answers before the advent of AI agents. I’ll walk through how we calculate time saved through AI, based on resolved tickets.

I will also highlight one of our major initiatives: using AI for code migrations. This includes leveraging agentic workflows to auto-generate OpenAPI specs for legacy services and perform framework upgrades using specialized prompts. Our scalable architecture has allowed us to migrate thousands of legacy code repositories and services, achieving 3x productivity.

Additionally, I’ll touch on use cases focused on accelerating finance and legal workflows. Finally, I’ll share how eBay is using Model Context Protocol (MCP) servers to power our agents.

[Source](https://www.youtube.com/watch?v=RFxfEV_siMM)

中文简报

赋能 eBay:上下文感知路由与 MCP 智能体 AI 重塑支持及迁移 eBay 已从基础知识库聊天机器人过渡到先进的多智能体平台,旨在消除开发摩擦并将工单周转时间从 24 小时缩短至数分钟。在自动化探测智能体与两阶段上下文感知路由架构的支持下,该系统自主解决了超过 21% 的内部支持咨询,同时挽回了数千小时的开发者专注时间。该智能体框架还推动了大规模代码现代化——在框架迁移和契约优先的 OpenAPI 生成上带来了 3 倍的生产力提升——并正在扩展至财务、法律合规以及基于 MCP 的安全工具编排领域。 eBay 已从基础的内部 RAG 知识聊天机器人,演进为一个支持无代码配置和基于 Spring AI 定制代码的双轨企业级 Agentic AI 平台。 (0:04) 针对以往工单平均需等待 24 小时、导致工程师因频繁上下文切换累计浪费 92 分钟专注时间的问题,eBay 借助数百个细分领域的专业智能体实现了端到端自动化解决,目前已有超 21% 的技术支持工单完全由 AI 自主搞定。 (3:06) 平台构建了上下文感知路由系统,通过探测智能体自动清洗与补全元数据,并结合 Top-K 向量检索、动态 Few-Shot 思维链重排及自洽性集成,实现高效精准的智能体分发。 (6:34) 在代码迁移工程中,eBay 放弃模型微调,转而采用针对单文件的动态 Prompt 组装策略,在服务 900 余名工程师的过程中实现了 3 倍的生产力提升,OpenAPI 规范自动生成准确率突破 80%。 (11:44) 智能体能力进一步拓展至财务(直连 SAP Ariba)与法务合规场景,并依托 Anthropic 标准的内部 MCP 网关统一管理鉴权,安全打通企业私有数据与工具生态。 (14:16)

Reading summary

eBay has developed an enterprise agentic AI platform to address developer productivity bottlenecks, legacy code modernization, and operational workflows across its marketplace infrastructure. Drawing on internal telemetry and architectural case studies presented by Ramesh, the platform uses stateful graph workflows, automated context-aware routing, and Model Context Protocol (MCP) integrations to streamline internal operations. Eliminating Developer Friction in Technical Support (3:06) eBay targeted internal developer support as the initial proving ground for agentic AI after telemetry revealed that resolving a technical support ticket required a 24-hour turnaround on average. During that window, engineers checked ticket statuses roughly four times. Drawing on industry research showing a 23-minute focus recovery time per context switch, eBay calculated that developers were losing 92 minutes of productive focus per inquiry. Factoring in an average of 20 minutes of support engineer effort, each manual ticket represented a baseline organizational cost of 112 minutes. To address this overhead, eBay deployed specialized agents running stateful graph workflows that execute modular tasks including intent classification, retrieval-augmented generation (RAG), domain logic, and automated self-critique. Ticket resolution is tracked via explicit engineer confirmation and implicit LLM-as-a-judge scoring using a composite threshold of at least 7 out of 10. According to the presentation, automated agents now resolve over 21% of eBay's enterprise technical support requests end-to-end, reducing turnaround times from a full day to minutes. Context-Aware Two-Stage Agent Routing (6:34) As internal teams built hundreds of specialized agents, directing developer inquiries to the correct agent became a primary architectural hurdle due to noisy, heterogeneous metadata. eBay resolved this dynamic discovery challenge by introducing an automated probing agent that interviews newly registered agents with standardized test prompts, extracting functional capabilities to generate structured capability profiles. Incoming developer requests are processed through a two-stage routing pipeline. The system first executes vector-based candidate generation to retrieve the top-K relevant agents, followed by an LLM-driven ranking stage. The ranking stage incorporates dynamic few-shot examples from vector memory, explicit Chain of Thought prompts, and self-consistency ensembling. Internal ablation studies confirmed that omitting dynamic few-shot retrieval or ensembling caused noticeable drops in routing accuracy, while downstream explicit user feedback continuously fine-tunes candidate generation. Code Modernization and CI/CD Diagnostics (11:44) Beyond routine support, eBay applied agentic workflows to modernize legacy systems, specifically contract-first API development and major framework upgrades. For API contracts, a supervisor agent coordinates sub-agents to parse legacy codebases and generate OpenAPI specifications, achieving over 80% contract accuracy against internal standards. For upgrading legacy Spring applications to Spring Boot, dynamic per-file prompt assembly paired with few-shot examples outperformed model fine-tuning, driving a 3x productivity improvement across 900 participating engineers. In operational environments, specialized diagnostic agents integrate directly into internal CI/CD pipelines and telemetry systems. When automated test suites fail or deployments stall, these agents correlate multi-tier logs across system layers to identify root causes and output diagnostic summaries within the delivery pipeline interface, removing the need for engineers to manually inspect multiple operational layers. Enterprise Expansion, Hybrid Architecture, and MCP (14:16) The platform has expanded into business operations, including finance and legal workflows. A travel and purchase order agent manages roughly 5,000 annual tickets by interfacing directly with SAP Ariba, synthesizing complex multi-contract dependencies and invoice blockers that raw status codes fail to explain. In the legal sector, agents automate PII redaction, detect unapproved brand logos, and conduct large-scale eDiscovery searches across internal records to lower outside counsel costs. Architecturally, eBay maintains a hybrid infrastructure: commercial Glean connectors are deployed for standard enterprise SaaS applications, while custom internal frameworks handle proprietary APIs and data sources. All internal tools are unified through Anthropic's Model Context Protocol (MCP) standard, governed by a centralized internal MCP Gateway that manages token validation, access policies, and enterprise authentication across all registered servers. eBay's agentic platform demonstrates measurable productivity gains in tech support and codebase modernization, but maintaining performance across hundreds of autonomous tools requires continuous operational guardrails, including automated probing for metadata quality, two-stage LLM routing, and centralized MCP security governance.

精炼阅读摘要

eBay技术团队在Ai4分享中阐述了其依托上下文感知路由与模型上下文协议(MCP)构建的企业级智能体AI平台,旨在化解其海量电商业务规模下的研发支持阻力并加速遗留系统现代化改造。据演讲者介绍,该系统通过两阶段智能路由、自动化元数据生成以及状态图工作流,已将AI深度融入软件开发、运维调试以及财务和法务等业务流程中。 研发支持瓶颈与ROI驱动的智能体网络 (3:06) 在承载23亿件在线商品与1.34亿活跃买卖家的业务体量下,eBay将技术支持选为智能体平台的首个落地试验场。平台先前的内部遥测与调查显示,开发者技术支持工单的平均解决周期长达24小时;期间工程师平均查验进度4次,结合每次打断后约23分钟的注意力恢复成本,单张工单导致开发者损失约92分钟的专注时间。叠加技术支持工程师20分钟的处理耗时,传统单张工单的综合组织成本基线达112分钟。为此,团队上线了包含数百个细分智能体的架构,通过框架智能体(Framework Agent)执行涵盖意图分类、知识检索、领域逻辑与自动化自我校验的状态图工作流,将工单平均响应周期缩短至数分钟。 基于双轨评估的研发时间节约量化 (9:32) 为客观评估AI在技术支持领域的落地成效,eBay建立了将112分钟基线成本乘以AI解决工单总数的数学计算模型。解决状态通过双轨机制判定:一是工程师手动确认解决的显式反馈,二是由大语言模型裁判基于复合质量标准进行的隐式评估(综合评分达7分及以上判定为有效解决)。目前该系统每月服务数千名活跃开发者,全公司超过21%的技术支持请求由智能体网络实现端到端无人化闭环,将大量工时重新释放回产品研发阶段。 上下文感知路由与动态智能体发现 (6:34) 针对内部大量智能体涌现带来的分发混乱与异构元数据问题,eBay构建了一套结合自动化元数据扩充与两阶段路由的调度体系。新智能体接入平台时往往缺乏规范文档,系统借助探测智能体(Probing Agent)向其发送标准化测试提示词,通过分析执行反馈自动提炼能力边界并生成高质量元数据。在请求接入阶段,系统首先基于向量检索完成Top-K候选生成,继而由大语言模型路由器拉取动态少样本、启动思维链分析并执行自我一致性集成表决完成最终排序。消融实验证实,移除动态少样本或集成机制会导致路由准确率显著下滑。 代码库重构与流水线调试的工程落地 (11:44) 在日常问答之外,智能体架构被用于处理契约优先的API迁移和传统框架升级(如遗留Spring升级至Spring Boot)。在契约迁移中,主管智能体协调子智能体解析旧代码并自动生成OpenAPI规范,契约合规率超过80%;在框架迁移中,动态按文件组装运行时模板与针对性少样本的策略表现优于模型微调方案,在900余名工程师中实现了3倍的生产力提升。此外,专门的排错智能体直连内部遥测系统与CI/CD交付流水线,通过跨架构层级日志关联直接输出根因摘要,避免了传统人工逐层排查的复杂过程。 跨业务拓展与基于MCP的企业级混合架构 (14:16) 平台目前已拓展至财务与法务场景。差旅与采购订单智能体通过直连SAP Ariba等企业ERP系统,聚合主工单、子合同及发票之间的复杂依赖,每年处理约5,000张工单并清晰呈现卡点;法务智能体则用于自动化PII脱敏、未授权品牌标志检测与电子数据调取。架构层面上,eBay采取实用主义的混合路线:标准SaaS与文档连接借助Glean实现,私有API与核心逻辑则构建于自研框架之上;同时建立统一的内部模型上下文协议网关(MCP Gateway),集中管理访问认证、令牌与权限控制,确保安全合规地向全域智能体暴露工具与上下文。 eBay展示了智能体通过提示词工程、两阶段路由及开放协议深入复杂企业级业务的可行性,但演讲内容主要聚焦于流程提效与正面收益,未详细披露极端异构代码迁移中的容错成本及未来大规模智能体网络的长期算力支出与治理挑战。

Detailed notes — zh

## Background 本内容由 Ai4 频道于 2025 年 8 月 27 日发布在 YouTube 平台。视频由 eBay 杰出工程师 Ramesh Periyathambi 主讲,展示了 eBay 如何通过构建具备上下文感知路由能力的 Agentic AI 平台,革新技术支持、代码迁移以及财务法务等企业级工作流程。 ## TL;DR 演讲围绕 eBay 如何利用 Agentic AI 解决开发者“92 分钟等待黑洞”展开,详细介绍了从早期 RAG 向由数百个专业智能体组成的庞大舰队的演进历程。系统依托包含元数据探针与“召回-重排”的两阶段上下文感知路由,实现了 21% 的技术支持完全自主解决率,并在框架迁移上借助动态 Prompt 达成 3 倍生产力飞跃。此外,eBay 还将智能体拓展至财务工单聚合、法务脱敏等场景,并通过基于 Anthropic MCP 的统一协议与定制 MCP 网关筑牢企业数据底座。 ## Atmosphere & style 整场演讲风格硬核务实且充满极客气息,Ramesh 以自信从容的工程师视角,将庞杂的架构演进与严谨的量化指标娓娓道来。分享既有清晰严密的系统架构图与消融实验剖析,也有回顾十年前“人工一层层翻日志”与当下自动化排障对比的生动感慨。现场互动紧凑真实,问答环节直面自研与采购的选型权衡,让观众在严谨的技术洗礼中直观感受到工业级 Agentic AI 落地带来的真实生产力变革。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=4s) eBay 拥有超过 23 亿件在线商品与 1.34 亿活跃用户,沉淀了近 30 年的电商数据,正将这些企业知识全面转化为 Agentic AI 智能体体系。 - [01:46](https://www.youtube.com/watch?v=RFxfEV_siMM&t=106s) 智能化演进路径从最初模块化解耦的单一内部 RAG 聊天机器人,逐步升级为支持无代码与 Spring AI 定制化方案的 Agentic AI 统一平台。 - [03:09](https://www.youtube.com/watch?v=RFxfEV_siMM&t=189s) 传统技术支持存在“92 分钟开发者时间黑洞”:24 小时平均响应周期内产生 4 次主动检查,每次打断带来 23 分钟心流恢复成本。 - [05:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=304s) eBay 部署了数百个高度专业化的技术支持智能体,依托支持图工作流(Support Graph)实现自我批判与校验,将解决时间缩短至数分钟。 - [06:34](https://www.youtube.com/watch?v=RFxfEV_siMM&t=394s) 采用上下文感知路由机制:通过探测智能体增强元数据,并结合 Embedding 候选生成与 LLM 深度排序的两阶段架构实现高精度流量分发。 - [09:32](https://www.youtube.com/watch?v=RFxfEV_siMM&t=572s) 建立单工单 112 分钟的基准耗时模型,结合显式反馈与 LLM-as-a-judge 隐式打分,实现超 21% 的技术支持请求全自动闭环解决。 - [11:44](https://www.youtube.com/watch?v=RFxfEV_siMM&t=704s) 代码重构中发现针对特定文件的运行时动态专业提示词(Specialized Prompts)效果显著优于全量微调,支撑了大规模框架升级与 OpenAPI 规范生成。 - [11:44](https://www.youtube.com/watch?v=RFxfEV_siMM&t=704s) 在 900 多名参与框架升级的开发者中,智能体工作流带来了 3 倍生产力跃升,且自动生成的契约合规准确率超过 80%。 - [14:16](https://www.youtube.com/watch?v=RFxfEV_siMM&t=856s) Agentic AI 扩展至财务与法务领域,打通 SAP Ariba 自动处理每年 5,000 张差旅及 PO 工单,并提供 PII 脱敏及电子数据调证能力。 - [17:48](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1068s) 财务智能体能够聚合跨系统主工单、子合同及发票的多维关联信息,提供全局瓶颈诊断报告而非单一状态查询。 - [19:05](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1145s) 技术选型采用双轨制:标准化通用企业连接复用 Glean 现成方案,专有业务数据与深度鉴权则由自研 eBay Agent 框架承载。 - [16:34](https://www.youtube.com/watch?v=RFxfEV_siMM&t=994s) 基于 Anthropic MCP(Model Context Protocol)构建统一数据编织层,配合自研 MCP Gateway 集中封装复杂的企业认证与权限控制。 - [22:05](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1325s) 部署专业运维排障智能体对接内部监控,跨层级关联日志并直接在交付流水线前端呈现单元测试与环境故障根因。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=4s) eBay 的规模与 Agentic AI 的愿景 演讲开场,Ramesh Periyathambi 抛出了一个核心主题:eBay 如何通过一支具备上下文感知能力的 AI Agent(智能体)舰队,大幅削减技术支持等待时间、改造数千个代码库,并重塑财务与法务的工作流程。在深入技术细节之前,他首先展示了 eBay 庞大的业务规模作为背景支撑。 当前 eBay 平台上拥有超过 23 亿个在线商品(Live Listings),这一数字相当于“地球上每三个人就对应一件商品”。平台服务着 1.34 亿活跃买家和卖家,去年创造了 747 亿美元的总商品交易额(GMV),背后沉淀了近 30 年的电商数据与行业知识。Ramesh 现场与观众互动,询问近期使用过 eBay 进行买卖的人数,以此引出本次演讲的核心议题:如何将这些沉淀数十年的海量知识,转化为驱动全公司运转的 Agentic AI 体系。 - **23 亿+** 在线商品挂牌量(Live Listings) - **1.34 亿** 活跃买家与卖家 - **747 亿美元** 年交易总额 - **近 30 年** 的电商知识与数据积累 --- ### [01:46](https://www.youtube.com/watch?v=RFxfEV_siMM&t=106s) 从单一聊天机器人向 Agentic AI 平台的演进 eBay 的智能化之旅最初始于一个非常简单的内部 RAG(检索增强生成)聊天机器人。该系统的主要目标是为员工提供一个快速、便捷且基于内部知识库的可靠问答渠道。在初始架构设计中,团队特别注重模块化解耦,将数据管道(Data Pipelines)、检索(Retrieval)与生成(Generation)完全分离,这一前瞻性设计为后续引入动态路由和复杂编排打下了坚实基础。 随着业务需求的爆炸式增长,团队将该聊天机器人进一步升级为全面的 Agentic AI 平台,并提供了两种接入模式以覆盖不同团队的技术栈和需求层次: 1. **无代码方案(No-Code Solution)**:业务人员与非核心开发团队可以通过可视化配置快速上线特定领域的智能体。 2. **定制化方案(Custom Solution)**:基于 eBay 自研框架与 Spring AI 模块构建,供工程团队深度定制复杂逻辑与专属工作流。 --- ### [03:09](https://www.youtube.com/watch?v=RFxfEV_siMM&t=189s) 技术支持的痛点与 92 分钟的“开发者时间黑洞” 在探索 Agentic AI 的落地场景时,技术支持(Tech Support)成为了 eBay 首选且规模最大的切入点。Ramesh 强调了这一决策背后的核心理念:“开发者每浪费一分钟,就等于浪费一分创新力(Every developer who waste a single minute equals wasted innovation)。” 为了量化传统支持模式的低效,团队结合内部指标与调研数据测算了开发者的时间损耗基准: - **24 小时平均响应时间**:在引入 AI 之前,一个技术支持工单从提出到获得人工解答平均需要整整一天。 - **4 次频繁打断**:在等待答复的 24 小时内,开发者平均每天会主动查看进展或寻找替代方案至少 4 次。 - **23 分钟心流恢复成本**:根据行业研究,知识工作者在遭遇一次工作打断后,平均需要 23 分钟才能重新进入深度专注状态。 将 4 次打断乘以每次 23 分钟的恢复时间,意味着**每个技术支持问题会导致开发者浪费 92 分钟的有效工作时间**。消除这 92 分钟的时间黑洞,成为智能体平台的核心使命。 ```mermaid flowchart LR accTitle: 传统技术支持中的开发者时间损耗模型 subgraph S1["传统支持等待周期(24小时)"] A["提交支持工单"] --> B["等待人工排队响应"] end subgraph S2["注意力打断与损耗"] B --> C["单日主动检查进度:4 次"] C --> D["单次被打断后恢复专注:23 分钟"] end D --> E["单问题累计浪费时间:92 分钟"] ``` --- ### [05:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=304s) 专化智能体集群与 Support Graph 工作流 如今,eBay 内部运行着数百个高度专业化的技术支持智能体,每一个智能体都针对开发者研发旅程中的极窄切片进行了专项微调。当开发者的咨询消息进入平台时,系统会依托支持图工作流(Support Graph Workflow)将其路由至对应的专家智能体(例如 Framework Agent 框架智能体)。 ```mermaid flowchart TD accTitle: 技术支持图工作流架构 UserQ["开发者咨询消息"] --> RouterNode["上下文路由与分类节点"] subgraph SpecialistAgent["Framework Agent(框架智能体工作流)"] RouterNode --> Classify["意图识别 / 分类节点"] Classify --> RAGNode["RAG 知识检索节点"] RAGNode --> DomainLogic{"领域特定节点"} DomainLogic --> DeployNode["部署逻辑节点 (Deployments)"] DomainLogic --> MigrateNode["框架迁移节点 (Migration)"] end DeployNode --> SelfCritique["自我批判与校验 (Self-Critique)"] MigrateNode --> SelfCritique SelfCritique --> FinalResp["数分钟内交付高质量解答"] ``` 在框架智能体内部,每个图节点仅专注于单一任务——如分类、RAG 检索、或者部署/迁移等领域特定逻辑。以部署节点为例,它生成的解决方案不仅包含精准的配置说明,还会在后台经过自我批判与校验(Self-Critiqued),在几分钟内直接交付给开发者,从而彻底打破了过去 24 小时的等待僵局。目前,该智能体平台每月已承载数千名活跃开发者的技术支持需求。 --- ### [06:34](https://www.youtube.com/watch?v=RFxfEV_siMM&t=394s) 上下文感知路由(Context-Aware Routing)与两阶段筛选 随着接入平台的智能体数量迅速膨胀、流量剧增,如何像“交警(Traffic Cop)”一样精确、迅速地将提问分发给最合适的智能体,成为了系统的核心挑战。特别是在动态环境中,每天都有新创建的智能体加入,伴随而来的是大量嘈杂且不完备的元数据。 为此,eBay 设计了**上下文感知路由(Context-Aware Routing)**机制,整体架构包含元数据增强与两阶段筛选体系: 1. **元数据增强(Metadata Enhancement)**:利用探测智能体(Probing Agent)主动扫描并规范化新入驻智能体的功能描述与元数据。 2. **两阶段路由架构**: - **第一阶段:候选生成(Candidate Generation)**:通过 Embedding 向量匹配快速从海量智能体池中粗筛出 Top-K 候选集。 - **第二阶段:LLM 深度排序(LLM Router)**:将候选集输入 LLM 进行上下文内分类。在此阶段融合了多项技术——从向量数据库中动态提取 Few-Shot 样本、在 Prompt 中设置“详细分析”指令触发思维链(Chain of Thought, CoT),并利用自洽性集成(Self-Consistency Ensembling)确保判断的鲁棒性。 消融实验(Ablation Study)结果显示,这套组合机制在准确率上大幅超越了单纯基于 Embedding 或传统语义路由的基线模型;一旦移除动态 Few-Shot 或自洽性集成,分类与路由性能便会出现显著下滑。 --- ### [09:32](https://www.youtube.com/watch?v=RFxfEV_siMM&t=572s) AI 提效量化:112 分钟基准与 21% 的全自动解决率 为了科学评估 AI 在技术支持中创造的实际商业价值,eBay 建立了一套严谨的时间节省计算模型。 首先计算单个工单在无 AI 介入下的总体时间成本: $$\text{单工单耗时} = \text{开发者浪费时间 (92 分钟)} + \text{技术支持工程师处理耗时 (20 分钟)} = 112 \text{ 分钟}$$ *(注:支持工程师耗时根据问题类别与渠道略有浮动,基准平均值为 20 分钟)* 在引入 AI 后,总节省时间即为 112 分钟乘以 AI 自动解决的问题总量。为了精准判定“问题是否真正得到解决”,团队引入了双轨判定机制: - **显式反馈(Explicit Resolution)**:提问者在界面上主动将问答标记为“已解决”。 - **隐式判定(Implicit Resolution)**:当缺乏显式反馈时,采用大模型作为裁判(LLM-as-a-judge),从多个维度对问答交互进行多指标综合打分,只有综合评分 $\ge 7.0$ 时,才会被计入隐式解决。 数据表明,目前 eBay 全公司已有**超过 21% 的技术支持请求由 AI 完全自主闭环解决**,这直接为工程团队释放了数以千计的高价值研发工时。 --- ### [11:44](https://www.youtube.com/watch?v=RFxfEV_siMM&t=704s) 代码重构与框架升级:Contract-First 与运行时动态 Prompt 在技术支持之外,eBay 将 Agentic AI 推进至更深水区:大规模代码库迁移与重构。该行动主要聚焦于两大方向: 1. **契约优先迁移(Contract-First Migration)**:针对缺乏标准契约的遗留老旧服务,利用主管智能体(Supervisor Agent)编排多个子智能体,自动化完成代码解析、OpenAPI 规范文档(Spec)生成,并严格对照 eBay 内部架构标准进行合规性验证。 2. **框架自动化升级(Framework Upgrades)**:针对如 Spring 迁移至 Spring Boot 等大规模框架跃迁,团队曾尝试对模型进行全量微调(Fine-Tuning),但最终发现**基于专业提示词工程(Specialized Prompts)的效果远超微调**。 在实际执行中,系统会根据每一个待迁移的遗留代码文件,动态抽取专有提示词模板与 Few-Shot 示例,在运行时动态拼装针对该文件的专用 Prompt 并提交 LLM。这种按文件定制的精细化编排,极大地提升了迁移代码的可用度,消除了大量手动重构成本。 - **多端触达**:借助统一的 MCP 连接器,AI 代码智能体无缝集成在开发者的 IDE、CLI 命令行以及云端流水线中。 - **成效统计**:在参与框架升级与迁移的 900 多名开发者中,框架升级效率实现了 **3 倍(3x)生产力飞跃**,生成的 OpenAPI Spec 正确率与合规准确率超过 **80%**。 --- ### [14:16](https://www.youtube.com/watch?v=RFxfEV_siMM&t=856s) 拓展至财务与法务:Ariba 自动化与合规审查 Agentic AI 平台的能力不仅限于研发部门,还迅速渗透至财务(Fintech)与法务(Legal)等企业级运营流程中。 #### 财务智能体(Finance Agents) 覆盖差旅(Travel)、采购订单(Purchase Order, PO)、合同与薪酬管理。其中,“差旅与 PO 智能体”是全平台使用率仅次于头部技术智能体的第二大无代码智能体。该智能体能够直接连接 SAP Ariba 系统实时抓取差旅和采购数据(未来计划打通 Concur 及其他财务数据源)。由于公司每年仅差旅和 PO 咨询就产生约 5,000 张内部工单,该流程的自动化为行政与财务部门带来了极其显著的人效释放。 #### 法务智能体(Legal Agents) - **合规与脱敏(Compliance & Redaction)**:自动识别并脱敏文档中的个人身份信息(PII),并在内容审查中自动标识未授权的企业 Logo,大幅压缩人工法务复核周期。 - **电子数据调证与文档检索(eDiscovery & Document Retrieval)**:针对特定的法律监管与诉讼要求,在全公司数以万计的内部文档中精准定位合规证据集,极大减少了外部律所按小时计费的法律审查支出与内部法务工时。 --- ### [16:34](https://www.youtube.com/watch?v=RFxfEV_siMM&t=994s) 统一数据底座:基于 Anthropic MCP 的服务体系 在技术架构的最底层,支撑所有上述智能体高效运转的核心,是基于 Anthropic 提出的 **Model Context Protocol(MCP,模型上下文协议)** 构建的 eBay 内部 MCP 服务体系。 MCP 为平台构建了一个标准化的统一数据编织层(Unified Data Fabric),让所有智能体能够以即插即用的方式安全访问各类异构数据源: ```mermaid flowchart TD accTitle: 基于 MCP 的统一数据交互架构 subgraph AgentFleet["上层智能体集群 (Agent Fleet)"] CodeAgent["Code AI Agent"] TechAgent["Tech Support Agent"] BizAgent["Finance / Legal Agent"] end subgraph MCPFabric["统一 MCP 数据编织底座 (Model Context Protocol)"] LocalMCP["本地 MCP 服务 (Local MCP Servers)<br/>如:Local GitHub MCP Server"] RemoteMCP["远程定制 MCP 服务 (Remote MCP Servers)<br/>如:eBay API Discovery MCP Server"] end subgraph DataSources["企业异构数据与系统"] GitRepo["GitHub 代码库 / CI/CD"] APIDoc["企业内部 API 注册表"] ERP["SAP Ariba / 金融数据源"] end AgentFleet <--> MCPFabric LocalMCP <--> GitRepo RemoteMCP <--> APIDoc RemoteMCP <--> ERP ``` - **本地 MCP 服务(Local MCP Server)**:例如本地 GitHub MCP 服务,它赋予了代码智能体在开发者本地环境中自主执行 Git 提交、PR 创建、分支管理等操作的能力。 - **远程 MCP 服务(Remote MCP Server)**:例如为 eBay 定制构建的 API Discovery 远程服务,供智能体在整个企业网络内动态发现并调用合规的后端接口。 通过这套基于开放标准的 MCP 架构,eBay 将智能体、工具与海量企业数据紧密缝合为一个有机整体,完成了从孤立对话工具向全自主协作生态的系统性跨越。 ### [17:48](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1068s) 财务智能体价值:从孤立状态到全局视图 演讲结束进入问答环节后,首个提问直击业务痛点:既然员工可以直接在财务系统中自行查询发票状态,为什么还需要专门构建一个财务智能体(Finance Agent)? ```mermaid flowchart TD accTitle: 财务智能体多源聚合与分析架构 accDescription: 展示财务智能体如何从主工单、子合同及关联发票中提取并聚合上下文信息,输出全局状态报告。 subgraph Input["数据源层"] T["主工单 (Main Ticket)"] C["子合同 (Sub Contracts)"] I["关联发票 (Invoices)"] end subgraph Agent["财务智能体 (Finance Agent)"] Agg["多维信息吸收与聚合<br/>(Information Absorption)"] Diag["瓶颈诊断与全局分析<br/>(Bottleneck Diagnosis)"] end subgraph Output["交付层"] R["全景状态报告 (Status Report)<br/>• 阻滞环节定位<br/>• 耗时归因分析"] end T --> Agg C --> Agg I --> Agg Agg --> Diag Diag --> R ``` 演讲者解释道,现实中的企业财务流程远非“查一个状态码”那么简单。发票往往与复杂的合同、主工单以及一系列子工单相互交织,背后包含大量外围上下文信息。如果一个工单处于正常流转或已解决状态,大家自然皆大欢喜;但如果工单卡在“进行中”甚至陷入停滞,员工最需要了解的是“全局全貌”(Big Picture)——究竟是哪个子环节卡住了?为什么会耗费这么长时间?财务智能体能够主动吸收并整合所有子合同与发票的关联数据,一次性生成综合性的状态报告与归因分析,而不是让员工在多个系统和子单据之间来回翻找。 - **多维上下文聚合**:智能体打破了“单点查询”的局限,能够将主工单与其下挂的子合同、发票凭证等周边信息打包为完整的“整体信息”(Collective Information)。 - **深层瓶颈定位**:重点解决流程异常或停滞时的排查痛点,明确指出流转堵塞的具体节点与耗时原因。 --- ### [19:05](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1145s) 第三方方案(Glean)与 eBay 自研框架的双轨架构 针对“eBay 究竟是完全自研还是采购第三方供应商方案”的疑问,演讲者明确表示 eBay 采取的是“自研与采购并重”的双轨路线。每个企业都会评估各种供应商产品,eBay 在企业级搜索和通用连接器方面引入了 Glean,但同时也深度构建了 eBay 自己的定制化智能体框架。 这种技术选型主要取决于具体业务场景(Use Cases)与数据源位置,核心权衡点在于“上市与交付时间”(Time to Market): 1. **企业级通用系统连接**:对于标准化的企业系统,直接复用 Glean 现成的连接器(Connectors),能够以最快速度完成对接上线。 2. **eBay 内部专有数据与系统**:eBay 内部沉淀了大量专有 API 与敏感业务数据,并且在对接 MCP(Model Context Protocol)服务器时,需要深度集成企业特有的认证与授权机制,因此采用自研的 eBay Agent 框架来支撑。 --- ### [20:22](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1222s) 元数据探针与两阶段智能路由机制 当被问及“智能体元数据是如何增强的”以及“系统如何将具体请求路由到对应智能体”时,演讲者揭示了底层核心的“探针机制”(Probing Agent)与两阶段路由算法。许多开发团队在注册新智能体时,填写的描述信息往往非常简略或不够清晰;为此,eBay 设计了专门的探测智能体,使用一套预定义的标准问题库去“盘问”新上线的智能体,根据其返回结果自动提炼并补全元数据,从而精准掌握其真实功能边界。 ```mermaid flowchart LR accTitle: 两阶段智能路由与反馈闭环 accDescription: 用户请求经由 Top-K 候选生成和深度 LLM 重排,命中目标智能体并建立用户反馈闭环。 subgraph Stage1["第一阶段:召回"] Q["用户请求 (User Query)"] --> CG["候选生成 (Candidate Gen)<br/>筛选 Top-K 智能体"] end subgraph Stage2["第二阶段:排序与执行"] CG --> DeepRank["深度 LLM 重排<br/>(Deep LLM Ranking)"] DeepRank --> Target["目标执行智能体<br/>(Selected Agent)"] end subgraph Stage3["反馈闭环"] Target --> Res["生成最终响应"] Res --> FB["用户反馈采集<br/>(Feedback Loop)"] FB -.->|"持续校准优化"| DeepRank end ``` 在路由分发环节,面对平台内数百个智能体的规模,传统简单的分发策略难以为继,系统采用了经典的两阶段决策流程: 1. **第一阶段(Candidate Generation)**:基于强化后的元数据快速过滤,检索出最可能匹配的 Top-K 候选智能体。 2. **第二阶段(Deep LLM Ranking)**:利用大语言模型对候选智能体进行深度重排与精准决策,挑出最佳智能体执行任务。 3. **反馈闭环(Feedback Loop)**:任务执行完毕后,系统会主动收集用户对回答质量的反馈(好评/差评),持续反哺并调优路由模型。 --- ### [22:05](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1325s) 生产环境排错、流水线排障与 MCP 鉴权网关 演讲者进一步分享了智能体在运维排障和安全架构方面的落地实践。虽然主讲环节未及展开,但 eBay 内部已经深度部署了用于生产调试与交付流水线(Delivery Pipeline)排障的专业智能体。这些智能体直接对接内部监控系统,能够跨越多个架构层级自动抓取并关联日志,快速定位由于单元测试失败、依赖异常或环境故障引发的流水线中断。演讲者感叹道,相比十年前自己做开发时必须“一层一层人工翻查日志”,如今通过智能体在流水线前端直接呈现根因,排障效率得到了质的飞跃。 针对 MCP 服务器的鉴权(Authentication & Authorization)问题,eBay 自研了定制化的 **MCP Gateway(MCP 网关)**: - **安全与权限封装**:将 eBay 内部复杂的认证与鉴权协议统一封装在网关层,底层数据源和 API 无需各自重复实现企业安全规范。 - **数据源快捷接入**:开发者与各业务团队可以通过 MCP 网关标准化地接入特定的专有数据源,由网关统一把控权限边界并安全地供智能体调用。 ## Notable quotes > [03:09](https://www.youtube.com/watch?v=RFxfEV_siMM&t=189s) Every developer who waste a single minute equals wasted innovation — Ramesh Periyathambi > [00:04](https://www.youtube.com/watch?v=RFxfEV_siMM&t=4s) 地球上每三个人就对应一件商品 — Ramesh Periyathambi > [03:09](https://www.youtube.com/watch?v=RFxfEV_siMM&t=189s) 开发者每浪费一分钟,就等于浪费一分创新力 — Ramesh Periyathambi > [03:09](https://www.youtube.com/watch?v=RFxfEV_siMM&t=189s) 每个技术支持问题会导致开发者浪费 92 分钟的有效工作时间 — Ramesh Periyathambi > [11:44](https://www.youtube.com/watch?v=RFxfEV_siMM&t=704s) 基于专业提示词工程(Specialized Prompts)的效果远超微调 — Ramesh Periyathambi > [09:32](https://www.youtube.com/watch?v=RFxfEV_siMM&t=572s) 超过 21% 的技术支持请求由 AI 完全自主闭环解决 — Ramesh Periyathambi > [22:05](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1325s) 一层一层人工翻查日志 — Ramesh Periyathambi > [19:05](https://www.youtube.com/watch?v=RFxfEV_siMM&t=1145s) 自研与采购并重 — Ramesh Periyathambi ## Mentioned eBay, Ramesh Periyathambi, Ai4, Model Context Protocol (MCP), Anthropic, Spring AI, Spring Boot, OpenAPI, SAP Ariba, Concur, Glean, GitHub, RAG ## Video description Ramesh Periyathambi, Distinguished Engineer, eBay Inc Abstract eBay is heavily investing in AI to enhance developer and employee productivity. What if every support ticket could be routed to the right agent and resolved in seconds, instead of waiting for hours? In this session, I will demonstrate how our team at eBay extended our chatbots into an Agentic AI platform that is transforming tech support. With hundreds of agents automating our support processes, I’ll explain how context-aware routing enabled agentic AI orchestration. We’ll dive deep into our tech support metrics, including research and survey findings that revealed developers wasted an average of 92 minutes waiting for answers before the advent of AI agents. I’ll walk through how we calculate time saved through AI, based on resolved tickets. I will also highlight one of our major initiatives: using AI for code migrations. This includes leveraging agentic workflows to auto-generate OpenAPI specs for legacy services and perform framework upgrades using specialized prompts. Our scalable architecture has allowed us to migrate thousands of legacy code repositories and services, achieving 3x productivity. Additionally, I’ll touch on use cases focused on accelerating finance and legal workflows. Finally, I’ll share how eBay is using Model Context Protocol (MCP) servers to power our agents. [Source](https://www.youtube.com/watch?v=RFxfEV_siMM)

Source quotes

[3:09] Ramesh Periyathambi: Every developer who waste a single minute equals wasted innovation [0:04] Ramesh Periyathambi: 地球上每三个人就对应一件商品 [3:09] Ramesh Periyathambi: 开发者每浪费一分钟,就等于浪费一分创新力 [3:09] Ramesh Periyathambi: 每个技术支持问题会导致开发者浪费 92 分钟的有效工作时间 [11:44] Ramesh Periyathambi: 基于专业提示词工程(Specialized Prompts)的效果远超微调 [9:32] Ramesh Periyathambi: 超过 21% 的技术支持请求由 AI 完全自主闭环解决 [22:05] Ramesh Periyathambi: 一层一层人工翻查日志 [19:05] Ramesh Periyathambi: 自研与采购并重

Source quotes

[3:06] Ramesh Periyathambi: Every developer who wastes a single minute equals wasted innovation. [22:04] Ramesh Periyathambi: when I was a developer like 10 years back I had to go through every single layer to really find where the issue is.

Original transcript

[0:04] Today I'm going to show you how a fleet [0:08] of context aware AI agents have slashed [0:13] tech support weight times, transformed [0:15] thousands of code bases and also [0:19] streamlined finance and legal. [0:23] Uh before I deep dive, I want to set the [0:26] stage with eBay scale. [0:32] eBay has over 2.3 billion live listings [0:36] on the site today. That is roughly about [0:41] one item for every third person on [0:44] Earth. [0:46] And uh it serves 134 million active [0:49] buyers and sellers [0:51] and generated 74.7 [0:55] billion total sales last year. All with [0:59] nearly 30 years of e-commerce data and [1:03] knowledge. [1:04] I just want to ask all of you, how many [1:06] of you have used eBay recently for [1:09] buying or selling? [1:12] Fantastic. [1:15] Okay, here's today's agenda. [1:19] Our journey from a simple chatbot to a [1:23] agentic platform. [1:26] deep dive into tech support and code [1:28] migrations [1:30] and quick wins on finance and legal and [1:34] finally how our internal model context [1:38] protocol MCP servers ties it all [1:41] together. [1:46] We started with a very simple chatbot. [1:50] A detailed tech blog about this is [1:52] linked in this QR code here. And uh this [1:57] gave us our employees a very quick and [2:01] easy way to get reliable answers [2:05] grounded in our internal knowledge base. [2:11] This is a architecture of our chatbot. [2:16] A detailed talk about this uh is linked [2:19] in the QR code that I did last year in [2:21] the last year conference. [2:24] We made the uh the architecture very [2:27] modular separating data pipelines and [2:32] retrieval and generation so that we can [2:35] add components like routing later on. [2:42] So we took this simple chatbot and then [2:45] transformed that into a agentic AI [2:49] platform with two onboarding [2:52] capabilities. First a no code solution [2:56] and second a custom solution which is [3:00] built on top of ebase framework and [3:02] spring AI modules. [3:06] Our [3:09] first and largest use case that we [3:12] started is tech support. Why did we [3:16] start here? [3:17] Because every developer who waste a [3:21] single minute equals wasted innovation. [3:27] So [3:30] we wanted to see how much a developer is [3:33] wasting time. So we calculated the [3:36] baselines of developer wester time [3:40] and based on our internal data metrics [3:45] and surveys we see an average support [3:49] response time is 24 hours and developer [3:54] checks at least four times a day [3:58] within that 24 hours to check for [4:01] whether they got an answer or checking [4:03] for other solutions. s also based on [4:06] industry research [4:09] we saw [4:11] uh a developer to regain focus he needs [4:15] 23 minutes to [4:18] uh after an interruption has occurred. [4:23] So putting this all together like it's [4:25] 92 minutes of wasted time per question. [4:31] Our mission was clear. Give this time [4:34] back to our developers and employees. [4:40] Today we run more than hundreds of [4:44] specialized tech support agents. [4:48] Everything tuned for a narrow slice of [4:51] developer journey. Some are created with [4:54] no code solutions and some with custom [4:57] solutions. [5:04] U so this is a sample of how a support [5:08] message [5:09] is flowing in our agentic platform and [5:14] gets routed to one of our tech support [5:16] agent. Here it is framework agent and [5:20] how one of the node in the framework [5:24] agent responds to the particular [5:25] question using a support graph workflow. [5:32] Zooming in you can see each of the node [5:36] is specialized with one task. Either it [5:40] can be classification or rack retrieval [5:43] or domain specific logic like [5:47] deployments or migration. [5:51] Here [5:52] is a sample of a real response that uh [5:57] is returned by a deployment node from [6:02] framework agent [6:04] and as you see it is all autogenerated [6:07] self-critiqued and delivered within [6:10] minutes. [6:14] Today the adoption has exploded into [6:18] thousands of developers per month for [6:20] our agentic platform. While we see [6:24] uh the reduction of support response [6:27] times from 24 hours to minutes. [6:34] With this traffic saring, we really [6:37] wanted a reliable way to route all these [6:42] messages and questions to the right [6:45] agent quickly. So we wanted somebody [6:49] like a traffic cop. So this is where our [6:53] context of our routing comes in. [6:58] Some of the common challenges that we [7:00] face during the context aware of our [7:02] routing are an ever growing agent pool [7:07] and uh noisy metadata of new agents [7:11] getting created every day and getting [7:13] added dynamically into our platform. [7:18] So we started with the metadata [7:21] enhancement using a probing agent and [7:25] then followed by a two-stage selection [7:27] process. The first is a candidate [7:30] generation for selecting the top K agent [7:34] using embeddings [7:35] and next is the LLM based ranking. [7:42] In our LLM based router, we do the in [7:45] context classification using techniques [7:48] like dynamic few short examples retrieve [7:52] from our vector database [7:55] chain of thought which is in the prompt [8:00] and self-consistency ensembling for more [8:03] robustness. [8:08] This visual shows [8:11] metadata enhancement, [8:13] candidate generation and LLM router all [8:17] in one flow. [8:21] Here is a prompt that EU used for [8:24] context aware routing which uses the [8:28] assistant metadata [8:30] and [8:31] also the examples for few short [8:34] learnings from the vector database [8:38] and also we have a prompt saying [8:41] detailed analysis triggering the chain [8:44] of thought and finally getting a [8:46] response of all agents. [8:49] uh ranked and scored. [8:55] Our routing results show a better [8:57] performance [8:59] here. If you see the LLM router and the [9:02] candid generation top five, it's it [9:05] beats the baselines of embedding or [9:09] semantic router [9:12] accuracies. [9:14] Also use uh like in the ablation study [9:18] what we saw was removing some of the [9:21] techniques what we have used like [9:23] dynamic f short learnings or [9:26] self-consistency impacted the results. [9:32] We did a lot of research and work to [9:35] really understand how much AI is helping [9:40] to save our developers time in tech [9:43] support. [9:47] So to calculate we started with [9:50] calculating the total amount needed for [9:53] tech support without using AI. We took [9:57] the 92 minutes that I explained before [10:00] as developer wester time and added that [10:04] with 20 minutes which is the support uh [10:09] engineer effort time and this can vary [10:12] based on like categories or the channels [10:15] the support channels. [10:19] So that is 112 minutes [10:23] per request. [10:28] So to calculate the total time with [10:31] using AI, we took this 112 minutes and [10:34] multiplied by the number of questions [10:38] resolved automatically using AI. [10:43] So we calculated the resolution in two [10:45] ways. First an explicit way where user [10:49] is marking a question and answer as [10:52] resolved or a implicit way where we use [10:56] the LLM judged [10:58] resolution. [11:03] uh for LLM uh judge resolution for [11:05] implicit feedback we use some of these [11:08] metrics listed here and we take a [11:11] composite score of greater than or equal [11:13] to 7 to mark a particular answer from AI [11:18] as implicitly resolved. [11:23] Today we see more than 21% of total [11:28] support requests [11:30] automatically resolved by AI. That is [11:35] equaling to thousands of developer hours [11:38] given back to engineering. [11:44] Our next frontier is code migrations, [11:47] large scale code migrations with two [11:50] focused areas. [11:53] First [11:54] contract first migration for generating [11:57] open API spec using agentic workflows [12:02] for legacy services. [12:04] Second, automating the framework [12:07] upgrades and [12:11] u migrations like spring to spring boot [12:14] for legacy applications using [12:17] specialized prompts. [12:22] In agentic workflow used in contract [12:24] migration, [12:27] we used a supervisor agent which [12:30] orchestrates all sub aents to parse [12:34] code, [12:36] generate open API spec and then finally [12:39] validate that with eBay standards. [12:45] For framework upgrades, [12:47] we tried different like uh fine-tuning [12:51] models. [12:52] What worked really well was specialized [12:54] prompts. For each of the legacy file, we [12:58] took [13:01] a prompt templates and few short [13:04] examples, [13:05] assembled a runtime prompt for each [13:08] legacy file and then use that for [13:12] sending that to the LL model. per file. [13:16] This gave us a tremendous improvement on [13:20] code migration quality and also it [13:23] really cut down a manual effort of code [13:26] migrations. [13:27] This is a very good learning for us too. [13:32] Today, our AI agents [13:36] run everywhere, starting from IDE to [13:40] CLIs to cloud thanks to our inbuilt MCP [13:45] connectors. [13:49] Across the 900 users who did the [13:53] framework upgrades and migrations [13:56] using AI agents, we saw a 3x [14:00] productivity gain for framework upgrades [14:04] and more than 80% [14:06] of [14:08] open API spec generation correctness [14:11] accuracy. [14:16] Our agitic platform also hosts [14:20] finance focused agents like travel, [14:25] purchase order, contracts and payroll. [14:32] Uh the travel and purchase order agent [14:35] is one of our second most used no code [14:38] agent [14:40] next to our some of our top tech agents. [14:45] It helps to retrieve live travel and [14:50] purchase order data directly from [14:52] Aribba. [14:54] Also, we are planning to integrate [14:57] Conquer and other fintech data sources [15:00] later on. [15:04] Today, we are getting around 5,000 [15:08] tickets for just travel and purchase [15:11] order related questions. [15:14] annually. [15:16] So, automating some of these fintech [15:19] workflows really gives us good [15:23] productivity for our employees [15:26] similar to what we have seen in tech [15:28] support. [15:32] We also have agents [15:35] related to legal [15:38] for automating compliance and reduction [15:41] workflows. [15:43] These agents [15:45] automatically redact PIA information and [15:48] also flag logo [15:52] unapproved logos [15:54] so that it reduces the review cycle time [15:59] and making us very productive. [16:04] We also have a eiscocovery and document [16:07] retrieval legal agent which retrieves a [16:11] specific set of documents that we need [16:14] for a given legal requirement across [16:18] thousands of internal documents that we [16:20] have. [16:22] This tremendously saved lot of external [16:26] review cost for us and lawyer hours. [16:34] Everything we have seen till now hinges [16:37] onto our internal MCP servers [16:42] built on top of the standards that [16:43] Anthropic provided. [16:47] It's a unified data fabric that all our [16:51] agents use to communicate to the [16:54] different set of available data sources [16:56] that they have. [17:01] These are some of our local and remote [17:04] MCP servers that we use in our agent [17:07] platform. [17:11] Here is a sample configuration of a [17:14] local GitHub MCP server which enables [17:20] code A agent to autonomously do the [17:24] GitHub actions listed here. [17:28] easily so that uh it's it's it's much [17:30] easier for us. [17:34] Here is a remote MCP server [17:36] configuration [17:37] for a API discovery [17:40] MCP server that is customuilt for eBay [17:43] needs. [17:46] That's all I have for today. Thank you [17:48] all for listening the talk. I'm open for [17:51] taking any questions. [17:53] Yeah, good question. So sometimes like I [17:57] think the question is like we have a [17:59] finance agent which retrieves the status [18:01] of the invoice. Is it much easier for [18:04] the employees to just go and check the [18:06] status by themselves? Right? So [18:09] sometimes if you see there are contracts [18:12] and some of these invoices have like [18:15] some kind of sub tickets there like lot [18:17] of surrounding information around that. [18:19] It's not just one status. It's always [18:22] sometimes you want to see the big [18:24] picture of where it is sitting. If it is [18:28] resolved every everybody is happy about [18:30] that, right? If it is kind of in [18:32] progress or if it is like not moving, [18:34] where things are not moving, where is it [18:36] really taking time is what an Agent can [18:40] really absorb that information and give [18:42] a status report. So for example like [18:44] there are there are systems where we [18:46] have a main ticket and there is [18:48] something like a set of like sub kind of [18:52] contracts and invoices and things like [18:53] that. So when you retrieve the main one [18:55] you want to really see how the all the [18:58] sub kind of information also looks like. [19:00] So we do that as a collective [19:03] information as one thing. So yeah the [19:05] question is are you using any vendors or [19:07] are you using your own? So we do both. [19:10] So as you know every company tries to le [19:13] like evaluate different set of vendors [19:15] too. So we use glean as one of our [19:18] solutions and we also have our ebase [19:21] custom framework which kind of helps us [19:24] to really leverage and build solutions [19:27] on top of it because sometimes like with [19:29] MCP servers we need to really build some [19:31] of the authentication capabilities that [19:33] we need for eBay. So we need to kind of [19:36] do internal as well. The question is [19:38] like is it based on just AB testing or [19:40] like use case based it's based on use [19:42] cases. So for example connecting to a [19:46] particular system from enterprise we [19:49] kind of use gleans connectors right and [19:51] sometimes for like lot of our like [19:54] internal data we have our own APIs so [19:57] for that like we use our own custom [19:59] agent so like it's based on use cases [20:01] and where the data source is located [20:03] whether there are capabilities for our [20:06] existing systems to connect to it or can [20:10] can glean or some other systems can [20:12] connect easily to us. It's it's about [20:14] like time to market than like really [20:18] thinking about which solution is the [20:20] best. Uh the question is how are you [20:22] doing the metadata enhancement? So we [20:25] have a set of questions as kind of like [20:27] we use the probing agent to kind of ask [20:30] the set of questions to the agent that [20:32] got onboarded. Even though the [20:34] description of those agents is not [20:37] great, it it has kind of encapsulated a [20:41] functionality, right? So based on that, [20:43] we kind of probe that agent with a set [20:46] of predefined questions and that gives [20:48] us the metadata and that gives us the [20:51] knowledge about what that agent is [20:53] capable of. So are you asking about the [20:55] routing? How are we routing a particular [20:58] question to a particular like say [21:01] invoice things like that? Right. So [21:03] again I I explained there right so it's [21:04] it's about like the if if there is a [21:07] question coming like we kind of do that [21:10] routing based on like okay [21:13] um what to say like we we kind of see [21:16] which particular agent can really answer [21:19] those question like we we have internal [21:21] ranking right so and we kind of select [21:23] the agent based on two-stage process [21:27] like a candidate generation like it's [21:30] it's like you have hundreds of agents [21:32] Initially it was easier and like as we [21:35] go it was much harder for us. So once [21:37] you had the metadata we kind of went [21:40] through the two-stage process like we [21:42] took the top K agents which could answer [21:44] the question and then we do the deep LM [21:48] ranking as well as I explained there [21:49] right so um so based on that we select [21:53] that agent we get the answer and then [21:56] the user will kind of give a feedback [21:57] okay like this is good or bad so we kind [22:00] of collect the feedback as well so it's [22:02] a kind of feedback loop yeah yeah so we [22:05] had specialized agents like the question [22:06] is like do you have agents for like [22:08] production debugging? Yes, we do. Um I [22:11] didn't cover in this slides but [22:13] definitely yeah so we we have ebase [22:16] internal kind of monitoring systems and [22:18] we have built agents that can retrieve [22:21] the logs uh across multiple kind of [22:25] layers and see where the real issue is [22:28] occurring. So yes, we we do have those [22:29] kind of agents and that's helping us [22:31] both in production kind of debugging and [22:33] also like kind of our pipeline [22:35] debuggings like uh say like if uh there [22:38] are like delivery pipelines where kind [22:40] of it fails based on like some test [22:42] failures and things like that. So all [22:44] these are logged in our monitoring [22:47] systems and we do have agents to really [22:49] surface that on the pipelines itself. So [22:52] it's much easier now than like going and [22:55] debugging as when I was a developer like [22:57] 10 years back I had to go through every [23:00] single layer to really find where the [23:02] issue is. Yeah, good question. So how we [23:04] are handling authentication for the MCP [23:06] servers, right? So again like I think [23:08] that's where like we are having some [23:11] eBay custom solution on top of it where [23:13] you can really onboard these kind of [23:15] data sources and APIs and we kind of [23:17] build something like MCP gateway which [23:19] kind of leverages some of this like we [23:22] have our own authentication [23:23] authorization processes inside eBay and [23:26] the gateway kind of encapsulates some of [23:28] this information so that you the users [23:31] can onboard a specific set of data [23:33] sources and we can use