Diego Canales

3 results

Multi-Agent Collaboration for Manufacturing Operations Optimization

While there are some naysayers across the media landscape who doubt the potential impact of AI innovations, for those of us immersed in implementing AI on a daily basis, there’s wide agreement that its potential is huge and world-altering. It’s now generally accepted that Large Language Models (LLMs) will eventually be able to perform tasks as well—if not better—than a human. And the size of the potential AI market is truly staggering. Bain’s AI analysis estimates that the total addressable market (TAM) for AI and gen AI-related hardware and software will grow between 40% and 55% annually, reaching between $780 billion and $990 billion by 2027. This growth is especially relevant to industries like manufacturing, where generative AI can be applied across the value chain. From inventory categorization to product risk assessments, knowledge management, and predictive maintenance strategy generation, AI's potential to optimize manufacturing operations cannot be overstated. But in order to realize the transformative economic potential of AI, applications powered by LLMs need to evolve beyond chatbots that leverage retrieval-augmented generation (RAG). Truly transformative AI-powered applications need to be objective-driven, not just responding to user queries but also taking action on behalf of the user. This is crucial in complex manufacturing processes. In other words, they need to act like agents. Agentic systems, or compound AI systems, are currently emerging as the next frontier of generative AI applications. These systems consist of a single or multiple AI agents that collaborate with each other and use tools to provide value. An AI agent is a computational entity containing short- and long-term memory, which enables it to provide context to an LLM. It also has access to tools, such as web search and function calling, that enable it to act upon the response from an LLM or provide additional information to the LLM. Figure 1. Basic components of an agentic system. An agentic system can have more than one AI agent. In most cases, AI agents may be required to interact with other agents within the same system or external systems., They’re expected to engage with humans for feedback or review of outputs from execution steps. AI agents can also comprehend the context of outputs from other agents and humans, and change their course of action and next steps. For example, agents can monitor and optimize various facets of manufacturing operations simultaneously, such as supply chain logistics and production line efficiency. There are certain benefits of having a multi-agent collaboration system instead of having one single agent. You can have each agent customized to do one thing and do it well. For example, one agent can create meeting minutes while another agent writes follow-up emails. It can also be implemented on predictive maintenance, with one agent analyzing machine data to find mechanical issues before they occur while another optimizes resource allocation, ensuring materials and labor are utilized efficiently. You can also provision dedicated resources and tools for different agents. For example, one agent uses a model to analyze and transcribe videos while the other uses models for natural language processing (NLP) and answering questions about the video. Figure 2. Multi-agent collaboration system. MongoDB can act as the memory provider for an agentic system. Conversation history alongside vector embeddings can be stored in MongoDB leveraging the flexible document model. Atlas Vector Search can be used to run semantic search on stored vector embeddings, and our sharding capabilities allow for horizontal scaling without compromising on performance. Our clients across industries have been leveraging MongoDB Atlas for their generative AI use cases , including agentic AI use cases such as Questflow , which is transforming work by using multi-agent AI to handle repetitive tasks in strategic roles. Supported by MiraclePlus and MongoDB Atlas, it enables startups to automate workflows efficiently. As it expands to larger enterprises, it aims to boost AI collaboration and streamline task automation, paving the way for seamless human-AI integration. The concept of a multi-agent collaboration system is new, and it can be challenging for manufacturing organizations to identify the right use case to apply this cutting-edge technology. Below, we propose a use case where three agents collaborate with each other to optimize the performance of a machine. Multi-agent collaboration use case in manufacturing In manufacturing operations, leveraging multi-agent collaboration for predictive maintenance can significantly boost operational efficiency. For instance, consider a production environment where three distinct agents—predictive maintenance, process optimization, and quality assurance—collaborate in real-time to refine machine operations and maintain the factory at peak performance. In Figure 3, the predictive maintenance agent is focused on machinery maintenance. Its main tasks are to monitor equipment health by analyzing sensor data generated from the machines. It predicts machine failures and recommends maintenance actions to extend machinery lifespan and prevent downtime as much as possible. Figure 3. A multi-agent system for production optimization. The process optimization agent is designed to enhance production efficiency. It analyzes production parameters to identify inefficiencies and bottlenecks, and it optimizes said parameters by adjusting them (speed, vibration, etc.) to maintain product quality and production efficiency. This agent also incorporates feedback from the other two agents while making decisions on what production parameter to tune. For instance, the predictive maintenance agent can flag an anomaly in a milling machine temperature sensor reading; for example, if temperature values are going up, the process optimization agent can review the cutting speed parameter for adjustment. The quality assurance agent is responsible for evaluating product quality. It analyzes optimized production parameters and checks how those parameters can affect the quality of the product being fabricated. It also provides feedback for the other two agents. The three agents constantly exchange feedback with each other, and this feedback is also stored in the MongoDB Atlas database as agent short-term memory. In contrast, vector embeddings and sensor data are persisted as long-term memory. MongoDB is an ideal memory provider for agentic AI use case development thanks to its flexible document model, extensive security and data governance features, and horizontal scalability. All three agents have access to a "search_documents" tool, which leverages Atlas Vector Search to query vector embeddings of machine repair manuals and old maintenance work orders. The predictive maintenance agent leverages this tool to figure out additional insights while performing machine root cause diagnostics. Set up the use case shown in this article using our repo . To learn more about MongoDB’s role in the manufacturing industry, please visit our manufacturing and automotive webpage . To learn more about AI agents, visit our Demystifying AI Agents guide .

February 19, 2025

Automate Network Management Using Gen AI Ops with MongoDB

Imagine that it’s a typical Tuesday afternoon and that you’re the operations manager for a major North American telecommunications company. Suddenly, your Network Operations Center (NOC) receives an alert that web traffic in Toronto has surged by hundreds of percentage points over the last hour—far above its usual baseline. At nearly the same moment, a major Toronto-based client complains that their video streams have been buffering nonstop. Just a few years ago, a scenario like this would trigger a frantic scramble: teams digging into logs, manually writing queries, and attempting to correlate thousands of lines of data in different formats to find a single root cause. Today, there’s a more streamlined, AI-driven approach. By combining MongoDB’s developer data platform with large language models (LLMs) and a retrieval-augmented generation (RAG) architecture, you can move from reactive “firefighting” to proactive, data-informed diagnostics. Instead of juggling multiple monitoring dashboards or writing complicated queries by hand, you can simply ask for insights—and the system retrieves and analyzes the necessary data automatically. Facing the unexpected traffic spike Now let’s imagine the same situation, but this time with AI-assisted network management. Shortly after you spot a traffic surge in Toronto, your NOC chatbot pings you with a situation report: requests from one neighborhood are skyrocketing, and an unusually high percentage involve video streaming paths or caching servers. Under the hood, MongoDB automatically ingests every log entry and telemetry event in real time—capturing IP addresses, geographic data, request paths, timestamps, router logs, and sensor data. Meanwhile, textual content (such as error messages, user complaints, and chat transcripts) is vectorized and stored in MongoDB for semantic search. This setup enables near-instant access to relevant information whenever a keyword like “buffering,” “video streams,” or “streaming lag” is mentioned, ensuring a fast, end-to-end diagnosis. Refer to this article to learn more about semantic search. Zeroing in on the root cause Instead of rummaging through separate logging tools, you pose a simple natural-language question to the system: “What might be causing the client’s video stream buffering problem in Toronto?” The LLM responds by generating a custom MongoDB Aggregation Pipeline —written in Python code—tailored to your query. It might look something like this: a $match stage to filter for the last twenty-four hours of data in Toronto, a $group stage to roll up metrics by streaming services, and a $sort stage to find the largest error counts. The code is automatically served back to you, and with a quick confirmation, you execute it on your MongoDB cluster. A moment later, the chatbot returns with a summarized explanation that points to an overloaded local CDN node, along with higher-than-expected requests from older routers known to misbehave under peak load. Next, you ask the system to explain the core issue in simpler terms so you can share it with a business stakeholder. The LLM takes the numeric results from the Aggregation Pipeline, merges them with textual logs that mention “firmware out-of-date,” and then outputs a cohesive explanation. It even suggests that many of these older routers are still running last year’s firmware release—a known contributor to buffering issues on video streams during traffic spikes. How retrieval-augmented generation (RAG) helps The power behind this effortless insight is a RAG architecture, which marries semantic search with generative text responses. First, the LLM uses vector search in MongoDB to retrieve only those log entries, complaint records, and knowledge base articles that directly relate to streaming. Once it has these key data chunks, the LLM can generate—and continually refine—its analysis. Figure 1. Network chatbot architecture with MongoDB. When the system references historical data to confirm that “similar spikes occurred during the playoffs last year” or that “users with older firmware frequently complain about buffering,” it’s not blindly guessing. Instead, it’s accessing domain-specific logs, user feedback, and diagnostic documents stored in MongoDB, and then weaving them together into a coherent explanation. This eliminates guesswork and slashes the time your team would otherwise spend on low-level data cleanup, correlation, and interpretation. Executing automated remediation Armed with these insights, your team can roll out a targeted fix, possibly involving an auto-update to the affected routers or load-balancing traffic to alternative CDN endpoints. MongoDB’s Change Streams can monitor for future anomalies. If a traffic spike starts to look suspiciously similar to the scenario you just solved, the system can raise a proactive alert or even initiate the fix automatically. Refer to the official documentation to learn more about the change streams. Meanwhile, the cost savings add up. You no longer need engineers manually piecing data together, nor do you endure prolonged user dissatisfaction while you try to figure out what’s happening. Everything from anomaly detection to root-cause analysis and recommended mitigation steps is fed through a single pipeline—visible and explainable in plain language. A future of AI-driven operations This scenario highlights how (gen) AI Ops and MongoDB complement each other to transform network management: Schema flexibility: MongoDB’s document-based model effortlessly stores logs, performance metrics, and user feedback in a single, consistent environment. Real-time performance: With horizontal scaling, you can ingest the massive volumes of data generated by network logs and user requests at any hour of the day. Vector search integration: By embedding textual data (such as logs, user complaints, or FAQs) and storing those vectors in MongoDB, you enable instant retrieval of semantically relevant content—making it easy for an LLM to find exactly what it needs. Aggregation + LLM: An LLM can auto-generate MongoDB Aggregation Pipelines to sift through numeric data with ease, while a second pass to the LLM composes a final summary that merges both numeric and textual analysis. Once you see how much time and effort this end-to-end workflow saves, you can extend it across the entire organization. Whether it’s analyzing sudden traffic spikes in specific geographies, diagnosing a security event, or handling peak online shopping loads during a holiday sale, the concept remains the same: empower people to ask natural-language questions about complex data, rely on AI to craft the specialized queries behind the scenes, and store it all in a platform that can handle unbounded complexity. Ready to embrace gen AI ops with MongoDB? Network disruptions will never fully disappear, but how quickly and intelligently you respond can be a game-changer. By uniting MongoDB with LLM-based AI and a retrieval-augmented generation (RAG) strategy, you transform your network operations from a tangle of logs and dashboards into a conversational, automated, and deeply informed system. Sign up for MongoDB Atlas to start building your own RAG-based workflows. With intelligent vector search, automated pipeline generation, and natural-language insight, you’ll be ready to tackle everything from video streams buffering complaints to the next unexpected traffic surge—before users realize there’s a problem. If you would like to learn more about how to build gen AI applications with MongoDB, visit the following resources: Learn more about MongoDB capabilities for artificial intelligence on our product page. Get started with MongoDB Vector Search by visiting our product page. Blog: Leveraging an Operational Data Layer for Telco Success Want to learn more about why MongoDB is the best choice for supporting modern AI applications? Check out our on-demand webinar, “ Comparing PostgreSQL vs. MongoDB: Which is Better for AI Workloads? ” presented by MongoDB Field CTO, Rick Houlihan.

February 5, 2025

Leveraging an Operational Data Layer for Telco Success

The emergence of 5G network communication, IoT devices, edge computing, and AI have accelerated structural changes within the telecommunications industry, creating new needs and opportunities. To remain competitive, telcos must embrace this technology-driven transformation by defining a robust data strategy. Such a strategy should enhance operational efficiency and provide unique value to customers, and should ultimately enable telcos to set themselves apart from their competitors. All of this can be attained by leveraging an operational data layer (ODL) with MongoDB. Operating a consolidated ODL opens new business opportunities that telcos can incorporate into their value matrix, including customer support systems, AI-enriched applications, and IoT-oriented services. These unlocked capacities will help telecommunications companies succeed in a competitive market. Understanding the operational data layer An ODL is an architectural pattern that centrally integrates and organizes siloed enterprise data, making it available to consuming applications. It acts as an intermediary between data producers and consumers. This architecture pattern is illustrated below: Figure 1. ODL sample reference architecture, using MongoDB In this diagram, MongoDB Atlas acts as the ODL, centrally integrating siloed data from multiple sources, including CRM, HR, and billing. Initially, data is extracted to the ODL, transformed according to established requirements, and then loaded to the MongoDB database. By means of delta loads, the ODL is kept in sync over time. Consuming applications, both operational and analytical, access the ODL through an API layer, which delivers a common set of methods for users, and enforces security standards throughout the organization. Enhancing operational efficiency with MongoDB and the ODL At its core, implementing an ODL with MongoDB provides access to a rich document model and a data developer platform that boosts operational efficiency and unlocks the value of previously siloed enterprise data. The ODL attains this efficiency through a set of key capabilities inherent to MongoDB. The ODL benefits from the flexibility of the document model that adapts its schema to any application requirement while supporting multiple data structures. This polymorphic structure allows variations from document to document liberating applications from rigid schemas and supporting merging from non-identical entities. Telcos gain speed in development—which translates to better performance—when accessing data through an ODL, as they avoid costly join operations required by legacy applications. MongoDB provides a unique place for data storage that can be accessed in a single database operation decreasing end-user response times. Telcos can leverage MongoDB’s versatility to cast multiple workloads, store any data type, and to adopt a rich query language that executes complex operations. Subsequently, the ODL accepts sophisticated query pipelines capable of processing text, images, videos, geospatial data, facet search, analytical transformations, time series, and more. Horizontal and vertical scalability empowers telcos to receive large data volumes and high traffic loads essential for modern applications. This mechanism is achieved through sharding, a process that partitions and distributes data across multiple nodes, accommodating fluctuating workload demands and enhancing overall system performance. An ODL running in MongoDB Atlas benefits from a multi-cloud strategy that allows deployments across multiple cloud providers. This approach mitigates vendor lock-in risks, grants global coverage, and adapts to infrastructure requirements—ensuring that applications adhere to cost constraints, achieve performance benchmarks, and maintain regulatory compliance. MongoDB provides a robust security framework for storing and managing sensitive data due to its built-in tools—including encryption, authentication, authorization, network security, and auditing—thus protecting data against information breaches. It also complies with important international regulations for telcos like the General Data Protection Regulation (GDPR) and the Payment Card Industry Data Security Standard (PCI DSS). MongoDB provides a modern data platform designed to build, manage and scale applications in a unified developer experience. The developer platform fosters innovation allowing developers to access a variety of features to manage their ODL including Atlas Vector Search, Atlas Monitoring, and Atlas Triggers, among others. Refer to our official documentation to learn more about MongoDB Atlas . Using the ODL to gain a competitive advantage Fostering operational efficiency through an ODL is the initial step toward opening a new business that will eventually translate into a competitive advantage. Accordingly, telcos need to develop their own strategies and capitalize on the benefits from these unlocked opportunities, differentiating themselves in the industry. Well-known telcos have already leveraged this approach, creating successful business outcomes. They consolidate single-view instances , concentrating information from different business lines—such as mobile, fixed lines, broadband, and TV/entertainment—into MongoDB Atlas. This environment is well-suited for building personalized customer management solutions, overcoming challenges with siloed data environments. These telcos choose MongoDB because it offers a flexible data model that facilitates data aggregation and horizontal scaling, allowing them to efficiently leverage customer data to build customer-centric applications. Additionally, leading telcos are leveraging AI to enhance their operations, safeguard their business, and improve their services. One prominent use of AI is fraud detection and prevention . This is a critical area that, if poorly managed, can lead to negative consequences like financial losses, unmeasurable reputational damage, and unhinged security network risks. A consolidated ODL serves as a gateway for implementing fraud detection measures. Nowadays, MongoDB’s platform is ingesting and storing terabytes of data from multiple platforms to leverage AI models, potentially saving millions of dollars for telcos. Refer to our ebook, Innovate with AI: The Future Enterprise , to learn more. Telcos are also capitalizing on their networks and the MongoDB ODL by effectively managing the vast amounts of data generated by IoT devices, and adding new end-to-end services. MongoDB is helping large telcos effectively implement IoT platforms supplying scalability for growing device demand, flexibility to manage data model changes, and automatic data tiering to reduce storage costs. These capabilities ultimately improve customer experiences and speed time to market for new applications. Furthermore, ODLs improve product catalog management systems, which are increasingly common in the industry due to telcos’ expanding their offering to a broader set of products, from phone plans to bundled entertainment services. ODLs upgrade the product catalog, allowing for real-time product personalization and analytics. MongoDB assists telcos in upgrading their product catalog systems, enabling advanced search capabilities, reducing development time, and supporting seasonal workload demand. Refer to our white paper, Implementing an Operational Data Layer for Product Catalog Modernization , to learn more. Finally, an ODL accelerates the modernization of monolithic relational database systems that struggle to manage exponential data growth and to adapt to evolving business needs. Telcos use MongoDB in their modernization efforts to deliver 3 to 5x faster operations, allowing scaling to millions of records per day, while at the same time reducing their costs—typically by 50% or more. Future directions This blog highlights how implementing an ODL with MongoDB can unlock telcos’ ability to achieve operational efficiency through the native capabilities of MongoDB and its cloud offering. This innovative architecture not only improves operations, but also unlocks business opportunities that are the foundation for new competitive advantages. These enhanced capabilities represent the backbone to consolidate telcos’ strategic positioning, ultimately differentiating from their competitors in powerful ways. Visit our MongoDB for Telecommunications solutions page to learn more. If you would like to learn more about implementing an ODL with MongoDB for your TELCO organization, visit the following resources: White paper: Implementing an Operational Data Layer White paper: Unleash Telco Transformation with an Operational Data Layer Head over to our quick-start guide to get started with Legacy Modernization today.

January 14, 2025