借助 AWS Agent Registry 实现运行时发现，有助于解决 Agent Demo 中常常掩盖的一个痛点。硬编码工具在只有少数几个时表现尚可，但在几十个时性能便开始下降，超过这一数量更会变得难以维护。企业系统暴露了数百个用于定价、技术支持、订单、库存和客户数据的内部 API。在这些系统中，模型可能花费比推理用户请求更多的 Token 去消除工具名称的歧义。每一个新能力都需要在编排器中修改代码、重新部署，并在不同团队之间协调发布，而这些团队往往更希望按照自己的节奏独立发布。

这种模式常见于企业级软件即服务（SaaS）项目中，团队会将庞大的内部 API 接口暴露给基于 Agent 的调用端。随着工具目录的不断扩大，构建期硬编码绑定（Build-time wiring）容易成为瓶颈。一种解决思路是改变编排器访问其工具的方式：不再将每个工具都硬编码编译进 Agent 中，而是让 Agent 在运行时动态发现相关工具。

AWS Agent Registry 是一项用于编目和发现模型上下文协议（Model Context Protocol，MCP）服务器、Agent 和 Agent 技能的托管服务。发布者在其中注册特定协议的描述符和可供搜索的描述信息。在运行时，编排器可以搜索已批准且可发现的记录，并利用返回的端点及描述符内容构建客户端。Registry 搜索结果不会返回该能力的调用凭证或认证方案。

本文将逐步介绍通过重构后的 Python 示例所展示的“发现 → 实例化 → 执行”（Discover → Instantiate → Execute）闭环。该代码通过 Amazon Bedrock AgentCore Gateway（Amazon Bedrock AgentCore 的一项能力）部署了一个订单管理 MCP 服务器，在 AgentCore runtime 上部署了两个 Agent 间交互（Agent-to-Agent，A2A）Agent，以及一个 Registry 和一个编排器。示例目录包含部署脚本、编排器、辅助模块和清理脚本。

方案概览：发现、实例化、执行

本示例中的编排器 Agent 本身并不内置任何关于工具或 Agent 的先验知识。

图 1：在没有 AWS Agent Registry 的情况下（左），端点为硬编码方式，添加新 Agent 意味着修改代码并重新部署。在使用 AWS Agent Registry 的情况下（右），编排器通过语义搜索发现能力，新集成在注册并获得批准后即可立即投入使用

发现（Discover）

编排器向 AWS Agent Registry 数据平面发送自然语言查询。搜索响应包含记录标识、名称、描述、记录类型、状态、版本以及协议描述符（例如 MCP 服务器元数据或 A2A Agent 卡片）。它不包含调用凭证。应用程序必须通过单独受信任的配置路径获取并应用相应的凭证。

实例化（Instantiate）

对于返回的每条记录，编排器会根据其描述符类型构建客户端。在本示例中，已注册的 MCP 服务器代表最初作为目标添加到 Amazon Bedrock AgentCore Gateway 的工具。因此，该 MCP 描述符指向 Gateway 端点。编排器单独获取 Cognito OAuth 访问令牌，并在创建 MCPClient 时使用该令牌。A2A 记录包含一个 Agent 卡片，其 URL 指向 AgentCore 运行时端点。包装器通过 boto3 数据平面客户端调用该运行时，该客户端会使用调用方的 AWS 凭证对请求进行签名。Registry 发现提供的是连接元数据，而非身份验证材料。

执行（Execute）

系统仅使用动态发现的工具构建一个临时的内部 Agent（ephemeral inner agent）。大语言模型（LLM）针对请求选择合适的一个或多个工具，并将结果综合汇总返回给用户。在当前轮次交互结束后，内部 Agent 及其客户端随即被销毁。下一次请求将触发全新的搜索并获取全新的一组工具。

图 2：端到端架构。运行在 Amazon Bedrock AgentCore 运行时上的单一编排器查询 AWS Agent Registry。匹配到的 MCP 服务器通过 Amazon Bedrock AgentCore Gateway 被调用，匹配到的 A2A Agent 则在 Amazon Bedrock AgentCore 运行时上被调用

示例中使用的参考架构包含 AWS Agent Registry、Amazon Bedrock AgentCore Gateway、Amazon Bedrock AgentCore runtime、Amazon Bedrock、Amazon Cognito、AWS Lambda 和 AWS Secrets Manager。

三个演示场景分别针对不同的能力组合测试了该发现闭环。第一个是纯 MCP 调用（订单状态）。第二个是串联 MCP + A2A（定价与折扣）。第三个测试了针对模糊用户意图的纯语义匹配：退货与退款（return and refund），而这两个词并未出现在匹配的 A2A Agent 名称中。

技术实现

文中所附的运行时发现示例代码部署了依赖项、创建并填充了 Registry、验证了发现功能、部署了编排器并运行了三个 Demo。orchestrator_agent.py 包含了针对每个请求的发现闭环。utils.py 用于解析 Registry 描述符并创建 MCP 和 A2A 客户端。cleanup.py 用于清理资源。

1. 注册模型

Registry 记录包含可搜索的描述信息以及特定协议的描述符。示例使用 Agent Registry 控制平面客户端进行 Registry 和记录的生命周期操作，并使用 Agent Registry 数据平面客户端进行运行时发现。

通过手动审批和 IAM 授权创建 Registry：

python registry_client = session.client("agent-registry-control") dp_client = session.client("agent-registry") reg = registry_client.create_registry( name="OrderManagementRegistry", description=( "Registry for Order Management & Customer Service — " "agent discovers tools and agents via semantic search" ), approvalConfiguration={"autoApprovalRules": []}, ) REGISTRY_ARN = reg["registryArn"] REGISTRY_ID = REGISTRY_ARN.split("/")[-1]

创建记录时 recordType 字段是必填项。在此示例中，MCP 服务器使用 recordType="MCP"，基于 A2A 的 Agent 使用 recordType="AGENT"。协议元数据存储在 descriptors 对象的 mcpServer 或 a2aAgentCard 字段下。MCP 描述符包含服务器元数据和工具定义。A2A 描述符包含 Agent 卡片。这些描述符包含连接元数据，但不包含使用者在调用该能力时必须提供的凭证。

构建适用于当前公共 SDK 的 MCP 和 A2A 记录描述符结构：

python

MCP descriptor

mcp_descriptors = { "mcpServer": { "data": json.dumps(server_metadata), "dataSchemaVersion": "2025-12-11", "additionalData": { "tools": { "data": json.dumps({"tools": tool_schemas}), "dataSchemaVersion": "2025-06-18", } }, } }

A2A descriptor

a2a_descriptors = { "a2aAgentCard": { "data": json.dumps(agent_card), "dataSchemaVersion": "0.3", } }

编写描述时应使用面向用户的语言，以便将该能力与相邻记录区分开来。描述符内容提供特定协议的服务器、工具或 Agent 卡片数据。搜索质量应通过具有代表性的查询进行评估。本文并不认为目录的增长会自动改善搜索排序。

使用当前的控制平面数据结构创建 Registry 记录：

python descriptors = ( mcp_descriptors if cfg["protocol"] == "MCP" else a2a_descriptors )

response = registry_client.create_registry_record( registryId=REGISTRY_ID, name=name, description=cfg["description"], recordType=cfg["protocol"], descriptors=descriptors, recordVersion="1.0", ) record_id = response["recordId"]

2. 审批工作流

当 autoApproval 设置为 false 时，新记录必须从 DRAFT 变为 PENDING_APPROVAL，然后再变为 APPROVED。提交和状态更新操作均经过 IAM 授权，从而允许分离发布者和审批者的权限。只有已批准的记录才会由可发现的 Registry 数据平面返回。

两步审批流转换：

python record = registry_client.get_registry_record( registryId=REGISTRY_ID, recordId=record_id, ) if record["status"] == "DRAFT": registry_client.submit_registry_record_for_approval( registryId=REGISTRY_ID, recordId=record_id, ) registry_client.update_registry_record_status( registryId=REGISTRY_ID, recordId=record_id, status="APPROVED", statusReason="Approved", )

3. 发现层

数据平面客户端支持跨可发现记录的混合关键词与语义搜索。最新的方法名称为 search_discoverable_registry_records。返回结果公开了标准化的记录字段和可发现的描述符，但不会暴露能力的调用凭证。

跨协议搜索已批准且可发现的记录：

python response = dp_client.search_discoverable_registry_records( registryIds=[REGISTRY_ARN], searchQuery=query, maxResults=3, ) records = response.get("registryRecords", [])

在示例场景中，针对“退货与退款”的查询检索出了客户支持 Agent（Customer Support Agent），因为其描述捕捉到了该意图。请将此视为一个演示效果，而非声称只要目录规模变大排序质量就会自然提升的一般性结论。

4. 编排器

编排器是一个部署在 Amazon Bedrock AgentCore runtime 上的 Strands Agent。它对外暴露了 discover_and_execute 函数，该函数负责搜索 Registry、解析每个返回的描述符、创建对应的 MCP 或 A2A 客户端，并仅根据这些动态发现的能力构建一个请求生命周期内的临时内部 Agent。

图 3：编排器的单请求流程。外部 Agent 将用户请求转化为 Registry 搜索；内部 Agent 根据搜索结果组装而成，并在当前轮次结束时被销毁

discover_and_execute 的核心逻辑可以在单个代码块中呈现：

编排器的“发现/实例化/执行”闭环：

python @tool def discover_and_execute(request: str) -> str: records = dp_client.search_discoverable_registry_records( registryIds=[REGISTRY_ARN], searchQuery=request, maxResults=5, ).get("registryRecords", [])

Registry returns descriptors, not invocation credentials.

oauth_token = fetch_oauth_token_from_config() 
mcp_clients, a2a_tools = [], [] 
for record in records: 
    metadata = parse_server_metadata(record) 
    if metadata["protocol"] == "MCP": 
        mcp_clients.append( 
            create_mcp_client_from_metadata(metadata, oauth_token) 
        ) 
    elif metadata["protocol"] == "A2A": 
        a2a_tools.append( 
            create_a2a_t

Runtime discovery with AWS Agent Registry can help address a problem that agent demos might hide. Hardcoded tools work fine for a handful, start to degrade at a few dozen, and become unmanageable beyond that. Enterprise systems expose hundreds of internal APIs for pricing, support, orders, inventory, and customer data. In these systems, the model can spend more tokens disambiguating tool names than reasoning about the user’s request. Each new capability requires a code change in the orchestrator, a redeploy, and a coordinated release across teams that would much rather ship on their own cadence.

This pattern can arise across enterprise software as a service (SaaS) engagements where teams expose large internal API surfaces to agentic consumers. Build-time wiring can become a bottleneck as the catalog expands. One approach is to change how the orchestrator accesses its tools: instead of compiling every tool into the agent, the agent can discover relevant tools at runtime.

AWS Agent Registry is a managed service for cataloging and discovering Model Context Protocol (MCP) servers, agents, and agent skills. Publishers register protocol-specific descriptors and searchable descriptions. At runtime, an orchestrator can search approved, discoverable records and use the returned endpoint and descriptor content to construct a client. Registry search results do not return the capability’s invocation credentials or authentication scheme.

This post walks through the Discover → Instantiate → Execute loop demonstrated by the refactored Python sample. The code deploys an order-management MCP server through Amazon Bedrock AgentCore Gateway, a capability of Amazon Bedrock AgentCore, two agent-to-agent (A2A) agents on AgentCore runtime, a Registry, and an orchestrator. The sample directory contains the deployment script, orchestrator, helper modules, and cleanup script.

Solution overview: discover, instantiate, execute

The orchestrator agent in this sample has no built-in knowledge of tools or agents.

Figure 1: Without AWS Agent Registry (left), endpoints are hardcoded and adding a new agent means code changes plus redeployment. With AWS Agent Registry (right), the orchestrator discovers capabilities through semantic search and new integrations are usable after registration and approval

Discover

The orchestrator sends a natural-language query to the AWS Agent Registry data plane. The search response includes record identity, name, description, record type, status, version, and protocol descriptors such as MCP server metadata or an A2A agent card. It does not include invocation credentials. The application must obtain and apply the appropriate credentials through a separate, trusted configuration path.

Instantiate

For each returned record, the orchestrator constructs a client from the descriptor type. In this sample, the registered MCP server represents tools that were first added as targets to Amazon Bedrock AgentCore Gateway. The MCP descriptor therefore points to the Gateway endpoint. The orchestrator fetches a Cognito OAuth access token separately and uses it when creating the MCPClient. A2A records contain an agent card whose URL identifies an AgentCore runtime endpoint. The wrapper invokes that runtime through the boto3 data-plane client, which signs the request with the caller’s AWS credentials. Registry discovery supplies connection metadata, not the authentication material.

Execute

An ephemeral inner agent is built with only the dynamically-discovered tools. The large language model (LLM) picks the right one(s) for the request, and the result is synthesized back to the user. After the turn finishes, the inner agent and its clients are torn down. The next request gets a fresh search and a fresh tool set.

Figure 2: End-to-end architecture. A single orchestrator on Amazon Bedrock AgentCore runtime queries AWS Agent Registry. Matched MCP servers are invoked through Amazon Bedrock AgentCore Gateway, and matched A2A agents are invoked on Amazon Bedrock AgentCore runtime

The reference architecture used in the sample includes AWS Agent Registry, Amazon Bedrock AgentCore Gateway, Amazon Bedrock AgentCore runtime, Amazon Bedrock, Amazon Cognito, AWS Lambda, and AWS Secrets Manager.

Three demo scenarios exercise the discovery loop with different capability combinations. The first is an MCP-only call (order status). The second chains MCP + A2A (pricing and discounts). The third tests a pure semantic match against ambiguous user intent: return and refund, where those words don’t appear in the matched A2A agent’s name.

Technical implementation

The linked runtime-discovery sample deploys the dependencies, creates and populates the Registry, verifies discovery, deploys the orchestrator, and runs three demos. orchestrator_agent.py contains the per-request discovery loop. utils.py parses Registry descriptors and creates MCP and A2A clients. cleanup.py removes resources.

1. The registration model

A Registry record contains a searchable description plus a protocol-specific descriptor. The sample uses the Agent Registry control-plane client for Registry and record lifecycle operations and the Agent Registry data-plane client for runtime discovery.

Creating a Registry with manual approval and IAM authorization.

registry_client = session.client("agent-registry-control")
dp_client = session.client("agent-registry")
reg = registry_client.create_registry(
    name="OrderManagementRegistry",
    description=(
        "Registry for Order Management & Customer Service — "
        "agent discovers tools and agents via semantic search"
    ),
    approvalConfiguration={"autoApprovalRules": []},
)
REGISTRY_ARN = reg["registryArn"]
REGISTRY_ID = REGISTRY_ARN.split("/")[-1]

The recordType field is required when creating a record. In this sample, MCP servers use recordType="MCP" and A2A-backed agents use recordType="AGENT". Protocol metadata is stored under mcpServer or a2aAgentCard in the descriptors object. An MCP descriptor contains server metadata and tool definitions. An A2A descriptor contains the agent card. The descriptors contain connection metadata but not the credentials that a consumer must present when invoking the capability.

Building current public-SDK descriptor shapes for MCP and A2A records.

# MCP descriptor
mcp_descriptors = {
    "mcpServer": {
        "data": json.dumps(server_metadata),
        "dataSchemaVersion": "2025-12-11",
        "additionalData": {
            "tools": {
                "data": json.dumps({"tools": tool_schemas}),
                "dataSchemaVersion": "2025-06-18",
            }
        },
    }
}

# A2A descriptor
a2a_descriptors = {
    "a2aAgentCard": {
        "data": json.dumps(agent_card),
        "dataSchemaVersion": "0.3",
    }
}

Write descriptions in user-facing language that distinguishes the capability from neighboring records. Descriptor content supplies the protocol-specific server, tool, or agent-card data. Search quality should be evaluated with representative queries. This post does not assume that catalog growth automatically improves ranking.

Creating a Registry record with the current control-plane shape.

descriptors = (
    mcp_descriptors
    if cfg["protocol"] == "MCP"
    else a2a_descriptors
)

response = registry_client.create_registry_record(
    registryId=REGISTRY_ID,
    name=name,
    description=cfg["description"],
    recordType=cfg["protocol"],
    descriptors=descriptors,
    recordVersion="1.0",
)
record_id = response["recordId"]

2. Approval workflow

With autoApproval set to false, a new record must move from DRAFT to PENDING_APPROVAL and then APPROVED. The submit and status-update actions are IAM-authorized, allowing publisher and approver permissions to be separated. Only approved records are returned by the discoverable Registry data plane.

The two-step approval transition.

record = registry_client.get_registry_record(
    registryId=REGISTRY_ID,
    recordId=record_id,
)
if record["status"] == "DRAFT":
    registry_client.submit_registry_record_for_approval(
        registryId=REGISTRY_ID,
        recordId=record_id,
    )
    registry_client.update_registry_record_status(
        registryId=REGISTRY_ID,
        recordId=record_id,
        status="APPROVED",
        statusReason="Approved",
    )

3. The discovery layer

The data-plane client supports hybrid keyword and semantic search across discoverable records. The latest method name is search_discoverable_registry_records. Results expose normalized record fields and discoverable descriptors. They don’t expose the capability’s invocation credentials.

Searching approved, discoverable records across protocols.

response = dp_client.search_discoverable_registry_records(
    registryIds=[REGISTRY_ARN],
    searchQuery=query,
    maxResults=3,
)
records = response.get("registryRecords", [])

In the sample scenario, a return-and-refund query retrieves the Customer Support Agent because its description captures that intent. Treat this as a demo result, not a general claim that ranking improves merely because the catalog is larger.

4. The orchestrator

The orchestrator is a Strands agent deployed to Amazon Bedrock AgentCore runtime. It exposes discover_and_execute, which searches the Registry, parses each returned descriptor, creates the corresponding MCP or A2A client, and builds a request-scoped inner agent from only those discovered capabilities.

Figure 3: The orchestrator’s per-request flow. The outer agent translates the user request into a Registry search. The inner agent is assembled from the search results and torn down at the end of the turn

The core of discover_and_execute fits in a single code block:

The orchestrator’s discover/instantiate/execute loop.

​​​@tool 
 def discover_and_execute(request: str) -> str: 
     records = dp_client.search_discoverable_registry_records( 
         registryIds=[REGISTRY_ARN], 
         searchQuery=request, 
         maxResults=5, 
     ).get("registryRecords", []) 
  
    # Registry returns descriptors, not invocation credentials. 
     oauth_token = fetch_oauth_token_from_config() 
     mcp_clients, a2a_tools = [], [] 
     for record in records: 
         metadata = parse_server_metadata(record) 
         if metadata["protocol"] == "MCP": 
             mcp_clients.append( 
                 create_mcp_client_from_metadata(metadata, oauth_token) 
             ) 
         elif metadata["protocol"] == "A2A": 
             a2a_tools.append( 
                 create_a2a_tool_from_metadata(metadata, session, REGION) 
             ) 
  
    return run_request_scoped_agent(request, mcp_clients, a2a_tools)​​ 

​​model = BedrockModel(model_id=MODEL_ID, region_name=REGION) 
​    started_clients = [] 
​    try: 
​        mcp_tools = [] 
​        for c in mcp_clients: 
​            c.start() 
​            started_clients.append(c) 
​            mcp_tools.extend(c.list_tools_sync()) 

​ 	    ##agent compiled in realtime within agent 
​        sub_agent = Agent( 
​            model=model, 
​            tools=mcp_tools + a2a_tools, 
​            system_prompt=( 
​                "You are an Order Management & Customer Service assistant. " 
​                "Use the RIGHT tool for each request:\\n" 
​                "- Order lookups, status, cancellations, address changes: use MCP tools\\n" 
​                "- Pricing, discounts, promo codes: use the pricing_agent tool\\n" 
​                "- Returns, refunds, complaints, escalations: use the customer_support_agent tool\\n" 
​                "Always use the most specific tool for the task." 
​            ), 
​        ) 
​        return str(sub_agent(request)) 
​    finally: 
​        for c in started_clients: 
​            try: 
​                c.stop() 
​            except Exception: 
​                pass​ 

The sample fans out several search queries to improve recall for its order-management domain, deduplicates records, and tears down MCP clients after the request. That fan-out is a sample-specific orchestration choice, not a Registry requirement. Authentication remains outside discovery: the Gateway OAuth token is obtained from Cognito configuration and Secrets Manager, whereas A2A runtime calls are signed through the boto3 session.

5. Running the three demos

Each demo exercises a different shape of the discovery loop.

Demo 1: Order status (MCP only)

A request that resolves to a single MCP tool call.

result = invoke_orchestrator(
    "What is the current status and tracking info for order 123?",
    agentcore_client, orchestrator_arn,
)

The Registry returns the order management MCP server. The orchestrator calls get_order_status through Gateway, the LLM synthesizes a human-readable response, and the inner agent terminates. No A2A involvement on this turn.

Demo 2: Pricing and discounts (MCP + A2A)

A request that resolves to a multi-protocol chain.

result = invoke_orchestrator(
    "Order 123 has 2x Widget Pro at $99.98. What discount tiers or "
    "promo codes can reduce the price?",
    agentcore_client, orchestrator_arn,
)

The Registry returns the order management MCP server and the pricing A2A agent: two protocols, one natural-language query. The LLM calls get_order_status to fetch line items, then calls the pricing agent on runtime for discount analysis, then synthesizes a single recommendation.

Demo 3: Return and refund (semantic match)

A request whose intent is not literally present in any tool name.

result = invoke_orchestrator(
    "I want to return order 789 (Premium Headphones, delivered "
    "March 10). Am I eligible for a return and what is the refund "
    "amount?",
    agentcore_client, orchestrator_arn,
)

This demo shows the value of semantic discovery. The phrase ‘return refund’ doesn’t appear in the Customer Support Agent’s registered name. The hybrid search ranks it highly because its description captures the intent. Without Registry, the orchestrator would need hardcoded knowledge of which agent handles returns.

6. Observability

Instrument the discovery and invocation path using Amazon Bedrock AgentCore Observability and Amazon CloudWatch where appropriate. Useful signals include Registry search success and failure, selected record identifiers, client-construction errors, downstream invocation outcomes, end-to-end trace correlation, and application errors. The sample grants Amazon CloudWatch Logs permissions, but it doesn’t create custom metrics or dashboards. Production teams should define the traces, logs, and alerts required for their operating model. Production deployments should also apply Amazon Bedrock Guardrails as a standard control on agent responses.

What teams gain from governed runtime discovery

After the discovery loop is in place, several capabilities that were previously coupled to orchestrator releases become independent.

• Decoupled publishing. Teams can deploy and register their own MCP servers, agents, and skills. Approval policy determines when a published record becomes available to consumers.
• No orchestrator code change for newly approved records. In this pattern, adding a compatible, approved Registry record doesn’t require adding a tool-specific import or endpoint to the orchestrator. Changes to protocols, authentication setup, or orchestration policy can still require code or configuration updates.
• Governed discovery. With manual approval, only reviewed and approved records become discoverable. IAM permissions can separate record publishers from approvers.
• Separated authentication. Registry authorization can use IAM or custom JWT. Capability invocation authentication is separate: the sample uses Cognito OAuth for Gateway and Boto3/IAM signing for AgentCore runtime. Search results don’t return those credentials.
• Catalog search instead of prompt stuffing. With hybrid Registry search, the orchestrator retrieves a small candidate set instead of placing the full catalog in the model context. Search quality depends on descriptions, descriptor quality, query design, and evaluation.

When not to use runtime discovery

Runtime discovery is not necessary for every workload. Two patterns can still favor explicit build-time wiring:

• Small, stable catalogs. If the complete capability set is small and changes rarely, explicit build-time wiring might be simpler and avoid an additional discovery request.
• Fixed pipelines. When the same capabilities always run in a fixed order, implementing them as a deterministic flow is more straightforward and keeps tracing focused.

Conclusion

Discovery of assets from Registry at runtime makes the orchestrator less dependent on a fixed catalog. Against an AWS Agent Registry, it can search approved capabilities with hybrid semantic and keyword search, parse MCP or A2A descriptors, and instantiate request-scoped clients. Governance determines what is discoverable. Authentication remains an explicit concern for the Registry and each invoked capability.

AWS Agent Registry is generally available with capabilities that extend beyond this single-account sample:

Run the runtime-discovery sample, then register one compatible MCP server or agent of your own. Confirm that its descriptor, approval state, authentication path, and search behavior match your production requirements.

Learn more

---

About the authors

Vibhu Pareek

Vibhu is a Sr. Solutions Architect at AWS. Since 2016, he has guided customers in cloud adoption using well-architected, repeatable patterns. With his specialization in databases, data analytics, and AI, he thrives on transforming complex challenges into innovative solutions. Outside work, he enjoys short treks and sports like badminton, football, and swimming.

Shubham Gupta

Shubham is a Solutions Architect at AWS based in Bengaluru, India, supporting independent software vendors (ISVs). He works with engineering and leadership teams to design, build, and run their products on AWS, from first architecture to production, with a deep focus on generative AI and resilience at scale. Outside of work, Shubham is an avid hiker who brings the same preparation and persistence from the trail to building systems that last.