MongoDB Builder Blog
Deep dives into technical concepts, architectures, and innovations with MongoDB.
Agent Observability: Monitoring Decisions, Not Requests
Observability is the practice of making a system’s internal behavior legible from the outside—capturing enough signal that an engineer can reconstruct what happened and why. For a web service, that signal is the request: a status code, a latency number, a stack trace when something throws. For an agent, the unit of behavior is a decision: the choice it makes between one call and the next. The agent reads context, chooses an action, calls a tool or a model, observes the result, and chooses again.
How We Used AI to Bring MongoDB to DynamoDB
Amazon has a history of favoring customer choice, and ExtendDB is another signal of that: an open source, pluggable adapter built specifically so DynamoDB workloads can run in more environments. At MongoDB, we also believe that everything starts with serving the customer well, so we work backwards from there. This is why we built a MongoDB storage backend for ExtendDB, AWS's open source DynamoDB-compatible adapter, which is ready for use today.
Building E-commerce AI Agents on MongoDB with CrewAI
AI-powered shopping agents are becoming a real differentiator for e-commerce teams. A 2026 Stord report on AI in e-commerce revealed a 34% year-over-year increase in the number of consumers who reported using generative AI for online shopping. The trend is even more pronounced among younger consumers: 37% of Gen Z and 29% of Millennials actively use AI to shop online. After seeing how the agentic commerce journey actually works, it's not hard to understand why.
Agent Memory Inside the Harness
Four posts on this blog have already covered what agent memory is: the memory hierarchy[1], why multi-agent systems need memory engineering[2], how to build a memory-augmented agent[3], and how to give one long-term memory with LangGraph[4]. This post takes the layer beneath them. It is about what memory becomes once it has to run in production—compacted alongside tool schemas and reasoning traces when the context window overflows, versioned and governed like any other production artifact, fed from enterprise systems no one is going to migrate, and access-controlled down to the individual unit.
How Palo Alto Networks Built a Zero-Downtime, Multi-Region SASE Health Portal with MongoDB Atlas
This guest blog post is from Kunal Kannav, Principal Site Reliability Engineer for Palo Alto Networks—a global cybersecurity leader delivering best-of-breed platforms, world-class threat intelligence and expert services to deliver what’s next in cybersecurity.
Agent Orchestration and Tool Use: The Machinery Underneath
The MongoDB blog has made the case for bounded autonomy1, and cataloged the design patterns that produce safe agents2. Earlier entries in this series introduced the harness, the layer of code and configuration around the model that determines whether an agent works in production. A recent formal definition of the agent harness3 names four elements: an agent loop, a tool interface, context management, and control mechanisms. The control mechanisms are where the concerns in this post live. This entry covers the layer those design patterns sit on top of—the runtime loop itself, and the machinery that determines whether the loop survives contact with production. Framework, harness, orchestration, and platform name four distinct layers, and this post is about the third. Architects and platform builders evaluating that layer will find four questions at the end for auditing an existing one.
Practical Guide: CPU Utilization and Network Compression in MongoDB
When operating at scale, even a highly optimized MongoDB deployment can face pressures during peak traffic. In this controlled exercise, we set out to systematically evaluate how different network compression algorithms impact CPU utilization, throughput, and bandwidth consumption under realistic production workloads.
How Auto-Generating Terraform Improved Our APIs and Customer Experience
Enterprise infrastructure increasingly runs declaratively. If a new capability is not available through the Infrastructure as Code (IaC) tool a customer has standardized on, it does not exist for the part of their organization responsible for shipping it to production. For the MongoDB Atlas customers we serve, that tool is overwhelmingly Terraform. And the gap between an Atlas API shipping and the matching resource appearing in the MongoDB Atlas Terraform Provider was four to ten weeks, a function of both the code development required per resource and the bandwidth our team had to maintain the provider alongside competing priorities. Given how central Terraform is to how customers consume Atlas, we wanted it to be a first-class delivery target for new features.