.png)
요약
Retail is entering the era of the multi-agent shopping assistant. Instead of a single, stateless chatbot following a rigid script, retailers are building systems where multiple agents collaborate behind the scenes, drawing on preferences and customer purchase…
본문
Retail is entering the era of the multi-agent shopping assistant. Instead of a single, stateless chatbot following a rigid script, retailers are building systems where multiple agents collaborate behind the scenes, drawing on preferences and customer purchase history to deliver recommendations that improve with every interaction. More retailers are reconfiguring their backends to reflect the rise in agentic usage, as this is no small trend: McKinsey estimates AI agents could mediate $3 trillion to $5 trillion of global consumer commerce by 2030 (1).
The need is real, as the race is heating up to quickly respond to customer searches and take service to another level. A customer searching for a pair of running shoes for an upcoming marathon no longer triggers a keyword search. The query kicks off a coordinated reasoning process across multiple specialized agents. This has to happen rapidly and seamlessly to keep consumers' attention and needs met.
The promise of this shift is real, but the real architectural question has nothing to do with which LLM or orchestration framework a team chooses. It has everything to do with where the data lives and whether every agent can see the same version of the truth simultaneously. Increasingly, retailers are finding that solution in MongoDB.
The technology challenge behind multi-agent AI
Building a single AI agent is straightforward with modern LLMs and orchestration frameworks. Building a production multi-agent system is not. Why? Agentic AI has five distinct data needs:
Semantic search over vector embeddings
Flexible user context
Conversation state across sessions
Long-term memory that evolves over time
Observability through audit logs
Engineering teams pay a heavy ‘siloed database tax’ to meet these needs, standing up five distinct, single-purpose datastores: a vector store for product discovery, a session store for chat history, a short-term memory store for session context, a long-term memory store for accumulated preferences, and an audit log for compliance and debugging.
That fragmentation comes at a cost. Every additional datastore adds its own SDK, its own operational overhead, and its own failure mode. If the profile agent writes a new preference to one store while the product agent reads from another, the two are only as consistent as the ETL job connecting them. In a real-time conversation, that gap shows up as an agent recommending a product the customer already ruled out, or forgetting a preference captured moments earlier.
Retail makes the problem concrete. Carol asks for running shoes for a road marathon. Her profile has her static preference on file: She wears a size eight. Earlier in this conversation, she mentioned wanting maximum cushioning; that's short-term session context. John asks for running shoes, too. His profile puts him at a size 11, but long-term memory holds something neither his profile nor this conversation does: He needs a waterproof build, a fact learned from a past return after a pair let water soak in. Serving both well, consistently, and across every channel requires holding all three—static preferences, session context, and long-term memory—as one coherent view. This is what we’ve built to make this all happen fluidly
Giving every agent the same context
Retailers building a multi-agent system need specialized agents—including planner agents, profile agents, product agents, and eventually others—to discover and invoke each other's capabilities regardless of which team built them. This is what an open protocol like Agent2Agent (A2A) (2) provides. The Multi Agent Retail Advisor (MARA) is a reference implementation. Here, a planner agent delegates to a profile agent and a product agent, coordinating through A2A. The orchestration framework and LLM are both swappable; MongoDB, the data layer underneath every agent, is not.
Figure 1. Reference architecture for the MARA, showing how the planner, profile, and product agents interact through the A2A protocol, with MongoDB Atlas unifying operational and agentic data via Vector Search, text search, and auto-embeddings.
MongoDB Atlas handles all five agentic data needs natively in one platform, as shown in Figure 2 below. Atlas Vector Search stores product embeddings alongside the catalog data itself, so semantic search runs directly against operational data instead of a separate index to remain in sync. The same flexible document model holds customer context and preferences without a schema migration every time a field changes. Short-term memory lives as a nested array inside each session document, allowing the planner agent to fetch an entire conversation in one read. Long-term memory accumulates in its own collection, capturing facts an agent learns about a customer, like a preference for polyester base layers because they dry faster, independent of any single session. Observability runs through the same platform, too, logging every tool call's inputs, outputs, and latency so a request's full execution path can be reconstructed instantly.
Figure 2. MongoDB Atlas consolidates all single-purpose datastores to meet agentic AI’s data needs into one platform.
.png)
For product discovery, retailers build directly on Atlas Vector Search. They embed queries with Voyage AI and match them semantically against the catalog, falling back automatically to Atlas full-text search on the same collection when a query needs it, with no extra infrastructure. Because Voyage AI's newer models share a common embedding space, retailers can embed the catalog once with a larger, accurate model, and then run live queries with a smaller, faster model without ever re-indexing.
A simpler, more resilient stack for IT teams
For retailers, the payoff is architectural simplicity that compounds into speed and cost savings. Teams no longer manage four or five separate systems; they manage one. Schema flexibility, shown in Figure 3, lets agent state and user profiles, each varying by shopper or task, evolve without disruptive migrations. Because MongoDB Atlas scales horizontally, it supports the bursty, unpredictable request patterns of autonomous agents without becoming a bottleneck. Full observability works the same way: A single aggregation pipeline query joins the tool_invocations log, agent_state history, and session record for a request, reconstructing what each agent did, in what order, and how long each step took. That gives IT teams a queryable execution trace for every agent decision, shortening the path from a production issue to a root cause.
Figure 3. Two documents from the agent_state collection and two from the users collection. This shows the same collection, different shape, depending on which agent ran or which shopper it describes.
This consolidation also changes how fast a team can move. The product catalog, user profiles, session history, long-term memory, and tool-invocation logs all live as collections in one MongoDB cluster, not four separate systems linked together. That's the difference between a proof of concept shipping in weeks and one spending its first quarter wiring systems together before a single agent runs. This setup lowers total cost of ownership the same way: one licensing agreement, one scaling model, and one team. Governance benefits too. Fine-grained access controls, encryption, and audit logging apply consistently across every agent's data, instead of system-by-system configuration. Because the architecture is not tied to a specific framework or model provider, retailers can add new agents, inventory, loyalty, and fulfillment onto the same data plane without replatforming. That matters most for agents no one can name yet. Any future agent built on the same document model plugs into the same unified context, turning what would otherwise be a multi-quarter integration effort into a schema extension.
An experience that feels seamless for customers
For customers, this translates into an experience that feels genuinely continuous. Because every agent reads from and writes to the same unified context, a preference shared in one conversation carries into the next. A question that starts in a chat can hand off cleanly to an inventory agent checking store stock or a loyalty agent applying a reward without the customer repeating themselves. This results in recommendations that get sharper the more a customer interacts with the system and a shopping experience that feels like one relationship rather than a series of disconnected sessions.
Figure 4. Any multi-agent retail architecture needs a swappable layer for orchestration and the LLM, but every agent still needs one constant data layer underneath it. Here, that's MongoDB Atlas beneath MARA's planner, profile, and product agents.
.png)
That continuity holds up across channels, not just across conversation turns. A preference a customer states while browsing on mobile is available the next time they open a chat window, walk into a store, or call support because it lives in the same unified profile every agent reads from rather than in a channel-specific cache. Customers also benefit from recommendations that account for their actual history rather than generic popularity signals. This happens since the product agent's semantic search runs against a catalog informed by what a shopper has already bought, browsed, and rejected. For the business, that precision compounds directly into commerce metrics: higher conversion, larger basket sizes, and fewer costly returns from recommendations that miss the mark.
Building for what comes next
The orchestration framework and LLM a retailer chooses today will likely change more than once. What shouldn't change is the data layer holding the system together. MongoDB gives retailers a single, flexible foundation for the knowledge, context, memory, and observability multi-agent retail experiences depend on, so the architecture underneath doesn't have to be rebuilt as frameworks and models evolve. Retailers that consolidate this layer now will be the ones ready to add the next agent—and the next protocol—without starting over.
megaphoneNext Steps
Discover how MongoDB can help you deliver seamless customer experiences across all channels through our industry solutions page.
Ready to start building? Register for MongoDB Atlas for free today and get started.
References
The automation curve in agentic commerce. McKinsey. January 28th, 2026.
https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-automation-curve-in-agentic-commerceGetting Started with Agent2Agent (A2A) Protocol https://codelabs.developers.google.com/intro-a2a-purchasing-concierge#0