Agent-to-Agent Collaboration: Using Amazon Nova 2 Lite and Amazon Nova Act for Multi-Agent Systems

My first attempt at building a travel planning agent looked exactly like the initial prototype: a large model, a few tools, and a long system prompt. This worked well until the complexity of the real world emerged. Flights came from a clean API, hotels lagged behind the changing web UI, and the model kept mixing up instructions, forgetting context, or taking confusing steps. That’s when it became clear: Single agent was not the solution, it was the obstacle.

Finding a solution means dividing the work rather than trying to fix the signal. This post explains how agent-to-agent collaboration on Amazon Bedrock works in practice, using Amazon Nova 2 Lite to plan and Amazon Nova Act For browser interactions, transforming a fragile single-agent setup into a predictable multi-agent system.

solution overview

The system is built as a small group of agents that work together, as shown in the following diagram. An agent plans the work and talks to the user. Other agents handle specific tasks, such as flight searches or hotel searches. They communicate through simple messages, so each agent stays focused and it’s easy to reason about the task.

When I looked at where the single agent design broke down, the pattern was clear: The agent wasn’t struggling because the task was hard, it was struggling because the tasks were fundamentally different. Flight search is structured and predictable. Hotel search is cluttered, visual and full of dynamic elements. Forcing a model to connect the two was like asking the same engineer to write a backend API and manually click on a website in real time. And the more I tried to patch it with prompts, more tools, and more fallback logic, the worse it got. When a single agent is burdened with too many responsibilities, it slows down, loses context, makes inconsistent choices and ultimately collapses under its own weight. The problem was with the design, and trying to solve it through hints wouldn’t work. The solution was to divide the work among three agents and let each focus on a single responsibility. The travel agent took over the user’s intention and planning. The flight agent spoke to the structured flight API. And hotel agents used browser automation to navigate to actual hotel sites. Instead of an overloaded model, each agent did one thing well — and they coordinated through a simple message-passing layer, so the workflow still felt seamless from the outside. The job of each agent was very clear. The travel agent was the coordinator who interpreted the request, broke it down into steps, and decided which agent should run each part. Flight Agent focused on fully structured API calls where the data was predictable. And Hotel Agent took care of the messy parts: navigating web pages, handling dynamic layouts, and extracting hotel details from real sites. Isolating the systems in this way kept the logic clean and prevented single agents from becoming overloaded again.

To implement this setup, agents needed an easy way to talk to each other. The travel agent had to send an explicit request to the flight agent, wait for the results, and then trigger the hotel agent with the next step. We didn’t need anything fancy, just a lightweight message format that agents could pass along so everyone knew what to do next. When that communication loop was in place, the entire workflow finally felt coordinated instead of chaotic pages with dynamic layouts and no public API. Using the same agent to handle both often increases the risk of equipment overload, confused instructions, and hallucinations.

Implementation Overview

Now that the architecture was clear, it was time to actually build the system. This is where the tools behind each agent ultimately come in handy. Both Travel Agent and Flight Agent use Amazon Nova 2 Lite for logic and planning, and Flight Agent also calls a structured Flight API to retrieve the actual data. Hotel Agent relies on Amazon Nova Act to automate browser interactions when no API exists. The three agents communicate through a direct agent-to-agent (A2A) message-passing pattern, where agents exchange short, structured messages to coordinate their work, which keeps the workflow predictable, even if each agent runs in a different execution environment. In a multi-agent system, expertise as well as coordination is equally important. Agents need a structured, predictable way to exchange goals, share status, and trigger behavior, especially when collaborating on a task like trip planning.

Travel Agent Implementation (Amazon Nova 2 Lite)

The travel agent is the orchestrator of the entire workflow. It receives the user’s request, interprets the intent using the Amazon Nova 2 Lite, and decides which agent to call next. The Nova 2 Lite is doing the heavy reasoning here – it breaks the input into steps, identifies when to trigger the flight agent or hotel agent, and keeps track of the overall plan. Because the travel agent does not touch external systems directly, his only job is to think clearly and route messages using A2A.

The following code example is a simplified version of how to initialize a travel agent:

    # Initialize A2A client tools
    provider = A2AClientToolProvider(known_agent_urls=(
        "http://localhost:9000",  # Hotel Booking Expert (NovaAct)
        "http://localhost:9001"   # Flight Booking Expert
    ))
    bedrock_model = BedrockModel(
    model_id="global.amazon.nova-2-lite-v1:0",
    region_name="us-east-1",
)
    
    # Create client agent with A2A tools
    client_agent = Agent(
        name="Travel Client",
        model=bedrock_model,
        description="Client agent that coordinates travel planning using specialized      A2A agents",
        tools=provider.tools,
        system_prompt="""You are an autonomous travel planning agent. You MUST take action immediately without asking for confirmation.

In practice, travel agents receive the same natural language requests, such as “Find me flights from NYC to Tokyo by July 10th and a hotel by July 15th.” From there, Amazon Nova 2 Lite does the heavy reasoning: It identifies that two different tasks are needed, formulates a clear plan, sends a message to the flight agent, waits for the results, and then triggers the hotel agent with the next instruction. Finally, it combines both outputs into a coherent response. This keeps the orchestration logic clean and flowing. The Nova 2 Lite effectively acts as the brain of the workflow, and specialized agents handle the actual execution.

Flight Agent Implementation (Amazon Nova 2 Lite and API)

The flight agent’s job is very simple: turning a structured request into actual flight options. It uses Amazon Nova 2 Lite for the lightweight logic needed to validate input, format the search, and decide whether to call the Live Flights API or fall back to mock data when credentials are not available. Once the API call is made, the agent returns a clean, predictable JSON response to the travel agent via A2A.

The following code example shows a simplified version of the flight search tool. The full implementation, including OAuth, fallback logic, and AirPort code handling, is available in Agent to Agent with Amazon Nova GitHub repository:

@tool
def search_flights(origin: str, destination: str, departure_date: str, return_date: Optional(str) = None) -> str:
    # Nova 2 Lite handles the reasoning around which path to take
    if amadeus_configured():
        return _search_amadeus_flights(
            origin=origin,
            destination=destination,
            departure_date=departure_date,
            return_date=return_date
        )
    else:
        # Local development fallback
        return _search_flights_web(origin, destination, departure_date, return_date)
{
  "flights": (
    { "flight_number": "DL456", "price": 520, "duration": "14h 30m" },
    { "flight_number": "JL701", "price": 545, "duration": "13h 50m" }
  ),
  "source": "Amadeus API"
}

Because this agent deals with clean, structured data, the logic load is light and the work of Amazon Nova 2 Lite is mostly about choosing the right execution path and normalizing the output. This keeps the entire pipeline predictable and avoids embedding API specific logic inside the travel agent.

Hotel Agent Implementation (Amazon Nova Act)

Hotels are nothing like flights. There’s no clean API you can call, and most booking sites load content in ways that vary from visit to visit. This is where Amazon Nova comes into play. The hotel agent uses Nova Act to control the actual browser and follow natural language instructions. Instead of writing delicate scraping code, the agent tells Nova Act what it needs, and Nova Act takes care of the browsing and returning structured data.

Here’s a condensed version of the tool:

@tool
def search_hotels(location: str, checkin_date: str, nights: int = 2) -> str:
    with NovaAct() as nova:
        result = nova.act(
            f"Search for hotels in {location} from {checkin_date} for {nights} nights. "
            f"Return the top 3 listings with name, price, and rating.",
            schema=HotelSearchResults.model_json_schema()
        )
        return json.dumps(result)

And here’s a simplified example of the reaction. The full code, including scrolling, cookie banners, and other details, is here Agent to Agent with Amazon Nova GitHub repo:

{
  "hotels": (
    { "name": "Shinjuku Grand", "price": "$180", "rating": 4.3 },
    { "name": "Park Tower Tokyo", "price": "$210", "rating": 4.6 },
    { "name": "Hotel Blossom", "price": "$155", "rating": 4.0 }
  ),
  "source": "Anycompany.com via Nova Act"
}

Using Amazon Nova Act saves the hotel agent from breaking every time the site layout changes. And by using it, you can avoid writing your own scraping or DOM parsing logic.

A2A message flow (how agents talk)

Now that each agent knows what it is responsible for, they need a way to talk to each other. Before a travel agent starts sending actual work, he first calls his A2A endpoint to check if other agents are ready. It also loads the list of devices displayed by each agent so that the Nova 2 Lite knows what capabilities are available. Once this is done, the flow becomes straight. The travel agent sends a message to the flight agent with the required fields. When the flight agent is done, it sends a message back. Then the travel agent sends the next message to the hotel agent. Each message is a small JSON object that contains things like the action, input data, and where to send the response.

Run end-to-end example

Here’s what a perfect run looks like. The user sends a single request to the travel agent:

Please arrange travel for one person from NYC to Paris on December 6, 2025, including a two night stay in Paris.

Travel Agent -> Flight Agent:
1. The travel agent extracts the flight portion of the request and sends it to the flight agent.
2. Flight Agent returns three direct, cheap flights from JFK to Paris, including airline, time, price and duration.
Travel Agent -> Hotel Agent:
1. The travel agent sends part of the hotel request to the hotel agent.
2. The hotel agent, using Nova Act, checks Paris hotels and returns the top three choices with names, prices, and brief notes.
End result for user
1. The travel agent combines both responses and sends back a clear summary that includes:
recommended flight
Recommended Hotels
Check-in and check-out dates
Value
A question asking what to book

conclusion

Creating this travel planner with three small agents became much easier to manage than one large agent. Each agent focuses on one task, and Amazon Nova 2 Lite handles the thinking needed to move the task from one step to the next. The Amazon Nova Act covers parts that don’t have an API, like hotel search, without writing scraping code. A2A message flow keeps everything connected but still straightforward.

This setup is not related to travel. The same idea can be used in tasks that combine different skills: let one agent plan the work, let others do the work they’re good at, and send short messages between them. This makes the system easier to change and explain.

If you want to try it yourself, the full code and examples are here Agent to Agent with Amazon Nova GitHub repo.

About the authors

yoav fishman is an AWS Solutions Architect with 12 years of cloud and engineering experience, specializing in GenAI, Agentic AI, and Cybersecurity. He guides startups from early stage to development, building secure, scalable architectures and implementing agent AI flows that drive business impact.

Elior Farajpur is a Solutions Architect at AWS with 7 years of experience in the cloud world and a passion for AI and cloud technologies. He helps organizations design innovative cloud-based solutions that drive real business value.

dan kolodny is an AWS Solutions Architect specializing in big data, analytics, and GenAI. He is passionate about helping customers adopt best practices, discover insights from their data, and adopt new GenAI technologies.