MongoDB Engineering: Expanding Our Presence in Greater Toronto

Jackie Denner
September 4, 2025

Toronto has long been recognized as one of North America's fastest-growing tech hubs, boasting a diverse, world-class talent pool and a vibrant startup culture. As MongoDB continues to expand globally, Toronto stands out as a strategic location to drive engineering excellence, foster innovation, and cultivate a collaborative culture. We're currently hiring for three key product areas in the greater Toronto area: Identity and Access Management (IAM), Atlas Stream Processing, and Atlas Search.

At MongoDB, our engineers are empowered to solve complex problems, take ownership of their work, and collaborate with world-class colleagues to build the future of data. As we scale our presence in Toronto, we aim to create an environment where local engineers can grow their careers, work on cutting-edge technology, and have a meaningful impact on the products that enable organizations around the globe to build the applications of today and tomorrow.

Why Toronto?

"Toronto is well known as one of the largest tech hubs in North America. We're constantly looking to attract the most talented engineers to work with, and are really excited about expanding into Toronto, which has previously been untapped," said Kevin Rosendahl, Director of Engineering for Atlas Search and Vector Search.

The decision to invest in Toronto is strategic. According to Tim Sedgwick, Vice President of Engineering for Atlas Stream Processing and App Services, "It enables us to increase engineering capacity responsibly, access high-velocity teams, and establish an innovation hub that mirrors our company’s values. We’re building a long-term hub here, and we want top engineers shaping that foundation with us."

Meet the teams

Identity and Access Management (IAM)

The IAM team at MongoDB is responsible for managing customer identities and access to MongoDB products. "If we're doing our job well, we're making you safe and secure and not getting in your way," said Harry Wolff, Director of Engineering for Atlas IAM. "We own login, registration, SSO for other teams within MongoDB, and provide features like customer federation so large companies can securely log in with their own credentials."

IAM is becoming a key differentiator in MongoDB's ability to land major enterprise customers. "We're going from a means to an end to a concrete dependency that unblocks major enterprise deals," Wolff said. "Our security bar is growing higher, and the work we do actively contributes to signing major contracts. I find that really exciting."

The new team in Toronto will focus on building a new enterprise-grade information architecture. "Right now, one company could have 50-plus organizations in Atlas. We're building an umbrella layer to consolidate resources, configure access at scale, and give customers greater auditability and control," said Wolff. "We're building brand new functionality that enterprise customers are asking for."

Wolff also emphasized career development and growth: "I joined MongoDB as a senior UI engineer, helped start the IAM team, and now I’m a Director. The company invests in its people, and this Toronto team will have the opportunity to grow alongside the product and make their mark."

Atlas Stream Processing

Atlas Stream Processing enables developers to continuously process streams of data using the MongoDB aggregation framework. It simplifies the creation of event-driven applications by eliminating the need for specialized infrastructure, allowing developers to stay within the MongoDB ecosystem.

"Stream Processing is core to powering modern, event-driven applications and delivering value from streaming data," said Tim Sedgwick. "Our goal is to meet developers where they are and make it easy to build with MongoDB."

The product has been generally available for just over a year, and there is a lot of exciting work on the horizon. "Some of the things we're focusing on this year include new sources and sinks, like Kinesis and Apache Iceberg, user-defined functions (UDFs), and distributed processing," Sedgwick said. "We're still early in the product lifecycle, and we're constantly learning from customers to deliver immediate impact."

The Stream Processing team is around 50 people, distributed across the U.S., and now expanding into Toronto. "It's a strategic growth lever for us. We're creating a long-term innovation hub here," Sedgwick said. "Toronto engineers will be shaping the foundation of this product."

Career growth is deeply embedded in the team culture. "I was the founding lead engineer in Austin for Atlas App Services. That experience of helping grow a new engineering hub was invaluable in my career. Now I lead engineering for Stream Processing," Sedgwick shared. "Joining MongoDB in Toronto could be a similar launchpad for someone else's journey."

Atlas Search

Atlas Search and Atlas Vector Search provide developers with built-in, relevance-based retrieval capabilities in the MongoDB database. This eliminates the need to sync data with external search engines, allowing teams to focus on building their applications.

"Search at MongoDB is a fascinating place to be right now," said Kevin Rosendahl. "We're providing cutting-edge capabilities that power AI applications, large-scale systems, and we're making those tools more accessible across all MongoDB deployments."

The team is distributed across major U.S. tech hubs and is now expanding into Toronto. Rosendahl explained, "We look for engineers excited about collaborating on complex, large-scale systems. The goal is to make powerful tools simple and intuitive for developers."

A major focus in the coming year is on integrating capabilities from Voyage AI, a recent MongoDB acquisition. "We're bringing intelligent, AI-powered search out of the box," Rosendahl said. "And we're making sure these tools are available for developers everywhere, whether they use our managed service or deploy MongoDB on their own."

Rosendahl’s own growth at MongoDB reflects the opportunities available: "I started as an individual contributor helping launch Atlas Search. I becamea lead engineer, then a staff engineer on a research team, and now I'm a Director of Engineering. MongoDB has supported my career development every step of the way."

"Our engineers prioritize working together to build the right thing. That creates a culture that values collaboration, communication, and low ego," he added. "We're always looking for the next generation of leaders."

Why join MongoDB?

Joining MongoDB's engineering organization means becoming part of a culture rooted in trust, innovation, and impact. Our engineers are encouraged to take initiative, pursue curiosity, and help shape the future of software development.

"We always look for culture adds—people who make us better, not just the same," said Harry Wolff. "Diversity of perspective and opinions is important at MongoDB."

Whether you're passionate about redefining access control, building intelligent data pipelines, or scaling AI-powered search, MongoDB offers the opportunity to work on industry-defining products alongside some of the most talented and driven people in tech.

"MongoDB can be a defining moment in your career - through the unique set of challenges you’ll solve and the amazing people you’ll work with," said Sedgwick. "Above all, what makes MongoDB great is the people."

Learn more about #LifeAtMongoDB and join us in building the future of data—become part of our talent community today.

Visit our careers page to check out our open roles.

← Previous

The Difference a (Field) Name Makes: Reduce Document Size and Increase Performance

It sometimes feels like I have the perfect job for a software geek who loves to travel. I was recently at a customer event in Greece. During one of the breaks, I joined a group of developers who were having an animated debate on the terrace. The big question was whether it's better to use camelCase or snake_case for field names in MongoDB documents. The first part of my response was that it's mainly a style decision, likely influenced by the conventions of the programming language you're using for your application. The second part was that this decision does have a right answer, and your decision will impact performance. This article will answer that question and demonstrate how other design decisions regarding data representation within a document impact the performance of your application. So which is it— camelCase or snake_case ? How MongoDB stores documents in its cache The MongoDB database has a built-in LRU (Least Recently Used) cache that holds an in-memory copy of recently accessed documents. The documents are stored in BSON format. Let's take this document as an example: { _id: 81873, color: "Red", size: "Small", shape: "Cylinder", props: { edge: 2, face: 3 }, coords: [ 2.2, 5.1] } This is how that document is stored in the cache: Figure 1. A table with a row for each of the fields in the document seen above. For each document, the BSON contains: The type of the field (int32, string, document, etc.). The name of the field. The length of the value (if the field type doesn't have a fixed size). The field's value. Why should you care about document size? The purpose of the database cache is to speed up queries. If the requested document is already in the cache, then the query isn't slowed down by having to fetch the data from disk. The smaller the size of each document, the more documents can fit in the cache (memory isn't infinite). The more documents that fit in the cache, the higher the probability that the document(s) your application requests are already in the cache. Smaller documents also reduce the volume of data that needs to be sent over the network between the database and your application. Optimizing document size I start with a baseline document and find its size. I then step through a number of optimizations, and for each one, I measure how the document size changes. In none of the steps do I reduce how much information is held in the document. Baseline Our initial document has this form: { ... "top_level_name_1_middle_level_name_1_bottom_level_name_1": "Your data goes here", "top_level_name_1_middle_level_name_1_bottom_level_name_2": "", "top_level_name_1_middle_level_name_1_bottom_level_name_3": "Your data goes here", "top_level_name_1_middle_level_name_1_bottom_level_name_4": "", ... "top_level_name_2_middle_level_name_5_bottom_level_name_5": "Your data goes here", "top_level_name_2_middle_level_name_5_bottom_level_name_6": "", "top_level_name_2_middle_level_name_5_bottom_level_name_7": "Your data goes here", "top_level_name_2_middle_level_name_5_bottom_level_name_8": "", "top_level_name_2_middle_level_name_5_bottom_level_name_9": "Your data goes here", ... "top_level_name_10_middle_level_name_10_bottom_level_name_9": "Your data goes here", "top_level_name_10_middle_level_name_10_bottom_level_name_10": "" } The document contains 1,000 fields, all at the top level of the document. Half of the fields contain the string "Your data goes here," while the other half contain an empty string. My collection contains a single document with this structure. I use MongoDB Compass to check the size of this document in the cache (note that the disk copy (Storage Size in the capture below) will be smaller as it's compressed): Figure 2. MongoDB Compass showing that schema 1 contains 1 document with a document size of 72.82 KB. Compass shows that the document size (in memory/cache) is 72.82 KB. This is our baseline measurement. Adding hierarchy For the first optimization, I added extra structure to the document. Rather than having 1,000 fields at the top level of the document, I have 10 fields that each contain 10 sub-fields. Those sub-fields in turn contain 10 fields, all of which are strings: { ... "top_level_name_1": { "middle_level_name_1": { "bottom_level_name_1": "Your data goes here", "bottom_level_name_2": "", "bottom_level_name_3": "Your data goes here", "bottom_level_name_4": "", "bottom_level_name_5": "Your data goes here", "bottom_level_name_6": "", "bottom_level_name_7": "Your data goes here", "bottom_level_name_8": "", "bottom_level_name_9": "Your data goes here", "bottom_level_name_10": "" }, ... "middle_level_name_10": { ... "bottom_level_name_9": "Your data goes here", "bottom_level_name_10": "" } }, ... "top_level_name_10": { ... } } Note that we haven't lost any information from the field names. Instead of having a field named top_level_name_1_middle_level_name_1_bottom_level_name_1 , we have one named top_level_name_1.middle_level_name_1.bottom_level_name_1 (note the "dot notation" used to indicate field levels within the document hierarchy.) A quick check with Compass shows that this more structured document has reduced the document size: Figure 3. MongoDB Compass showing that schema 2 contains 1 document with a document size of 38.46 KB. The more organized document uses 38.46 KB of memory. That's almost a 50% reduction in the size of the original document. That means almost twice as many documents will fit in the database cache. The reason that the document has shrunk is that we're storing shorter field names. No context or information has been lost, and we have documents that are easier for people to understand. Replace empty strings with null 50% of the lowest-level fields contain an empty string. What happens if we store null instead? { ... "top_level_name_1": { "middle_level_name_1": { "bottom_level_name_1": "Your data goes here", "bottom_level_name_2": null, "bottom_level_name_3": "Your data goes here", "bottom_level_name_4": null, "bottom_level_name_5": "Your data goes here", "bottom_level_name_6": null, "bottom_level_name_7": "Your data goes here", "bottom_level_name_8": null, "bottom_level_name_9": "Your data goes here", "bottom_level_name_10": null }, ... "middle_level_name_10": { ... "bottom_level_name_9": "Your data goes here", "bottom_level_name_10": null } }, ... "top_level_name_10": { ... } } Compass shows us a further small reduction in document size: Figure 4. MongoDB Compass showing that schema 3 contains 1 document with a document size of 35.96 KB. The size has been reduced from 38.46 KB to 35.96 KB . The saving comes because we no longer need to store the length or value of the empty strings. Removing null fields The polymorphic nature of MongoDB collections means that different documents in the same collection can contain different fields. Rather than storing fields that contain null values, we can remove those fields altogether (note that querying a missing field yields the same result as querying on one set to null): { ... "top_level_name_1": { "middle_level_name_1": { "bottom_level_name_1": "Your data goes here", "bottom_level_name_3": "Your data goes here", "bottom_level_name_5": "Your data goes here", "bottom_level_name_7": "Your data goes here", "bottom_level_name_9": "Your data goes here", }, ... "middle_level_name_10": { ... "bottom_level_name_9": "Your data goes here", } }, ... "top_level_name_10": { ... } } This means that we no longer have to store those empty fields (including the field names). Compass confirms a notable saving: Figure 5. MongoDB Compass showing that schema 4 contains 1 document with a document size of 25.36 KB. The new document consumes 25.36 KB of memory compared to 35.96 KB for the document with null fields. camelCase vs. snake_case Finally, we get to answer the question as to which is more performant: camelCase or snake_case: { ... "topLevelName1": { "middleLevelName1": { "bottomLevelName1": "Your data goes here", "bottomLevelName3": "Your data goes here", "bottomLevelName5": "Your data goes here", "bottomLevelName7": "Your data goes here", "bottomLevelName9": "Your data goes here", }, ... "middleLevelName10": { ... "bottomLevelName9": "Your data goes here", } }, ... "topLevelName10": { ... } } Compass shows that camelCase has it! Figure 6. MongoDB Compass showing that schema 5 contains 1 document with a document size of 23.53 KB. The new document uses 23.53 KB , which is a 7% saving over the 25.36 KB when using snake_case. In total, the schema changes have reduced the document size by 67.7% . As you've probably figured out by now, camelCase results in smaller documents because the field names are shorter—we no longer have to waste cache space storing thousands of _ characters. Taking it too far In the steps taken so far, no information has been lost. The field names are just as instructive as they were in our original document. If you structure your hierarchy around the natural structure of your data (e.g., have a field representing an address with sub-fields for street number, street name, city...), then the final document is easier for humans to understand than the original. The hierarchy also makes it faster to find documents using unindexed keys. It's a win-win-win. What about taking things to the extreme? If shorter field names mean we can fit more documents into cache, then should we opt for this? { ... "a1": { "b1": { "c1": "Your data goes here", "c3": "Your data goes here", "c5": "Your data goes here", "c7": "Your data goes here", "c9": "Your data goes here", }, ... "b10": { ... "c9": "Your data goes here", } }, ... "a10": { ... } } Compass confirms that it delivers a significant saving: Figure 7. MongoDB Compass showing that schema 6 contains 1 document with a document size of 15.02 KB. At 15.02 KB , this is a 36% saving over the already-optimized document. However, this has come at a cost. The shorter field names have made it much more difficult for people to read the document and understand its contents. Shortening field names can produce smaller documents, which can speed up your application. However, you need to be able to maintain your application, so it doesn't make sense to go too far. Pick names that are concise but still convey the meaning of the field's value. Summary If you'd like to reproduce the results and perform your own experiments, then you can use this MongoDB VS Studio playground to recreate the results: // This is a playground for MongoDB for VS Code Extension. // It creates 6 collections that each contain 1 document. All 6 collections // contain the same information but with different field names. This is to // demonstrate the different ways that MongoDB can store the same data and what // impact your design decisions have on document size (and therefore how many // documents can fit in the database cache → performance). use('FieldNames'); const schema1 = db.getCollection('schema1'); const schema2 = db.getCollection('schema2'); const schema3 = db.getCollection('schema3'); const schema4 = db.getCollection('schema4'); const schema5 = db.getCollection('schema5'); const schema6 = db.getCollection('schema6'); schema1.drop(); schema2.drop(); schema3.drop(); schema4.drop(); schema5.drop(); schema6.drop(); let doc = {}; for (let outer = 1; outer <= 10; outer++) { for(let middle = 1; middle <= 10; middle++) { for(let inner = 1; inner <= 10; inner++) { doc[`top_level_name_${outer}_middle_level_name_${middle}_bottom_level_name_${inner}`] = (inner % 2 !== 0) ? "Your data goes here" : ""; } } } schema1.insertOne(doc); doc = {}; for (let outer = 1; outer <= 10; outer++) { let middleLevel = {}; for(let middle = 1; middle <= 10; middle++) { let innerLevel = {}; for(let inner = 1; inner <= 10; inner++) { innerLevel[`bottom_level_name_${inner}`] = (inner % 2 !== 0) ? "Your data goes here" : ""; } middleLevel[`middle_level_name_${middle}`] = innerLevel; } doc[`top_level_name_${outer}`] = middleLevel; } schema2.insertOne(doc); doc = {}; for (let outer = 1; outer <= 10; outer++) { let middleLevel = {}; for(let middle = 1; middle <= 10; middle++) { let innerLevel = {}; for(let inner = 1; inner <= 10; inner++) { innerLevel[`bottom_level_name_${inner}`] = (inner % 2 !== 0) ? "Your data goes here" : null; } middleLevel[`middle_level_name_${middle}`] = innerLevel; } doc[`top_level_name_${outer}`] = middleLevel; } schema3.insertOne(doc); doc = {}; for (let outer = 1; outer <= 10; outer++) { let middleLevel = {}; for(let middle = 1; middle <= 10; middle++) { let innerLevel = {}; for(let inner = 1; inner <= 10; inner++) { if (inner % 2 !== 0) { innerLevel[`bottom_level_name_${inner}`] = "Your data goes here"; } } middleLevel[`middle_level_name_${middle}`] = innerLevel; } doc[`top_level_name_${outer}`] = middleLevel; } schema4.insertOne(doc); doc = {}; for (let outer = 1; outer <= 10; outer++) { let middleLevel = {}; for(let middle = 1; middle <= 10; middle++) { let innerLevel = {}; for(let inner = 1; inner <= 10; inner++) { if (inner % 2 !== 0) { innerLevel[`bottomLevelName${inner}`] = "Your data goes here"; } } middleLevel[`middleLevelName${middle}`] = innerLevel; } doc[`topLevelName${outer}`] = middleLevel; } schema5.insertOne(doc); doc = {}; for (let outer = 1; outer <= 10; outer++) { let middleLevel = {}; for(let middle = 1; middle <= 10; middle++) { let innerLevel = {}; for(let inner = 1; inner <= 10; inner++) { if (inner % 2 !== 0) { innerLevel[`c${inner}`] = "Your data goes here"; } } middleLevel[`b${middle}`] = innerLevel; } doc[`a${outer}`] = middleLevel; } schema6.insertOne(doc); Learn more about MongoDB design reviews Design reviews are a chance for a design expert from MongoDB to advise you on how best to use MongoDB for your application. The reviews are focused on making you successful using MongoDB. It's never too early to request a review. By engaging us early (perhaps before you've even decided to use MongoDB), we can advise you when you have the best opportunity to act on it. This article explained how designing a MongoDB schema that matches how your application works with data can meet your performance requirements without needing a cache layer. If you want help to come up with that schema, then a design review is how to get that help. Would your application benefit from a review? Schedule your design review .

September 3, 2025
Next →

Multi-Agentic Ticket-Based Complaint Resolution System

In the AI-first era of customer experiences, financial institutions face increasing pressure to deliver faster, smarter, and more cost-effective service, all while maintaining transparency and trust. This blog introduces a multi-agentic architecture, co-developed with MongoDB and Confluent Data Streaming Platform , designed to automate ticket-based complaint resolution. It leverages the AI-native capabilities of both platforms within a real-time event streaming environment. With continuously active agents orchestrated across the entire system, financial institutions can automatically resolve common customer issues in seconds, significantly improving resolution times and boosting customer satisfaction. Specifically, this blog demonstrates the automation of customer complaint handling for a retail bank using a sequence of specialized AI agents. Customers interact through a simple ticket, while behind the scenes, Confluent Cloud for Apache Flink ® powers intent classification, MongoDB Voyage AI -backed semantic search, and contextual reasoning against live customer data to propose resolutions in real time. Structured events flow through a Confluent Cloud for Apache Kafka ® backbone to automate downstream ticketing and update audit logs, with Atlas Stream Processing (ASP) ensuring sub-second updates to the system-of-record database. Business context & challenge Retail banks face an immense operational challenge in managing the sheer volume of customer inquiries they receive on a monthly basis, often numbering in the millions. A substantial portion of these interactions, frequently ranging from 20% to 30%, is dedicated to addressing relatively routine and common issues that could potentially be automated or handled more efficiently. These routine inquiries typically revolve around a few key areas: Card declines or transaction failures: Customers frequently contact their banks when a credit or debit card transaction fails, or when a card is declined. This can be due to various reasons such as insufficient funds, security holds, incorrect PINs, or technical glitches. OTP / authentication problems: Issues related to One-Time Passwords (OTPs) or other authentication methods are a common source of customer frustration and inquiries. This includes not receiving an OTP, OTPs expiring, or difficulties with multi-factor authentication processes when trying to access accounts or authorize transactions. Billing or statement discrepancies: Customers often reach out to clarify charges on their statements, dispute transactions, or report discrepancies in their billing summaries. These inquiries can range from unrecognized transactions to incorrect fees or interest calculations. Addressing these high-volume, routine inquiries efficiently is crucial for retail banks. Streamlining these processes, perhaps through self-service options, AI-powered chatbots, or improved internal tools for customer service representatives, could significantly reduce operational costs, improve customer satisfaction, and free up resources to handle more complex or sensitive customer issues. Current pain points: Long holds or call-backs frustrate customers and drive support costs. The support team must manually sift through past cases and customer records to recommend next steps. Inconsistent audit trails hamper compliance and SLA reporting. Solution overview Our multi-agentic ticket-based complaint resolution system automates first‑line support by orchestrating a series of AI agents, built on MongoDB and Confluent technologies. Why a multi-agentic system? Traditional AI systems often employ a singular, all-encompassing model to handle a broad spectrum of tasks. However, this architecture proposes a more sophisticated and efficient approach: a multi-agentic system. Instead of a monolithic AI, this design breaks down complex responsibilities into smaller, manageable units. Each of these specialized AI agents is dedicated to a distinct, yet crucial, function. This division of labor allows for greater precision, scalability, and resilience within the overall system, as each agent can be optimized for its specific role without impacting the performance of others. This modularity also simplifies debugging and updates, as changes to one agent do not necessitate a re-evaluation of the entire system. Figure 1. Architecture layers & data flow. Architecture overview Ingestion & classification: The initial triage The initial phase of this customer service system is dedicated to efficiently receiving and categorizing incoming customer complaints. This is where raw, unstructured customer input is transformed into actionable intelligence. Ticket (web/mobile) - The customer's voice: This is the primary entry point for customer grievances. Whether submitted via a web portal, a dedicated mobile application, or other digital channels, customers provide their feedback as free-text complaints. This flexibility allows customers to articulate their issues naturally, without being confined to pre-defined categories. The system is designed to handle the nuances of human language, capturing the essence of the problem as expressed directly by the customer. Intent classification agent - Understanding the "why": Technology stack: At the heart of this classification lies a powerful combination of Confluent Flink for real-time stream processing and an LLM ( large language model ). Confluent Flink provides the robust framework necessary to process incoming tickets with low latency, ensuring that customer complaints are analyzed almost instantaneously. The integrated LLM is the intelligence engine, trained on vast datasets of customer interactions to accurately discern the underlying intent behind the free-text complaint. Core functionality: The primary role of this agent is to classify the complaint into specific, pre-defined intents. For example, a customer typing "My credit card isn't working at the ATM" would be classified under an intent like "card not working." Beyond just intent, the LLM is also adept at extracting explicit parameters embedded within the complaint. In the "card not working" example, it would extract the "card ID" if provided, or other relevant identifiers that streamline the resolution process. This automated extraction of key information significantly reduces the need for manual data entry and speeds up the subsequent steps. Semantic retrieval agent - Learning from the past: Technology stack: This agent leverages the advanced capabilities of Voyage AI and Atlas Vector Search . Voyage AI provides sophisticated embedding generation and re-ranking algorithms that are crucial for understanding the semantic meaning of the classified intent. This semantic understanding is then fed into MongoDB Atlas Vector Search, which is purpose-built for efficient similarity searches across vast datasets. Core functionality: Once the intent is classified and parameters extracted, the semantic retrieval agent leverages MongoDB’s Voyage AI and then re-ranks the embeddings to ensure the most relevant matches are prioritized. This process enables the system to efficiently retrieve the ‘N’ most similar past cases or knowledge base entries. This retrieval is critical for two reasons. Historical context: It provides agents (human or automated) with insights into how similar issues were resolved previously, offering potential solutions or precedents. Knowledge base integration: It pulls relevant articles, FAQs, or troubleshooting guides from the knowledge base, equipping the system with immediate information to address the customer's query. This proactive retrieval of information is a cornerstone of efficient problem resolution. Contextual reasoning: Assembling the puzzle With the initial classification and historical context in hand, the system moves to contextual reasoning, where all available data is brought together to formulate the most appropriate resolution. Contextual reasoning agent - The decision maker: Technology stack: MongoDB Atlas serves as the central data platform for this crucial stage. Its flexible document model and real-time capabilities are ideal for aggregating and querying diverse datasets quickly. Core functionality: This agent performs several critical functions: Live data fetching: It connects to and fetches real-time customer profiles and transaction data from various systems. This includes information such as account status, recent transactions, past interactions, and communication preferences. Access to live data ensures that the suggested resolution is based on the most current customer situation. Data merging: The fetched live data is then seamlessly merged with the semantic results obtained from the previous stage (i.e., the relevant past cases and knowledge base entries). This creates a holistic view of the customer's problem, enriched with both their current context and historical solutions. Resolution suggestion: Armed with this comprehensive dataset, the agent applies pre-defined business rules or leverages lightweight LLM prompts to select the best resolution suggestion. These business rules could involve decision trees, conditional logic, or specific protocols for certain complaint types. For more complex or nuanced situations, lightweight LLM prompts can be used to analyze the combined data and suggest a human-like, contextually appropriate resolution. This stage aims to automate as much of the resolution process as possible, only escalating to human intervention when necessary. Execution & eventing: Actioning the resolution The final phase focuses on executing the determined resolution and ensuring that the necessary downstream systems are updated. Resolution execution agent - Turning suggestions into action: Technology stack: This stage uses a scalable and event-driven infrastructure to process the resolution suggestion and convert it into a structured event. Core functionality: This agent takes the suggested action from the Contextual Reasoning Agent (e.g., "issue new card") and converts it into a structured resolution event. This event is a standardized, machine-readable message that contains all the necessary details to trigger the actual resolution in downstream systems. The structured format ensures consistency and interoperability across the ecosystem. Confluent Cloud: Technology stack: Confluent Cloud Core forms the backbone of the eventing architecture. It acts as a high-throughput, low-latency event bus, facilitating the seamless flow of resolution events across the enterprise. Core functionality: Confluent Cloud carries these structured resolution events to various downstream systems. A critical component here is the Confluent Schema Registry, which ensures that all events adhere to governed schemas. This schema enforcement is vital for data integrity and compatibility, preventing errors and ensuring that all consuming systems correctly interpret the event data. The event bus acts as the central nervous system, broadcasting resolution information to all interested parties. Downstream consumer - Closing the loop: This section describes the various systems that consume the resolution events from the Confluent Cloud event bus, ensuring a fully integrated and closed-loop system. Confluent MongoDB Sink Connector: This connector plays a crucial role in maintaining an audit trail and storing detailed resolution information. It efficiently logs all audit and resolution details into MongoDB, providing a historical record of all customer interactions and the actions taken to resolve their issues. This data is invaluable for analytics, reporting, and future system improvements. Confluent MongoDB Source Connector: This connector facilitates closed-loop integrations by streaming any external database changes back into Kafka. This means that if an action taken in a separate, external system (e.g., a manual card activation by a human agent) results in a database change, this change is streamed back into the event bus. This allows other systems within the ecosystem to react to these external changes, ensuring complete synchronization and a truly integrated customer service experience. MongoDB Atlas Stream Processing (ASP): ASP is designed for real-time data processing and updates. It actively listens on Kafka (the underlying technology of Confluent Cloud) for specific status-change events. When such an event occurs (e.g., a card replacement is initiated), ASP processes it and writes low-latency updates back to the Customer Profile collection in MongoDB Atlas. This ensures that the customer's profile is always up-to-date with the latest status of their issue, providing a consistent view for both customers and internal teams. Figure 2. Key benefits & metrics. Why this matters to management Cost reduction & operational efficiency: By automating routine complaint workflows and first-line resolutions, the system significantly reduces call center headcount and manual support costs. Leveraging serverless AI agents and managed services ensures predictable, elastic operational costs that scale with demand rather than fixed staffing. Faster, contextual resolutions with AI: End-to-end AI-assisted decisioning powered by intent classification, semantic search, and real-time customer context drives faster, more accurate resolutions. Personalized outcomes improve customer satisfaction while reducing friction across the support journey. Enterprise-grade observability & compliance: Every decision and action is governed by enforcement via the Confluent Schema Registry schema, time-stamped, and logged in MongoDB Atlas. This ensures a complete audit trail for internal governance and external regulatory audits streamlining compliance without added overhead. Trusted, scalable platforms: Built on MongoDB and Confluent, the architecture uses proven, enterprise-grade platforms for data, events, and real-time AI workflows. This provides reliability, observability, and high availability by default. Future-proof & extensible design: The modular design allows seamless onboarding of new AI agents for emerging use cases like loan servicing, KYC checks, or investment guidance without re-architecting. This adaptability ensures long-term value as business requirements evolve. Competitive advantage through personalization: Delivering intelligent, real-time resolutions is no longer optional, it’s a differentiator. The system enhances customer loyalty and satisfaction by resolving issues instantly, accurately, and in context. Closing thoughts Agentic architectures are going to be a large part of the future of customer service automation, and they require infrastructure that can reason in real time. MongoDB and Confluent provide a proven, production-ready foundation for deploying multi-agent systems that are cost-effective, explainable, and deeply personalized using the latest AI techniques. Whether you're in financial services or another vertical, this reference architecture offers a start for strategic thinking or even a tangible leap forward. Not yet a MongoDB user? Deploy a free instance of MongoDB Atlas and explore how Atlas can power your AI-driven applications with ease. Not yet a Confluent customer? Start your free trial of Confluent Cloud today ! New users receive $400 to spend during their first 30 days. Kickstart your journey with MongoDB Atlas and Confluent by trying out Confluent Cloud + MongoDB Atlas in real-world gen AI use cases with these Quick Starts: Small Business Loan Agent Chatbot on AWS Medical Knowledge Database on Google Cloud

September 4, 2025