Agent-to-agent interoperability: Using Amazon Nova 2 Lite and Amazon Nova Act in multi-agent systems

My first attempt at building a travel planning agent looked exactly like most early prototypes: one big model, few tools, and a long system information. It worked well until real-world difficulties arose. Airlines come from a clean API, hotels stay behind a dynamic web UI, and the model kept mixing instructions, forgetting the context, or tricky steps. That's when it became clear: the single agent was not the cure, it was the bottle.

Getting a fix meant splitting the job instead of trying to fix the information. This post walks through how agent-to-agent interaction in Amazon Bedrock works, using Amazon Nova 2 Lite programming and Amazon Nova Act through browser interaction, to transform a fragile single-agent setup into a predictable multi-agent system.

Solution overview

The system is built as a small group of agents working together, as shown in the following diagram. One agent schedules the job and communicates with the user. Some agents handle specific tasks, such as flight searches or hotel searches. They communicate with simple messages, so each agent stays focused and the work is easy to think about.

When I saw where the single-agent design broke down, the pattern was clear: the agent wasn't struggling because the task was difficult, it was struggling because the tasks were too different. Flight searches are structured and predictable. Hotel search is messy, intuitive, and full of dynamic features. Forcing one model to juggle both was like asking the same developer to write back-end APIs and manually re-click on a website in real-time. And the more I tried to patch it up with commands, extra tools, and other logical fallbacks, the worse it got. If a single agent is burdened with too many responsibilities, it shrinks, loses context, makes inconsistent choices, and eventually collapses under its own weight. The problem was in the design, and trying to fix it by command wouldn't work. The solution was to divide the work into three agents and allow each to focus on one responsibility. Travel Agent manages the user's intention and planning. Flight Agent communicates with the scheduled flight API. And Hotel Agent used a default browser to navigate real hotel sites. Instead of one overcrowded model, each agent does one thing well – and they communicate through a simple messaging layer, so the workflow still feels seamless from the outside. Each agent had a very specific job. The Travel Agent was a coordinator that interpreted the request, divided it into steps, and decided which agent should use each part. Flight Agent focused entirely on structured API calls where data was predicted. And Hotel Agent takes care of the dirty parts: navigating web pages, managing dynamic properties, and extracting hotel information from real sites. Dividing the system in this way kept the logic clean and prevented individual agents from becoming too crowded.

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 for the next step. We didn't need anything fancy, just a lightweight message format that agents could go through so they each knew what to do next. Once that communication loop was in place, the entire workflow finally felt connected instead of chaotic pages with dynamic layouts and no public APIs. Using the same agent to treat both often leads to equipment overload, confusing instructions, and a high risk of misdiagnosis.

Implementation overview

Now that the construction was clear, it was time to build the system. This is where the tools behind each agent come into play. Both Travel Agent and Flight Agent use Amazon Nova 2 Lite for inference and planning, and Flight Agent also calls the structured flight API to retrieve the actual data. Hotel Agent relies on Amazon Nova Act to automate browser interactions in the absence of an API. The three agents communicate in a direct agent-to-agent (A2A) transfer pattern, where agents exchange small, structured messages to coordinate their work, which keeps the workflow predictable as each agent works in a different execution environment. In a multi-agent system, coordination is equally important as specialization. Agents need a structured, predictable way to exchange goals, share status, and trigger behavior especially when engaging in a task like travel planning.

Implementation of travel agent (Amazon Nova 2 Lite)

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. Nova 2 Lite does the hard thinking here—it breaks the input into steps, indicates when to launch the Flight Agent or the Hotel Agent, and tracks the entire process. Because the Travel Agent does not directly interact with external systems, its only job is to think correctly and deliver messages using A2A.

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

    # Initialize A2A client tools
    provider = A2AClientToolProvider(known_agent_urls=[
        "  # Hotel Booking Expert (NovaAct)
        "   # 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.

Basically, the Travel Agent receives a single natural language request, such as “I got flights from NYC to Tokyo on July 10th and a hotel until July 15th.” From there, Amazon Nova 2 Lite does the hard thinking: it realizes that two different tasks are needed, generates a clear plan, sends a message to the Flight Agent, waits for the results, and then triggers the Hotel Agent with the next command. Finally, it combines both results into one coherent response. This keeps the orchestration logic clean and flowing. Nova 2 Lite effectively acts as the brain of the workflow, and special agents handle the actual execution.

Flight agent implementation (Amazon Nova 2 Lite and API)

The Flight Agent has a very small task: turn a structured request into real flight options. It uses Amazon Nova 2 Lite for the simple reason that it needs to validate the input, format the search, and decide whether to call the live flight API or fall back to mock the data when the information is not available. After the API call is made, the agent returns a clean, predicated JSON response to the Travel Agent via A2A.

The following code example shows a simplified version of the flight search tool. The complete implementation, including OAuth, fallback logic, and airport code management, is available for agent-to-agent via the 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 burden of thinking is light and the work of Amazon Nova 2 Lite is mainly about choosing the right method of extraction and normalizing the output. This keeps the entire pipeline predictable and avoids embedding specific API logic within Travel Agent.

Hotel agent implementation (Amazon Nova Act)

Hotels are not at all like airplanes. There is no single clean API to call, and many booking sites load content in ways that change from one visit to the next. This is where the Amazon Nova Act comes into play. Hotel Agent uses Nova Act to control the actual browser and follow natural language instructions. Instead of writing weak scraping code, the agent tells Nova Act what it needs, and Nova Act takes care of browsing and returns structured data.

Here is an abbreviated 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 is a simplified example of the answer. The full code, including scrolling, cookie banners, and other details, is on the agent via the 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 the Amazon Nova Act prevents the Hotel Agent from breaking every time the site changes its structure. And by using it, you can avoid writing your own scratch or DOM partitioning logic.

A2A message flow (how agents talk)

Now that each agent knows what they are responsible for, they need a way to talk to each other. Before a Travel Agent starts sending an actual job, it first checks for the presence of other agents by calling their A2A endpoints. It also loads a list of tools that expose each agent so the Nova 2 Lite knows what capabilities are available. After that, the flow is straightforward. The Travel Agent sends a message to the Flight Agent with the required fields. When the Flight Agent finishes, it sends the message again. Then the Travel Agent forwards the following message to the Hotel Agent. Each message is a small JSON object with things like action, input data, and where to send the response.

An end-to-end example run

Here's what one full 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.

1. 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, times, price, and duration.
2. Travel Agent -> Hotel Agent:
   1. The Travel Agent sends part of the hotel request to the Hotel Agent.
   2. Hotel Agent, using Nova Act, searches for hotels in Paris and returns the top three options with names, prices, and short notes.
3. The end result for the user
   1. Travel Agent combines both responses and returns a clear summary that includes:
4. Recommended flight
5. Recommended hotel
6. Check-in and check-out dates
7. Prices
8. A question asking if you will make a reservation

The conclusion

Building this travel planner with three small agents was much easier to manage than one large one. Each agent focuses on one task, and the Amazon Nova 2 Lite handles the thinking needed to move the task from one step to another. Amazon Nova Act integrates components without APIs, such as hotel search, without writing code from scratch. The A2A message flow keeps everything connected but still on point.

This setting is not tied to mobility. Tasks involving different skills can use the same logic: let one agent plan the task, let the others do the parts they are good at, and pass small messages between them. It makes the system seamless to change and define.

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 writers

Yoav Fishman AWS Solutions Architect with 12 years of cloud and engineering experience, specializing in GenAI, Agentik AI, and cybersecurity. He guides startups—from inception to growth—in building secure, scalable architectures and implementing Agentic AI workflows that drive business impact.

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

Dan Kolodny an AWS Solutions Architect specializing in big data, analytics, and GenAI. He is passionate about helping clients implement best practices, find insights from their data, and embrace new GenAI technologies.