Scalable Automation Starts Here: Meet Stagehand and MongoDB Atlas

Sigfrido Narvaez and Kyle Jeong
September 12, 2025

While APIs deliver clean, structured data on a silver platter, the most valuable insights for AI applications often hide in the messy, unstructured corners of the web. AI's potential is immense, and many organizations face a significant challenge: their existing data infrastructure isn't ready for the scale needed by AI. The web is a vast ocean of data, and ~80% of it is unstructured.

But what if you could reliably automate web interactions, extract complex data, and seamlessly integrate it into a database that offers a variety of query and search methods? This is where the powerful combination of Stagehand (by Browserbase) and MongoDB Atlas redefines what's possible for building AI applications.

Figure 1. Stagehand and MongoDB Atlas: Seamlessly automating web data collection and AI-ready integration.

This diagram starts on the left with a bubble titled web sources that feeds into BrowserBase. The box for BrowserBase contains natural language interfact, playwright core, and BrowserBase interface. BrowserBase then feeds to MongoDB Atlas, which contains multi-cloud document store, vector engine, search engine, and stream processing. Atlas then connects to MongoDB MCP Server, while the internal tools connect to MCP Server through Voyage AI Models. The MCP server then provides information to the user.

Stagehand: An SDK for developers to write automations with natural language

The browser is a powerful tool for collecting data, but it's hard to control and scale. Traditional browser automation tools like Playwright, Puppeteer, and Selenium often force developers to write fragile code that breaks with even slight UI changes on a website. This makes maintaining scripts on live websites a significant pain point. Stagehand, however, is designed specifically for the AI era.

Stagehand allows you to automate browsers using a combination of natural language and code. It's built to be more reliable and adaptable than legacy frameworks, enhancing Playwright's determinism with large language models (LLMs) to account for page changes and volatility. This means you can write code once, and it adapts to that website if it changes.

Key capabilities of Stagehand include:

Reading and interacting with page content: Stagehand can read page content by parsing the DOM using accessibility trees, interact with, and continue to work even when the page changes.

Natural language operations: You can use natural language to extract data or instruct the browser to take actions. For instance, page.extract("the price of the first cookie") or page.act("add the first cookie to cart")<.

Agentic workflows: Stagehand allows you to use a simple agent to automate complex workflows with commands like stagehand.agent.execute("complete checkout") or stagehand.agent.execute("Extract the top contributor's username").

Full control: By extending the page and context objects from Playwright, Stagehand gives developers full control over the browser session, allowing for deterministic and repeatable automation while being resilient to unpredictable DOM changes.

Performance-oriented: Traditionally, developers would inspect the DOM manually, right-click elements, test CSS or XPath selectors in the console, and tweak them repeatedly to get automation working using the browser’s DevTools, such as the example below to select a button nested in div’s. await page.click('div.container > div:nth-child(3) button.primary'); with Stagehand, those selectors are automatically inferred and stabilized, so you can focus on logic instead of fragile DOM paths.

For scaled, production deployments, Stagehand works seamlessly with Browserbase, allowing you to launch hundreds of browsers at once through an API, with advanced features like session replay, prompt observability, and captcha solving.

MongoDB Atlas: The AI-ready data foundation

Once Stagehand has done its work, gathering dynamic web content and insights, you need a robust, flexible, and scalable database to store, process, and make sense of this data for your AI applications. This is where MongoDB Atlas shines as the ideal data foundation.

MongoDB Atlas is built to handle today's need for flexible, real-time data processing, unlike traditional databases that are rigid and not designed for an AI-first world.

Here's how MongoDB Atlas becomes the memory and content hub for Stagehand's extracted data:

Flexible document model: Stagehand can extract highly diverse information from websites—from product details and customer reviews to financial reports and real estate listings. MongoDB's flexible document model mirrors the way developers structure data in their code, making it a natural fit for complex, semi-structured, and constantly evolving web data. It eliminates the need for cumbersome schema “day 1” definitions and “day 2” migrations, which are a constant bottleneck in relational databases.

Native vector search: A significant blind spot in traditional data analysis is the vast amount of semi-structured data. MongoDB Atlas Vector Search addresses this by enabling modern vector search workflows. With Stagehand, you can define the structure in every extract call, catering to a variety of concepts—like product reviews, customer support transcripts, or even images from visually rich documents. Once scraped, they can be vectorized via embedding models (such as Voyage AI's voyage-3-large) and ingested directly into MongoDB Atlas. Storing these vector embeddings next to the original text chunks along with semi-structured data allows for native semantic search queries directly inside the database, reducing system complexity, development and testing time, and enabling low-latency results.

Voyage AI models: Voyage AI offers specialized embedding models, including voyage-multimodal-3, capable of processing interleaved text and images, making it ideal for varied website content from text articles to images and mixed media. Domain-specific models like voyage-code-3, voyage-law-2, and voyage-finance-2 ensure scraped data receives contextually appropriate semantic understanding. These models show up to 20% improved retrieval accuracy over widely adopted production models across 100 datasets, crucial for handling noisy web-scraped content.

The native integration eliminates operational complexity when managing multi-modal scraped data at scale. By natively bringing Voyage AI's models to MongoDB Atlas, developers eliminate the burdens of managing separate API calls for embeddings and reranking, reducing overhead when processing diverse web content types. The unified platform optimizes both storage and retrieval, making it cost-effective for large scraped datasets. The combination of embedding models and reranking models that deliver gains of up to 14% in precision and recall ensures accurate retrieval from massive, heterogeneous web datasets, enabling AI applications to provide precise responses regardless of original data source or format.

Real-time stream processing: Stagehand can continuously gather live information from the web. MongoDB Atlas Stream Processing enables development teams to process streams of this complex data in real time using the familiar MongoDB Query API. This is crucial for applications requiring immediate insights, such as dynamic pricing in retail or real-time market intelligence. Atlas Stream Processing can also invoke external functions, such as AWS Lambda functions, directly from streaming pipelines for data enrichment, validation, or AI/ML inference in-flight. Below is a definition of an asynchronous external function:

let asyncEF = {
  $externalFunction: {
    connectionName: "EF-Connection",
    functionName: "arn:aws:lambda:us-west-1:12112121212:function:EF-Test",
    execution: "async"
  }
}

Support for agentic AI architectures: AI agents often require dynamic evaluation criteria and the ability to enrich feature sets based on diverse data. MongoDB Atlas is uniquely suited to store dynamic criteria as flexible JSON documents and serves as the ideal foundation for agentic architectures, allowing captured web data to be used to generate new features for machine learning models without requiring schema redesigns. Checkout this blog post defining 7 Practical Design Patterns for Agentic Systems.

Massive scalability: Whether Stagehand is scraping millions of product listings or billions of clinical data points, MongoDB Atlas's distributed architecture and flexible schema simplify scaling, handling unpredictable workloads and massive data volumes effortlessly. Companies like Ubuy manage over 300 million products and 150 million annual searches, while SHARE NOW handles 2 TB of IoT data per day, all powered by MongoDB Atlas. Additionally, Browserbase enabled Structify to eliminate gigabytes of RAM usage, bringing memory consumption on their production web servers down to virtually zero, and can support several thousand concurrent browser sessions, allowing them to scrape tens of thousands of websites in a single campaign with ease.

The powerful synergy: Stagehand + MongoDB Atlas in action

Figure 2. Data flow: From web automation via Stagehand to scalable AI processing in MongoDB Atlas.

Diagram showing the data flow for web automation.

Imagine the possibilities when Stagehand reliably harvests information from the web, and MongoDB Atlas makes that data immediately actionable for AI:

Customer engagement & product discovery: Stagehand can extract vast amounts of customer reviews and product information from various e-commerce platforms. MongoDB Atlas stores this data as both operational data and vector embeddings, enabling AI-driven recommendations and intent-driven product discovery, as seen with Ubuy, reducing search times from seconds to milliseconds, but still providing traditional query and insights over data as required by human consumers, enterprise systems, and external partners and consumers.

Real-time market and financial intelligence: Stagehand can be programmed to extract live financial news, market trends, or competitive pricing data. This real-time stream can be fed into MongoDB Atlas Stream Processing for immediate analysis, enabling dynamic pricing models or allowing financial analysts to sift through dense reports with AI-powered multimodal search for specific trends.

Enhanced content curation and recommendation: For media companies, Stagehand can gather articles, reports, and visual content from diverse sources. MongoDB Atlas, with its vector search and multimodal capabilities, allows for a hybrid search experience, blending keyword precision with AI-driven discovery, delivering hyper-relevant recommendations instantly, much like the Financial Times' solution.

Next-gen inventory classification: By using Stagehand to collect qualitative metrics from product reviews or social media posts (e.g., customer expectations, re-purchase probability), this unstructured data can be vectorized and integrated into MongoDB Atlas. AI agents can then use this enriched dataset to dynamically classify inventory, transforming reactive inventory management into predictive and customer-centric decision-making.

The bridge to AI platforms via the model context protocol (MCP)

The MongoDB MCP Server allows for interacting with both MongoDB Databases and MongoDB Atlas. It can be configured using a MongoDB connection string or Atlas API credentials, and supports various deployment methods, including npx commands or Docker containers.

Tool-based access: The MCP Server exposes a list of "tools" for interacting with your data. These tools are categorized into:

MongoDB Atlas tools: For managing Atlas resources like listing organizations, projects, clusters, creating clusters, managing access lists, and database users.
MongoDB database tools: For direct data operations such as find, aggregate, count, insert-one, insert-many, update-one, update-many, delete-one, delete-many, create-index, drop-collection, drop-database, list-databases, and list-collections. This comprehensive set of tools means AI applications can not only read (e.g., find, aggregate) but also potentially write or modify data (e.g., insert-one, update-one) in your Atlas clusters, depending on the server configuration.

Integration with AI clients: The MCP Server is explicitly designed to be integrated with various Model Context Protocol clients. The sources mention specific clients such as Windsurf, VSCode, Claude Desktop, and Cursor. This means that any AI application or platform that supports the Model Context Protocol can leverage the MongoDB MCP Server.

Query and Retrieve Data: Perform find and aggregate operations directly against your MongoDB collections—whether structured, semi-structured, or enriched with vector embeddings. Use $vectorSearch for semantic similarity, $search for lexical matching, or $rankFusion to blend relevance signals from both for more accurate results. For example, an AI agent can retrieve specific documents or run complex analytics on scraped content, combining keyword filters with semantic context in a single query pipeline. Below is an example that executes two input pipelines, combines the returned results, and outputs the first 20 “rank fusioned” documents.

db.embedded_movies.aggregate( [
   {
      $rankFusion: {
         input: {
            pipelines: {
               searchOne: [
                  {
                     "$vectorSearch": {
                        "index": "<INDEX_NAME>",
                        "path": "<FIELD_NAME>",
                        "queryVector": <QUERY_EMBEDDINGS>,
                        "numCandidates": 500,
                        "limit": 20
                     }
                  }
               ],
               searchTwo: [
                  {
                     "$search": {
                        "index": "<INDEX_NAME>",
                        "text": {
                           "query": "<QUERY_TERM>",
                           "path": "<FIELD_NAME>"
                        }
                     }
                  },
                  { "$limit": 20 }
               ],
            }
         }
      }
   },
   { $limit: 20 }
] )

Manage data: Depending on configuration, AI agents could also insert new scraped data, update existing records, or even create indexes to optimize future queries.
Access Atlas management: AI platforms could potentially manage parts of your MongoDB Atlas infrastructure (e.g., list clusters or projects) if configured with appropriate Atlas API credentials and permissions.

Security and control: The MCP Server offers configuration options like readOnly mode, which restricts operations to only "read", "connect", and "metadata" types, disabling "create", "update", or "delete" operations. This is crucial for controlling how AI applications interact with sensitive scraped data. It also has an indexCheck mode to enforce optimized queries.

By combining Stagehand's robust web data acquisition, MongoDB Atlas's flexible and AI-ready data foundation (including vector search capabilities), and the MongoDB MCP Server's ability to expose this data and its management tools to diverse AI applications and platforms, organizations can create a truly seamless and powerful data pipeline for their AI initiatives. This setup empowers developers and AI agents to access, understand, and leverage web data at an unprecedented scale and efficiency.

Ready to build smarter, adapt faster, and scale more confidently? Explore Stagehand and Browserbase for your browser automation needs and connect it with a free MongoDB Atlas cluster to power your next AI application – get started with the MongoDB + Stagehand integration on GitHub.

← Previous

Why Multi-Agent Systems Need Memory Engineering

Most multi-agent AI systems fail not because agents can't communicate, but because they can't remember. Production deployments have shown agents tend to duplicate work, operate on inconsistent states , and burn through token budgets, re-explaining context to each other—problems that scale exponentially as you add more agents. A breakthrough came from context engineering for individual agents: " The right information at the right time " transforms agent effectiveness. But this principle breaks down catastrophically when multiple agents must coordinate without shared memory infrastructure. To understand multi-agent coordination, we must first establish our foundation: Agent memory (and memory management) is a computational exocortex for AI agents—a dynamic, systematic process that integrates an agent’s LLM memory (context window and parametric weights) with a persistent memory management system to encode, store, retrieve, and synthesize experiences. Within this system, information is stored as memory units (also called memory blocks)—the smallest discrete, actionable pieces of memory that pair content with rich metadata such as timestamps, strength/confidence, associative links, semantic context, and retrieval hints. Agent memory is the key term, but the actual discipline that is the focal point of this piece is memory engineering. Memory engineering is the missing architectural foundation for multi-agent systems. Just as databases transformed software from single-user programs to multi-user applications, shared persistent memory systems enable AI to evolve from single-agent tools to coordinated teams capable of tackling enterprise-scale problems. The path from individual intelligence to collective intelligence runs through memory. Figure 1. The relationship between memory engineering and context engineering. The memory crisis in multi-agent systems Enterprise AI agents face a fundamental architectural mismatch. Without the proper data-to-memory transformation pipeline (aggregation → encoding → storage → organization → retrieval), they're built on stateless large language models but must operate in stateful environments that demand continuity, learning, and coordination. This creates cascading failure modes that become exponentially worse when agents work together. Individual agent memory failures Every production agent battles four core memory problems . Context poisoning occurs when hallucinations contaminate future reasoning, creating a feedback loop of increasingly inaccurate responses. Context distraction happens when too much information overwhelms the agent's decision-making process, leading to suboptimal choices. Context confusion emerges when irrelevant information influences responses, while context clash creates inconsistencies when conflicting information exists within the same context window. Figure 2. How context degrades over time. Recent research from Chroma reveals an additional critical issue: context rot —the systematic degradation of LLM performance as input length increases, even on trivially simple tasks. Their evaluation of 18 leading models, including GPT-4.1, Claude 4, and Gemini 2.5, demonstrates that performance degrades non-uniformly across context lengths, with models showing decreased accuracy on tasks as basic as text replication when processing longer inputs. This phenomenon is particularly pronounced when needle-question similarity decreases—as needle-question similarity decreases, model performance degrades more significantly with increasing input length—and when distractors are present, creating cascading failures in multi-agent environments where context pollution spreads between agents. These problems are expensive. According to Manus AI's production data, agents solving complex tasks average 50 tool calls per task with 100:1 input-to-output token ratios , far exceeding simple chatbot interactions. With context tokens costing $0.30-$3.00 per million tokens across major LLM providers, inefficient memory management becomes prohibitively expensive at scale. Multi-agent coordination failures When multiple agents operate without proper memory coordination, individual failures become systemic problems. Research by Cemri et al. analyzing over 200 execution traces from popular multi-agent frameworks found failure rates ranging from 40% to over 80%, with 36.9% of failures attributed to inter-agent misalignment issues ( Cemri et al., "Why Do Multi-Agent LLM Systems Fail?" ). Figure 3. Challenges encountered in multi-agent systems, categorized by type. Work duplication occurs constantly—agents repeat tasks without knowing others have already completed them. An inconsistent state means different agents operate on different versions of reality, leading to conflicting decisions and recommendations. Communication overhead skyrockets as agents must constantly re-explain context and previous decisions to each other. Most critically, cascade failures spread one agent's context pollution to others through shared interactions. The coordination chaos this creates is exactly what Anthropic's team encountered in their early development: "Early agents made errors like spawning 50 subagents for simple queries, scouring the web endlessly for nonexistent sources, and distracting each other with excessive updates" (Anthropic, Hadfield et al., 2025). These coordination failures aren't just inefficient—they're architecturally inevitable without proper memory engineering. This is particularly evident in Deep Research Mode (one of three core application modes alongside Assistant and Workflow modes), where Anthropic found that multi-agent systems excel when properly architected with shared memory infrastructure. Memory as the foundation for multi-agent coordination Understanding multi-agent coordination requires understanding how individual agents manage memory. Like humans, every agent operates within a memory hierarchy—from immediate working memory to long-term stored knowledge to shared cultural understanding: Figure 4. Memory types specific to multi-agent systems. The context window challenge A context window represents an agent's active working memory—everything it can "see" and reason about simultaneously. This includes system prompts, tool schemas, memory units, recent conversations, files, and tool responses. Even large models with 128K token limits can be exceeded by complex agent tasks, creating performance bottlenecks and cost explosions. Context engineering emerged as the solution for individual agents: managing what information enters the context window and how it's organized. The goal is getting "the right information at the right time" to maximize agent effectiveness while minimizing costs. Figure 5. Conversations aren’t free—the context window can become a junkyard of prompts, outputs, tool calls, and metadata, failed attempts, and irrelevant information. This represents the natural evolution from prompt engineering to context engineering , and now to memory engineering and memory management —the operational practice of orchestrating, optimizing, and governing an agent's memory architecture. While single-agent memory management remains an active area of research, techniques like retrieval-augmented generation (RAG) for semantic knowledge access, hierarchical summarization for compressing conversation history, dynamic context pruning for removing irrelevant information, and external memory systems like MemGPT have dramatically improved individual agent reliability and effectiveness over the past few years. The multi-agent memory challenge Research insight: Studies show that memory management in multi-agent systems must handle "complex context data and sophisticated interaction and history information," requiring advanced memory design. These systems need both individual agent memory capabilities and sophisticated mechanisms for "sharing, integrating, and managing information across the different agents" ( LLM Multi-Agent Systems: Challenges and Open Problems, Section 4 ). Most memory engineering techniques developed to date focus on optimizing individual agents, not multi-agent systems. But coordination requires fundamentally new memory structures and patterns that single-agent systems never needed. Multi-agent systems demand innovations like consensus memory (a specialized form of procedural memory) for verified team procedures, persona libraries (extensions of semantic memory's persona memory) for role-based coordination, and whiteboard methods (implementations of shared memory configured for short-term collaboration)—structures that emerge only when agents work together. Figure 6. How persona, consensus, and whiteboard memory work together. More importantly, multi-agent systems create opportunities to invest in collective memory that improves both current performance and future agent capabilities. Shared external memory enables several critical capabilities: Persistent state across agent interactions ensures continuity when agents hand off tasks or collaborate on long-running projects. Atomic operations provide consistent updates when multiple agents need to modify a shared state simultaneously. Conflict resolution handles situations where agents attempt contradictory updates to the same information. Performance optimization through caching and indexing reduces redundant operations across agent teams. Context windows become shared resources requiring careful management. Core memory alignment ensures agents share essential state and objectives. Selective context sharing propagates relevant information between agents without overwhelming their individual context windows. Memory block coordination provides synchronized access to shared memory blocks. Cost optimization maximizes KV-cache hit rates across agent interactions, reducing the exponential cost growth that kills multi-agent deployments. The economic impact of smart context management in multi-agent systems isn’t trivial, as Anthropic found in their multi-agent deep research deployment: " In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats " (Anthropic, Hadfield et al., 2025). Yet when coordination and memory work together, the results are remarkable. Anthropic's research system provides compelling evidence: " We found that a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval " (Anthropic, Hadfield et al., 2025). This dramatic improvement shows the multiplicative potential of well-coordinated agent teams. The 5 pillars of multi-agent memory engineering Successful multi-agent memory engineering requires architectural foundations that extend beyond single-agent patterns. These five pillars provide the complete framework for scalable multi-agent systems. Figure 7. Five pillars of engineering memory for multi-agent systems. 1. Persistence architecture (storage and state management) Multi-agent systems need sophisticated storage patterns that enable coordinated state management across agent teams. Memory units structured as YAML or JSON documents in systems like MongoDB provide the foundation for complex multi-agent state management. These memory units—structured containers with metadata and relationships—can be configured as either short-term or long-term shared memory depending on use case requirements. Shared Todo.md patterns extend the proven individual agent pattern of constantly updated objectives to team-level coordination. A shared objective tracking system ensures all agents work toward aligned goals while maintaining visibility into team progress. Cross-agent episodic memory captures interaction history and decision patterns between agents. This enables agents to learn from past coordination successes and failures, improving future collaboration effectiveness. Procedural memory evolution stores workflows and coordination protocols that improve over time. As agent teams encounter new scenarios, they can update shared procedures, creating institutional memory that benefits the entire system. 2. Retrieval intelligence (selection and querying) Retrieving the right information at the right time becomes exponentially more complex with multiple agents accessing shared memory concurrently. Embedding-based retrieval uses vector similarity to find relevant cross-agent memory, but must account for agent-specific contexts and capabilities. A customer service agent and a technical support agent need different information about the same customer issue. Agent-aware querying tailors memory selection based on individual agent capabilities and roles. The system understands which agents can act on specific types of information and prioritizes accordingly. Temporal coordination manages time-sensitive information sharing. When one agent discovers urgent information, the memory system must propagate this to relevant agents quickly while avoiding information overload for agents working on unrelated tasks. Resource orchestration coordinates access across multiple knowledge bases, APIs, and external systems. Rather than each agent independently querying resources, the memory system can optimize queries and cache results for team benefit. 3. Performance optimization (compression and caching) Optimization becomes critical when context costs multiply across agent teams. Hierarchical summarization compresses inter-agent communication efficiently. Rather than storing complete conversation transcripts between agents, the system can create layered summaries that preserve essential information while reducing storage and retrieval costs. Selective preservation maintains restoration paths for complex coordination scenarios. Even when compressing information, the system preserves references to original sources, enabling agents to access full context when needed. Intelligent eviction implements memory lifecycle management through forgetting (gradual strength degradation) rather than deleting, removing redundant information while preserving the coordination state. The system reduces memory strength attributes of outdated memory units while maintaining their structure for potential reactivation. Cross-agent cache optimization implements shared KV-cache strategies that benefit the entire agent team. When one agent processes information, the results can be cached for other agents with similar contexts, dramatically reducing costs. 4. Coordination boundaries (isolation and access control) Effective boundaries prevent context pollution while enabling necessary coordination. Agent specialization creates domain-specific memory isolation. A financial analysis agent and a marketing agent can share high-level project information while maintaining separate specialized knowledge bases. Memory management agents handle cross-team memory operations as a dedicated responsibility. Rather than every agent managing memory independently, specialized agents can optimize memory operations for the entire team. Workflow orchestration coordinates context across specialized agent teams. The system understands how information flows between different agent roles and can manage context propagation accordingly. Session boundaries isolate memory by project, user, or task domain. This prevents information leakage between unrelated workstreams while enabling rich context within specific collaboration boundaries. 5. Conflict resolution (handling simultaneous updates) Multi-agent systems must gracefully handle situations where agents attempt contradictory or simultaneous updates to shared memory. Atomic operations ensure that critical memory operations to update memory units happen entirely or not at all. When multiple agents need to perform memory operations on shared memory units simultaneously, atomic operations prevent partial updates that could leave the system in an inconsistent state. Version control patterns track changes to shared memory over time, enabling agents to understand how information evolved and resolve conflicts based on temporal precedence or agent authority levels. Consensus mechanisms handle situations where agents have conflicting information about the same topic. The system must determine which information is authoritative and how to propagate corrections to agents operating on outdated knowledge. Priority-based resolution resolves conflicts based on agent roles, information recency, or confidence levels. A specialized technical agent's assessment might override a general-purpose agent's conclusion about a technical issue. Rollback and recovery enable the system to revert problematic changes when conflicts create an inconsistent state. If a memory update causes downstream coordination failures, the system can roll back to a known-good state and retry with better conflict resolution. Figure 8. Analogies for memory engineering. Measuring multi-agent memory success Successful multi-agent memory engineering requires understanding what good coordination looks like and how it relates to the five architectural pillars. Rather than focusing on individual agent performance, we must measure emergent behaviors that only appear when agents work together effectively. What success looks like Seamless coordination makes multi-agent systems reliable (through consistent access to accurate historical context), believable (through trustworthy inter-agent interactions), and capable (through leveraging accumulated collective knowledge)—the RBC framework that defines successful agent memory implementation. Collective intelligence emerges when agent teams consistently outperform individual agents on complex tasks. The shared memory system enables capabilities that no single agent could achieve alone. Cost-effective scaling occurs when adding agents to a team reduces per-task costs rather than multiplying them. Effective memory sharing prevents the exponential cost growth that kills most multi-agent deployments. Resilient operations maintain continuity when individual agents fail or new agents join the team. The shared memory system preserves institutional knowledge and enables smooth transitions. Adaptive learning allows agent teams to improve over time through accumulated experience. Shared memory becomes an investment that benefits current and future agent deployments. Figure 9. High-level signals for measuring memory engineering quality. Persistence architecture success shows up as a consistent state across all agents and zero data loss during coordination. You measure this through state synchronization rates and the absence of coordination conflicts caused by inconsistent storage. Retrieval intelligence success manifests as agents quickly finding exactly the information they need without information overload. Effective retrieval means agents spend time acting rather than searching. Performance optimization success appears as sub-linear cost scaling as you add agents and tasks. Well-optimized systems show decreasing per-agent costs through effective caching and compression. Coordination boundaries success prevents context pollution while enabling necessary information sharing. You see this in specialized agents maintaining their expertise while contributing to team objectives. Conflict resolution success handles simultaneous updates gracefully and maintains system consistency even when agents discover contradictory information. The system should rarely require manual intervention to resolve conflicts. The ultimate measure The true test of multi-agent memory engineering is whether agent teams tackle problems that individual agents cannot solve, at costs that make deployment viable. Success means transitioning from "agents helping humans" to "agent teams solving problems independently"—the difference between tools and teammates. Organizations implementing sophisticated memory engineering will achieve 3× decision speed improvement and 30% operational cost reduction by 2029 (Gartner prediction), demonstrating the strategic value of proper memory architecture. The path forward Memory engineering represents the missing infrastructure layer for production multi-agent systems. Just as relational databases enabled the transition from single-user desktop applications to multi-user web applications, shared memory systems enable the transition from single-agent tools to multi-agent intelligence. The companies succeeding with AI agents today have figured out memory architecture, not just prompt engineering. They understand that agent coordination requires the same foundational infrastructure thinking that built the modern web: persistent state, atomic operations, conflict resolution, and performance optimization. Research validates this approach: Enterprises implementing proper memory engineering achieve 18% ROI above cost-of-capital thresholds (IBM Institute for Business Value) , while systems without memory architecture continue to struggle with the coordination failures that plague 40-80% of multi-agent deployments. Key takeaways Multi-agent systems fail because of memory problems, not communication problems . The real issue isn't that agents can't talk to each other—it's that they can't remember and coordinate state effectively. Memory engineering is the key differentiator for production multi-agent systems . Companies succeeding with AI agents have figured out memory architecture, not just prompt engineering. Individual agent memory patterns extend naturally to multi-agent coordination . The same principles (write, select, compress, isolate) that solve single-agent context problems solve multi-agent coordination problems. Shared external memory is essential infrastructure . Just like databases enabled web applications to scale, shared memory systems enable AI agents to coordinate at enterprise scale. To explore memory engineering further, start experimenting with memory architectures using MongoDB Atlas or review our detailed tutorials available at AI Learning Hub .

September 11, 2025

Next →

Circles Uses MongoDB to Fuel Jetpac’s Rapid Global Expansion

Founded in Singapore in 2014, Circles has grown to become a global telecommunication company revolutionizing the industry with its cutting-edge SaaS platform. Present in 14 countries, Circles empowers telco operators worldwide to launch innovative digital brands and refresh existing ones, accelerating their transformation into ‘techcos’. MongoDB Atlas is at the heart of Circles’ success, enabling one of Circles’ biggest product launches, Jetpac, in 2022. Kelvin Chua, Head of Markets, and Circles' first employee, described Circles’ experience at the recent MongoDB .local Singapore, in July 2025 . During a Fireside session, Chua shared insights into Circles’ journey and his own close relationship with MongoDB. Here’s the full conversation. For the Fireside discussion with Kelvin Chua, skip to 23'40. Before we dive into your work with MongoDB, could you please introduce yourself? Sure. I am currently the Head of Markets for Circles, but I am also their first employee. I've been working in the telco space for more than 20 years, and I've been around the ecosystem of startups a lot, helping build and scale startups. Actually, the first time I used MongoDB was for a startup in the [Silicon] Valley. So you have a pretty long standing relationship with MongoDB. Can you tell us a bit more about that? As I said, my relationship with MongoDB dates back to my start-up days, when MongoDB was still in its infancy. I chose MongoDB to handle about 5 million documents per hour. That was back in 2013. From there, I started looking at how MongoDB scales. Years later, I continued to leverage MongoDB to help build Circles in Singapore, but also for scaling the company globally across Pakistan, Mexico, and other regions. Figure 1. Kelvin Chua, Head of Markets, Circles, speaking at MongoDB.local Singapore in July 2025. How [did] Circles’ journey with MongoDB start? Circles was built on the Community Edition of MongoDB back in 2014 . At the time, our team was using Node.js, and I immediately knew that MongoDB and a NoSQL database model was the right choice to build and scale the business. As a fan of Node.js, it was very natural to feel the ease of using MongoDB. I feel like using Node.js for your workload and then using MongoDB for the backend creates the best tandem. As we transitioned to other development environments and languages, including Golang, MongoDB remained at the core of our database operations, mostly because of its flexibility, the ease of prototyping, and the scalability. We never really saw the need to change from MongoDB as our requirements for a document store are always fulfilled by it. More recently, Circles launched a very successful offering: Jetpac. … This was also built on MongoD, but before we dive into this, can you share more about what sparked the idea for this product? As you know, the COVID-19 pandemic put a hold on all international travel. So when 2022 rolled in, we were expecting a boom in travel again as restrictions eased up. This is when we had the idea for Jetpac, which is basically a travel tech solution providing seamless roaming and innovative travel lifestyle products. You had a pretty challenging timeline to work against, though? Yes! We had a massive challenge because we had six weeks to build Jetpac right from zero. That included solutioning, strategizing, and team-building. Having had ten years of experience working with MongoDB, I knew we needed a NoSQL database, especially to keep track of what people are buying, how they are using the packs, and how to present usage to customers. So Jetpac was built on MongoDB Atlas in just six weeks, in time to launch before the end of year holiday period where international travel was expected to resume. Since then, Jetpac expanded really quickly: revenue grew 500% between January and November 2024, and it is now available in 200 countries. Jetpac is not just a Singapore product anymore—it’s a global brand. Can you explain why you recently decided to move from MongoDB Community to Atlas for your operations in Singapore? Sure. After several years running and scaling the business on MongoDB Community Edition, we decided that it was time to move to MongoDB Atlas because we wanted to optimize efficiencies and reduce operational costs across Circles’ markets, as well as reduce and ease the regulatory compliance risk and burden posed by the Singapore telco industry. It all started when we decided to run an internal comparison to look into how many resources were spent on maintaining our database internally, versus moving to MongoDB Atlas. We realized that we were running very inefficient clusters—many clusters with only about 10% utilization per cluster. That cost goes to the cloud provider. We found that we could aggregate these clusters into MongoDB Atlas to improve utilization and save money. Another main benefit of moving to MongoDB Atlas was the flexibility and productivity that this offered our engineering and developer team. That is something we hear a lot from our customers, how MongoDB Atlas really helps empower their engineering team. How did that show up for you and your team? MongoDB Atlas amplifies everything very fast. It allows engineers to make mistakes in sandbox environments in a way where they don’t get constrained by wondering, ‘What can I break?’ If they make a mistake, they can spin up a new instance and move forward. That is really valuable. Also, with automation and workflows streamlined under MongoDB Atlas, we have really been able to expedite new projects. For example, I was in India a few weeks ago for one of our new Jetpac B2B projects. We were able to shortcut our process by about a week just because contractors could access MongoDB Atlas and select schemas immediately—no delays in consulting environments! What does the future hold for Circles? What are your priorities? What technologies are you investing in? I think AI is really a big priority for us. Actually, some of our users might already have noticed that our app is starting to evolve into a more AI-powered application— we provide predictions, automatic waivers, personalized special offers, and more. As a company, Circles plans to continue leveraging MongoDB as we scale these AI operations, particularly for retrieval-augmented generation (RAG) projects where we want to rely on MongoDB’s vector search capabilities . I love hearing that and am really looking forward to seeing all of these projects come to life! Thank you so much for being with us, Kelvin. Thank you. Learn more about MongoDB Atlas through the learning hub . Visit our product page to learn more about MongoDB Community Edition.

September 11, 2025