MongoDB Atlas sirve como la capa de datos operativos unificada para la red intencional basada en agentes, lo que permite a los agentes de IA configurar, supervisar y reparar redes complejas de forma autónoma en tiempo real.
caso de uso: Gen AI
Industrias: Telecomunicaciones
Productos: MongoDB Atlas, MongoDB Search, MongoDB Atlas Vector Search, Voyage AI
Descripción general de la solución
Telecommunications and media are among the industries that lead AI adoption, alongside software and fintech. Yet the gap between leaders and everyone else keeps widening: companies at the frontier of AI capability generate roughly double the revenue growth of their peers, while nearly three-quarters of all companies have yet to show any tangible value from their AI investments. Telecom races ahead on one front in particular — it has the highest rate of agentic AI adoption of any industry. The gap isn't the model. It's everything underneath that agents need to act on live network data:
Pipeline de datos
Búsqueda vectorial
Incrustaciones
Memoria a corto y largo plazo
Procesamiento en tiempo real
La automatización de red basada en agentes cierra esa brecha. En lugar de que los ingenieros traduzcan las solicitudes en configuraciones de dispositivos manualmente, los agentes autónomos interpretan los objetivos, planifican los cambios, actúan en la red y verifican el resultado. IBN es la expresión más clara de este patrón. Usted establece un resultado de red en términos comerciales sencillos, y el sistema lo entrega y lo defiende sin más intervención.
Con IBN, el cliente de un operador describe lo que necesita, no cómo compilarlo. Por ejemplo: Abrir una nueva tienda insignia. Asigne prioridad al tráfico de POS, mantenga el WiFi de invitados estrictamente separado, agregue un enlace ascendente de cámara y mantenga la latencia de POS por debajo de los 40 ms.
Un agente central traduce esa intención en políticas de red, provisiona los servicios y los supervisa continuamente. Cuando la red se desvía de la promesa, el agente diagnostica la causa y aplica una solución por sí solo.
MongoDB Atlas sirve como la capa de datos operativos que impulsa este flujo de trabajo. Consolida todos los recursos que el agente necesita en una base de datos, lo que permite realizar queries en tiempo real en el estado actual de la red, los acuerdos con los clientes, los historiales de eventos y las perspectivas del operador. La capa de IA se conecta directamente a los datos, lo que elimina el bus de mensajes, la caché o los pipelines de ETL. La sección Arquitecturas de referencia muestra cómo funciona este marco en detalle.
Arquitecturas de Referencia
La solución se ejecuta en un único agente respaldado por MongoDB Atlas. La figura 1 muestra los componentes principales:
Un orquestador basado en ReAct
Un enrutador semántico de dos etapas
Un conjunto de microservicios MCP especializados
Colecciones de Atlas que almacenan los datos de la red y la memoria del agente
Cada servicio lee y guarda en Atlas, lo que elimina la necesidad de mantener un bus de mensajes, caché o pipeline de ETL. Esta base es extensible: el mismo orquestador, enrutador y capa de memoria asumen nuevos dominios agregando servicios y colecciones de MCP. Este marco sienta las bases para futuros casos de uso, como un gemelo de red digital para la planificación de la capacidad de qué pasaría si.
Figura 1. El orquestador enruta cada query a través de MongoDB Atlas, que almacena el catálogo de servicios, las colecciones de IBN y la memoria del agente.
Enrutamiento de querys al servicio correcto
A medida que aumenta el número de servicios, el agente necesita una forma confiable de elegir el correcto. El enrutamiento se ejecuta en dos etapas, ambas respaldadas por MongoDB.
Primero, un LLM pequeño clasifica la query en función de una taxonomía corta de dominios, utilizando unas pocas líneas por dominio en lugar de por servicio. Este marco mantiene el enrutamiento preciso a medida que los servicios se multiplican. En segundo lugar, un Atlas $vectorSearch, filtrado al dominio seleccionado, recupera el servicio que mejor coincide. El catálogo de servicios reside en Atlas y las queries se enrutan a través de él.
El ciclo de vida de la intención
Una intención de resultado de red pasa por los siguientes servicios desde una solicitud inicial hasta una resolución final:
Servicio de intención: analiza la solicitud de lenguaje natural en campos estructurados con un LLM. Rastrea el estado de la intención a medida que avanza por las etapas de enviado, factible, planificado, activo, violado y cerrado.
Servicio de inventario: contiene la red física, asignando sitios con coordenadas geoespaciales y los recursos disponibles en cada ubicación. Cuando un sitio necesita un dispositivo de repuesto, encuentra el más cercano disponible con una query geoespacial.
Servicio de viabilidad: compara la intención con el inventario actual, crea un plan de servicio concreto y guarda una snapshot inmutable de ese plan. Cada cambio crea una nueva snapshot, por lo que el historial de planificación completo permanece auditable.
Servicio de garantía: supervisa la telemetría en vivo con respecto a los objetivos acordados. Cuando una métrica supera su umbral, registra un evento de cumplimiento y lo envía al tablero en tiempo real.
Simulador de telemetría: inyecta eventos on-demand, para que pueda probar el ciclo completo de infracción, diagnóstico y corrección en un entorno controlado.
Diagnóstico en una sola query
Las infracciones en vivo crean el momento más exigente. Supongamos que la latencia del punto de venta en la nueva tienda supera su objetivo de 40 ms. En lugar de abrir un ticket, el agente de garantía ejecuta un único pipeline de agregación de Atlas que aplica filtros específicos a la Base de Conocimiento, creando una única query de diagnóstico en cuatro dimensiones:
Similitud semántica:
$vectorSearchencuentra incidentes pasados cuya descripción es la más cercana a la infracción actual, como colisión de cronograma de cola, segmentación estricta de invitados activa, utilización de enlaces baja.Filtro estructurado: limita los resultados a incidentes pasados, de modo que los runbooks y las plantillas de políticas no diluyan la coincidencia.
Ventana de tiempo: excluye incidentes de más de 180 días, de modo que las conclusiones de estados de red anteriores no induzcan a error en los resultados.
Límites geoespaciales: mantenga la búsqueda local, de modo que un incidente en una ciudad no sesgue un diagnóstico en otra.
Estas operaciones se ejecutan como prefiltro dentro del índice de Atlas Vector Search, lo que reduce el conjunto de candidatos antes de que se ejecute el cálculo de similitud. Las respuestas devuelven el incidente pasado más cercano, su causa raíz y su runbook probado juntos. El agente aplica el runbook, registra un evento de recuperación y el tablero se vuelve verde. Un pipeline en Atlas reemplaza múltiples query coordinadas en sistemas separados.
Enfoque de modelo de datos
IBN funciona con diferentes formas de datos, y MongoDB Atlas los contiene todos en un solo lugar. Cada una de las siguientes colecciones se asigna a una parte del flujo de trabajo:
ibn_intents: Almacena la intención analizada y su estado de ciclo de vida. Contiene todos los campos especificados en la solicitud, como el límite de latencia o la política de segmentación.ibn_sites: Contiene los sitios de red con coordenadas de índice 2dsphere para búsquedas geoespaciales.ibn_resources: Contiene los recursos de red disponibles en cada sitio.ibn_policy_snapshots: Almacena snapshots de planes inmutables que conservan el historial de planificación completo.ibn_telemetry. Almacena muestras de métricas en una colección de series de tiempo.ibn_compliance_events: Almacena el registro de cada infracción y recuperación.ibn_knowledge_chunks: Almacena incidentes pasados, runbooks y plantillas, incrustados automáticamente con Voyage AI para búsqueda vectorial.
La memoria del agente también reside en MongoDB, almacenada en colecciones dedicadas junto con los datos de red:
agent_workstreams: Almacena el contexto a corto plazo para el hilo de trabajo actual.agent_memories: Extrae hechos a largo plazo cuando se cierra un flujo de trabajo, con índice de vectores para su recuperación en todas las sesiones.user_preferences: Almacena las instrucciones que el ingeniero enseña al agente.
Un único índice de Atlas Vector Search hace posible la query de diagnóstico cuatridimensional. Con la incrustación automática de Atlas, se apunta el índice a un campo de texto y Atlas genera y almacena las incrustaciones por usted. No necesita un pipeline o servicio de incrustación independiente para ejecutar. Ese mismo índice empareja el campo de texto incrustado automáticamente con filtros estructurados, de tiempo y geoespaciales. Como resultado, una etapa $vectorSearch realiza el trabajo de varios motores de query:
{ "fields": [ { "type": "autoEmbed", "modality": "text", "path": "text", "quantization": "float", "model": "voyage-4" }, { "type": "filter", "path": "kind" }, { "type": "filter", "path": "segment" }, { "type": "filter", "path": "market" }, { "type": "filter", "path": "plan_id" }, { "type": "filter", "path": "ts" }, { "type": "filter", "path": "lng" }, { "type": "filter", "path": "lat" } ] }
Compilar la solución
The full demo is available on this GitHub repository. Clone the repository, then follow these steps.
Establezca sus claves de API
Establezca las variables de entorno para los servicios externos a los que llama la demostración:
OpenAI para el modelo de lenguaje
MongoDB Atlas para la capa de datos
Voyage AI para incrustaciones
export OPENAI_API_KEY="<your openai api token>" export MONGODB_URI="<your mdb connection string>" export VOYAGE_API_KEY="<your voyage api token>"
Configura tu entorno de Python
Instale Python 3.13 y agréguelo a su ruta. Luego, cree y active un entorno virtual. Finalmente, instale las dependencias.
brew install python@3.13 export PATH="$(brew --prefix)/opt/python@3.13/libexec/bin:$PATH" python -m venv <dir> source <dir>/bin/activate cd agentic-mcp-demo pip install -r requirements.txt
Ejecuta el agente y obsérvalo en vivo
Inicie los servidores web y dirija su navegador a http://localhost:8070/ para acceder a la consola interactiva.
./bin/start.sh
Los botones de la navegación superior le permiten:
Introduzca datos de inicialización en las colecciones de MongoDB.
Restablezca los datos para volver a realizar la demostración.
Abra otra ventana del navegador para mostrar el tablero de IBN.
Vea el estado en vivo de los sitios supervisados en tiempo real.
Pruebe un ciclo de vida de intención completo
Desde el chat en el navegador, guíe al agente a través de una intención completa, desde la solicitud hasta la recuperación. El mensaje de violación de diagnóstico activa la query de diagnóstico cuatridimensional.
-I'm opening a new Alpenmarkt store at Marienplatz Munich. POS priority, guest WiFi strictly separated, camera uplink, online by 18:00, max 40ms POS latency, 99.95% availability -feasibility check -propose and activate -inject morning rush -diagnose violation -apply runbook
Lecciones clave
Unifique sus datos en un solo almacenar: mantenga registros de intenciones, sitios geoespacial, telemetría de serie de tiempo y conocimientos índice por vectores en una única base de datos de MongoDB Atlas, que se puede consultar con un driver y un pipeline.
**Recuperar en todas las dimensiones en una query:** Combine la similitud vectorial, los filtros estructurados, una ventana de tiempo y los límites geoespaciales en una sola etapa de Atlas Vector Search, sin orquestación del lado de la aplicación.
Transmita cambios en tiempo real: Utilice MongoDB Change Streams para enviar activaciones, infracciones y recuperaciones de intenciones a los tableros sin sondeo.
Proporcione memoria a su agente: Almacene el contexto a corto plazo, los hechos a largo plazo y las preferencias del usuario como colecciones, de modo que el agente mejore con el uso en lugar de volver a entrenarse.
Automatice el ciclo de vida completo de la intención: permita que un agente analice, planifique, active, asegure y corrija las intenciones de red de extremo a extremo, basándose en datos en vivo.
Autores
Benjamin Lorenz, MongoDB
Aditya Vikram Roy, MongoDB
Diego Canales, MongoDB