Building Agents at Cloud Scale — Antje Barth, AWS

What would it take to reinvent everyday customer experiences with AI—and build experiences that were not possible before? Antje Barth opens with that problem at Amazon’s scale. Barth reports more than 1,000 generative AI applications built or in development across Amazon, spanning inventory forecasting, delivery routing, shopping, and home interactions. These are applications at different stages of development, not a count of deployed agents. She introduces the reimagined Alexa+ as what she describes as the largest integration of services, agentic capabilities, and LLMs known to her team.

The promotional montage makes the coordination problem concrete: a child’s birthday party conflicts with picking up Grandma at the airport. Alexa notices the conflict and offers to book her a ride. The next exchange moves from knowing that Billie Eilish will be in town to offering a notification when tickets become available. These illustrated experiences connect information to a proposed action; the montage is not a live verification of those bookings or notifications.

A vacation request then accumulates constraints across several turns: somewhere nearby, with a beach and nice weather. Alexa recommends Santa Barbara, suggests a restaurant, answers a question about the destination, and offers to book a catamaran tour when whale watching comes up. The useful behavior is the continuity: new questions and preferences become part of the same developing task.

The remaining scenes broaden the kinds of context an assistant might use. It gives the next repair instruction, responds to a question about getting bangs, receives a request for a baby-photo slideshow, and recalls that the repair needs two-inch washers. It reports an approaching Uber and, when asked whether Mozart the dog has been outside, says it checked the cameras. Together, these scenes span conversation, remembered details, media, service status, and information from household devices.

Barth reports more than 600 million Alexa devices worldwide. That is the Alexa installed base, not Alexa+ adoption. To explain the architecture behind the new experience, she describes hundreds of specialized expert systems: groups of capabilities, APIs, and instructions organized to accomplish a particular task. Those experts orchestrate across tens of thousands of partner services and devices, according to Barth. The assistant’s broad surface area is supported by task-specific capabilities working together.

Specialization makes the cloud-scale question a service-design question. Once capabilities are separated, the next problem is how to connect and operate them. Barth’s transition from web services to agentic services rests on the idea that many underlying principles remain useful, whether the application serves a device fleet, adds AI to enterprise software, or helps a startup scale its first product. The rest of the demonstration progressively exposes those connections: first an agent calling a documentation tool, then an SDK connecting models and tools, and finally a remotely hosted tool service.

Amazon Q Developer brings the same pattern into a developer’s terminal. Barth introduces its CLI agent as an assistant for natural-language questions, debugging, and reading or writing files. In the demonstration, she asks what it knows about Amazon Bedrock. The significant step is what happens between the question and the answer: Q uses its MCP integration to reach the AWS documentation team’s server.

The interaction has a visible sequence:

1. Select a tool. Q identifies a documentation tool available through the MCP server.
2. Request permission. The terminal presents the proposed tool use, and Barth approves it.
3. Use the retrieved information. Q returns an answer grounded in official AWS documentation.

The tool connection supplies the external information; the permission step lets the user approve its use before execution.

Barth then asks the audience to guess how long the AWS team needed to build and ship the service: two months, three weeks, or half a year. Barth says the team built and shipped this agentic service within three weeks. Her point is delivery speed as a competitive advantage, and the engineering question becomes how to make that pace repeatable for other teams.

The development approach behind that speed gives the model responsibility for deciding, planning, reasoning, and taking actions. Developers specify what the agent should accomplish and which tools it can use, instead of prescribing every step. Strands Agents packages this approach as an open-source Python SDK. The model directs the work; the developer supplies the task and available capabilities.

Even the name follows that pairing. Barth says an AI chose “Strands,” using the two strands of DNA as an analogy for connecting a model and its tools. The practical workflow is similarly small: define a prompt and tools in code, test the agent locally, and deploy it when ready.

After installing strands-agents and strands-agents-tools, the basic Python structure is an import, a tool list, and an agent invocation. For example, a calculator gives the model a concrete capability to call:

from strands import Agent
from strands_tools import calculator

agent = Agent(tools=[calculator])
agent("What is 17 multiplied by 23? Use the calculator.")

The same structure can support a single question or become the starting point for a more involved workflow. Adding a tool makes a capability available; the model determines how to use it in response to the task.

In the configuration shown in the talk, Amazon Bedrock is the default provider and the model is Claude 3.7 Sonnet. That historical configuration does not restrict the SDK to AWS. Barth describes several routes for choosing a model:

The agent’s prompt-and-tools structure stays central while the provider determines which model performs the reasoning.

Barth describes more than 20 prebuilt tools in Strands at the time of the talk. They cover ordinary operations such as file manipulation, API calls, and AWS service integration, as well as memory and retrieval-augmented generation. One tool, retrieve, performs semantic search over a knowledge base. Its use need not be limited to finding documents for an answer: it can help the agent find other tools.

Barth reports an internal AWS agent managing more than 6,000 tools. Placing the entire catalog in one model context makes the model’s selection problem difficult. The team instead stores tool descriptions in a knowledge base and uses retrieval to narrow the candidate set:

1. Index descriptions. Keep the searchable tool catalog in a knowledge base.
2. Search for the current task. Use retrieve to find relevant tools.
3. Load the subset. Put only those tools into the model context.
4. Choose an action. Let the model decide which retrieved tool to use.

This separates finding plausible capabilities from selecting the next action. The catalog size describes the scope of the internal system; Barth supplies no tool-selection accuracy or latency measurement for this approach.

The surrounding tool set also reaches beyond text and single-agent actions:

• Multimodal work: support spans images, video, and audio.
• Additional reasoning: a tool can prompt more thinking and deeper reasoning.
• Agent collaboration: prebuilt tools support graph-based workflows and swarms of sub-agents.

These extend what an agent can do without changing the basic model-and-tools starting point.

Strands’ native Model Context Protocol (MCP) integration makes capabilities exposed by MCP servers available as agent tools. Barth describes agent-to-agent protocol support, A2A, as forthcoming at this point in the SDK’s history. For AWS-specific capabilities, she points to the awslabs/mcp repository and its growing collection of server implementations.

The cloud deployment example begins with a local server. As Barth explains, MCP’s initial standard-I/O setup connected clients to locally running tools. Her Python example uses FastMCP: create a server, decorate a function as a tool, and accept a parameter describing how many sides the die should have. A minimal implementation of that mechanism is:

import random

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("dice")


@mcp.tool()
def roll_dice(sides: int) -> int:
    """Roll one die with the requested number of sides."""
    if sides < 2:
        raise ValueError("A die must have at least two sides.")
    return random.randint(1, sides)


if __name__ == "__main__":
    mcp.run(transport="stdio")

The function implements the action, while the decorator exposes it as an MCP tool. The sides argument makes the same tool useful for different dice.

A D20 is a 20-sided die, familiar to Dungeons & Dragons players and new to Barth. She holds one up and credits Mike Chambers with building the demonstration. That detail becomes the test input later: the agent will need to turn a request for a D20 roll into a tool call using 20 sides.

To decouple the client from a locally running server, Barth moves the MCP service to AWS Lambda and connects over Streamable HTTP. Lambda functions sit behind a gateway, so the client can reach the tools remotely. The demonstration adds an authorizer for access control and stores session data in DynamoDB; Cognito is mentioned as another option for the authorization integration.

The architectural change is small enough to compare directly:

The dice operation remains the useful capability. Hosting, access control, and session storage move into the service infrastructure around it.

The walkthrough first introduces an MCP Lambda handler with a small Hello World tool. The tool still uses a decorator; the Lambda entry point forwards the invocation to the MCP server. Barth then shows the fuller server implementation: add the DynamoDB session table, define the dice tool, and use the same forwarding step at the end of the Lambda handler. The adaptation connects the Lambda invocation model to the MCP server rather than requiring each tool to implement that connection itself.

Deployment uses the existing AWS SAM workflow. Once the deployment returns an API Gateway URL, the client can discover and use the remote tools:

1. Configure the connection. Give the Strands MCP integration the API Gateway URL.
2. Supply authorization. Attach the bearer token used in the demonstration.
3. Discover tools. List the tools exposed by the remote MCP server.
4. Construct the agent. Pass the discovered tools to the Strands agent.

Barth explicitly describes the bearer-token arrangement as a simple concept demonstration; a more robust authorization integration remains part of building the service around it.

The final request is to roll a D20. The tool activates, and the demonstrated D20 roll returns seven. This completes the path from natural-language input through tool selection to remote execution and a returned result. The value of the example is its small surface area: once the tool runs on Lambda, the same integration pattern can expose existing Lambda-compatible application code and AWS capabilities to an agent.

With existing AWS applications reachable through agent tools, Barth turns to the next connection: agents talking to other agents. She presents open protocols as the basis for that interoperability, says AWS has joined the MCP steering committee, and describes contributions to code and protocol development. She also points to an AWS open-source blog series following that work.

The closing vision moves from an individual remote tool to a personal agent coordinating other agents. Quoting her colleague Danielle, Barth says, “The atomic unit of all digital interactions will be an agent call.” The accompanying concept shows a personal agent connecting to an agent store so that multiple agents can accomplish tasks together. The artwork explicitly labels this as a concept, not a real product. It leaves the demonstrated service boundary intact—an agent reaching a separately hosted capability—while imagining that the capability on the other side can itself be an agent.