What Inspired Us Our team was inspired by a simple but frustrating human experience: getting distracted while shopping online. We've all done it—you find the perfect item, add it to your cart, and then, a notification, a phone call, or a sudden thought pulls you away. You close the tab, and the moment is gone. We realized that while modern e-commerce platforms are incredibly fast and scalable, they are often reactive and linear. They wait for you to come back. We wanted to build something that was proactive, a system that could act as a true partner to the customer, anticipating their needs and re-engaging them in a helpful, non-intrusive way. The goal wasn't just to recover a lost sale; it was to build a relationship.
We were particularly intrigued by a key industry problem: the gap between AI awareness and implementation in e-commerce. Research shows that while most online stores recognize the value of AI, many are held back by a "fear of losing control" and the perceived complexity of integration. This challenge became our mission. We chose to tackle this head-on by building an external, multi-agent system that could connect to the existing Online Boutique APIs without ever modifying its core code, proving that you can add advanced intelligence without re-architecting your entire system.
What We Learned We learned that building an intelligent system isn't just about the model—it's about the architecture. We realized that a single AI agent, like a simple chatbot, has limited capabilities. The true power lies in a collaborative ecosystem of specialized agents, each with a distinct role. We learned that the communication between these agents is as important as the agents themselves. This led us to our core learning: the synergy between the Model Context Protocol (MCP) and the Agent2Agent (A2A) protocol. We found that the MCP was crucial for giving our agents a standardized way to access real-time data from the Online Boutique's APIs, preventing our models from hallucinating and ensuring their decisions were based on factual information. At the same time, the A2A protocol provided the "glue" that enabled our Abandon Cart Agent to seamlessly hand off a customer's information to the Personalization Agent, creating a dynamic, multi-step workflow that was impossible with a traditional, rules-based system. We quantified the commercial viability of this approach using a simple model for the expected revenue, where
n is the number of abandoned carts:
ExpectedRevenue=∑ i=1 n (CartValue i ×RecoveryRate i )
This simple equation helped us understand that by even slightly improving the Recovery Rate through personalized, proactive engagement, we could unlock significant revenue for a business.
How We Built Our Project We followed an agile, phased approach, building our project on the solid foundation of Google Kubernetes Engine (GKE) and the Google AI stack. We started by deploying the unmodified Online Boutique application on GKE to establish our baseline environment.
Phase 1: Foundation. We built an MCP server to act as a secure, standardized bridge between our future agents and the Online Boutique’s gRPC-based APIs. This was a critical first step, as it gave our AI a clear interface to the real world.
Phase 2: Single-Agent MVP. Using the Agent Development Kit (ADK), we built our first agent—a simple, read-only agent that used the MCP to query the productcatalogservice. This proved our core integration concept and gave us the confidence to build a more complex system.
Phase 3: The Multi-Agent Ecosystem. We then developed a full multi-agent system, including the Personalization Agent, the Inventory Agent, and the Abandon Cart Agent. We used the A2A protocol to create a dynamic workflow where these agents could collaborate. For example, when a cart was abandoned, the Abandon Cart Agent would ask the Personalization Agent for a tailored offer, then use the emailservice to send a dynamic, personalized message.
Phase 4: Optimization and Deployment. We containerized each new agent using a Dockerfile and used standard Kubernetes manifests to deploy them to GKE. This allowed us to scale our agents independently of the core application. We also implemented an API gateway to cache frequent requests, ensuring low latency and high performance.
Challenges We Faced The most significant challenge we faced was the complexity of orchestrating a multi-agent system. We quickly realized that we couldn't rely on a fixed, pre-scripted workflow. We had to build a system that could adapt in real time to unforeseen issues. For example, what happens if an API call to a core microservice times out? What if a product goes out of stock? To solve this, we integrated a "reflection pattern," where an orchestrator agent could detect the failure of a sub-agent and re-plan the workflow to either retry the task or escalate it to a human, ensuring system resilience.
We also had to tackle the issue of data privacy and user control, which the research identified as a major barrier to AI adoption. We addressed this by building a user-facing dashboard that provides full transparency, showing the user exactly what data the agents are using and allowing them to opt-out of certain capabilities, directly addressing the "fear of losing control" and building trust.
Built With
- a2a
- adk
- api-gateway
- docker
- gcloud
- gemini
- gemini-cli
- gke
- go
- google-ai-models
- google-cloud
- grpc
- java
- kubectl
- kubectl-ai
- kubernetes
- mcp
- node.js
- python
- vertex-ai
Log in or sign up for Devpost to join the conversation.