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 most early prototypes: one big model, a few tools, and a long system prompt. It worked fine until the moment real-world complexity showed up. Flights came from a clean API, hotels lived behind a shifting web UI, and the model kept mixing instructions, forgetting context, or hallucinating steps. That’s when it became obvious: the single agent wasn’t the solution, it was the bottleneck.

Finding a fix meant splitting the work instead of trying to fix the prompting. This post walks through how agent-to-agent collaboration on Amazon Bedrock works in practice, using Amazon Nova 2 Lite for planning and Amazon Nova Act for browser interaction, to turn 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. One agent plans the work and talks to the user. The other agents handle specific tasks, such as flight search or hotel search. They communicate through simple messages, so each agent stays focused and the task is straightforward to reason about.

When I saw where the single agent design broke, the pattern was obvious: 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 messy, visual, and full of dynamic elements. Forcing one model to juggle both was like asking the same engineer to write backend APIs and also manually click through 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 overloaded with too many responsibilities, it slows down, loses context, makes inconsistent choices, and eventually collapses under its own weight. The problem was with the design, and trying to address it through prompting wouldn’t work. The fix was to split the work across three agents and let each one focus on a single responsibility. The Travel Agent handled user intent and planning. The Flight Agent talked to the structured flight API. And the Hotel Agent used browser automation to navigate real hotel sites. Instead of one 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. Each agent had a very clear job. The Travel Agent was the coordinator that interpreted the request, broke it into steps, and decided which agent should run each part. The Flight Agent focused entirely on structured API calls where the data was predictable. And the Hotel Agent took care of the messy parts: navigating web pages, handling dynamic layouts, and extracting hotel details from real sites. Separating the system this way kept the logic clean and prevented single agents from becoming overloaded again.

To make this setup work, the agents needed a simple way to talk to each other. The Travel Agent had to send a clear 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, only a lightweight message format the agents could pass around so each one knew what to do next. When that communication loop was in place, the whole workflow finally felt coordinated instead of chaotic pages with dynamic layouts and no public APIs. Using the same agent to handle both often leads to tool overload, tangled instructions, and higher risk of 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 finally come into play. Both the Travel Agent and the Flight Agent use Amazon Nova 2 Lite for reasoning and planning, and the Flight Agent also calls a structured flight API to retrieve real data. The Hotel Agent relies on Amazon Nova Act to automate browser interactions when no API exists. The three agents communicate through a straightforward agent-to-agent (A2A) message-passing pattern, where agents exchange small, structured messages to coordinate their work, which keeps the workflow predictable even as each agent runs in a different execution environment. In a multi-agent system, coordination is equally as important as specialization. Agents need a structured, predictable way to exchange goals, share state, and trigger behaviors especially when collaborating on a task like planning a trip.

Travel agent implementation (Amazon Nova 2 Lite)

The Travel Agent is the orchestrator of the whole workflow. It receives the user request, interprets intent using Amazon Nova 2 Lite, and decides which agent to call next. Nova 2 Lite is doing the heavy reasoning here—it breaks the input into steps, identifies when to trigger the Flight Agent or the Hotel Agent, and keeps track of the overall plan. Because the Travel Agent doesn’t touch external systems directly, its only job is to think clearly and route messages using A2A.

The following code example is a simplified version of how the Travel Agent is initialized:

    # 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, the Travel Agent receives a single natural language request, such as “Find me flights from NYC to Tokyo on July 10 and a hotel until July 15.” From there, Amazon Nova 2 Lite does the heavy reasoning: it recognizes that two separate tasks are required, generates 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 assembles both outputs into one coherent response. This keeps the orchestration logic clean and flowing. Nova 2 Lite effectively acts as the brain of the workflow, and the specialized agents handle the actual execution.

Flight agent implementation (Amazon Nova 2 Lite and API)

The Flight Agent has a much narrower job: turn a structured request into real flight options. It uses Amazon Nova 2 Lite for the light reasoning it needs for validating inputs, formatting the search, and deciding whether to call the live flight API or fall back to mock data when credentials aren’t available. After the API call is made, the agent returns a clean, predictable JSON response back to the Travel Agent through 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 the 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 reasoning load is light and the job 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 isn’t one clean API you can call, and most booking sites load content in ways that change from one visit to the next. This is where Amazon Nova Act comes in. The Hotel Agent uses Nova Act to control a real browser and follow natural language instructions. Instead of writing fragile scraping code, the agent tells Nova Act what it needs, and Nova Act takes care of the browsing and returns structured data.

Here’s a shortened 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 response. The full code, including scrolling, cookie banners, and other details, is in the 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 keeps the Hotel Agent from breaking every time the site changes its layout. And by using it, you can avoid writing your own scraping or DOM parsing logic.

A2A message flow (how the agents talk)

Now that each agent knows what it’s responsible for, they need a way to talk to each other. Before the Travel Agent starts sending real work, it first checks that the other agents are up by calling their A2A endpoints. It also loads the list of tools each agent exposes so Nova 2 Lite knows what capabilities are available. After that’s done, the flow is straightforward. The Travel Agent sends a message to the Flight Agent with the fields it needs. When the Flight Agent finishes, it sends a message back. Then the Travel Agent passes the next message to the Hotel Agent. Each message is a small JSON object with things like the action, the input data, and where to send the response.

End-to-end example run

Here’s how one full run looks. 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.

1. Travel Agent -> Flight Agent:
   1. The Travel Agent pulls out the flight part of the request and sends it to the Flight Agent.
   2. The Flight Agent returns three direct, cheap flights from JFK to Paris, including the airline, times, price, and duration.
2. Travel Agent -> Hotel Agent:
   1. The Travel Agent sends the hotel part of the request to the Hotel Agent.
   2. The Hotel Agent, using Nova Act, checks Paris hotels and returns the top three options with names, prices, and short notes.
3. Final result to the user
   1. The Travel Agent combines both answers and sends back a clear summary that includes:
4. The recommended flight
5. The recommended hotel
6. The check-in and check-out dates
7. The prices
8. A question asking whether to book

Conclusion

Building this travel planner with three small agents turned out to be much easier to manage than one big one. Each agent focuses on one job, and Amazon Nova 2 Lite handles the thinking needed to move the work from step to step. Amazon Nova Act covers the parts that don’t have APIs, such as hotel searches, without writing scraping code. The A2A message flow keeps everything connected but still straightforward.

This setup isn’t tied to travel. Tasks that mix different skillsets can use the same idea: let one agent plan the work, let the others do the parts they’re good at, and pass small messages between them. It makes the system seamless to change and explain.

If you want to try this yourself, the full code and examples are in the 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 growth—in building secure, scalable architectures and implementing Agentic 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 embrace new GenAI technologies.