Maven Apps: tus agentes necesitan operadores, no paneles de control

Un panel de interruptores hace exactamente aquello para lo que se cableó: accionas el interruptor y obtienes la misma respuesta fija, siempre. Pídele que gestione algo fuera de ese circuito y no podrá, porque no gestiona la variación, solo el cableado.

Un operador es distinto. Dale una solicitud, como “comunícame con recepción”, y descubrirá cómo resolverla: qué línea usar, qué hacer si está ocupada o si la propia solicitud era ambigua. No se limita a transmitir la señal; la interpreta y actúa en consecuencia.

Las Maven Apps son operadores, no paneles de interruptores. Cuando nos propusimos crear el framework que impulsa nuestra infraestructura de Apps, hicimos una apuesta deliberada: no construir otra capa de integración más, sino una verdadera plataforma de aplicaciones en la que los agentes de IA fueran ciudadanos de primera clase.

Hoy tenemos miles de apps en nuestro framework. Sí, incluye apps para grandes sistemas de terceros como Salesforce, Zendesk y Notion. Pero también incluye cientos de apps personalizadas que funcionan en producción con agentes en vivo.

Por qué las integraciones básicas se quedan cortas

Pregunta a 10 proveedores qué significa “se integra con Salesforce” en su producto y obtendrás 10 respuestas distintas, porque un sistema como Salesforce, Zendesk o Front nunca es una sola cosa. Puede ser:

• Un lugar al que tu agente debe acudir para encontrar información (una base de conocimiento, un historial de casos)
• Un lugar al que tu agente debe acudir para actuar (crear un ticket, actualizar un registro, emitir un reembolso)
• Una interfaz en la que tu agente debe estar presente (un copiloto de asistencia dentro de la consola en la que ya trabaja tu equipo de soporte)

Una “integración con Salesforce” que solo conoce artículos no es el mismo producto que una que además puede abrir un caso, ni el mismo que una que puede funcionar como copiloto dentro de la consola del agente. A menudo se agrupan bajo una misma palabra de marketing, y las carencias las descubres durante la implementación.

Es el problema de la máquina expendedora: un menú fijo que funciona exactamente como se anuncia hasta que lo que necesitas no está en la lista, y para entonces ya te has comprometido. No queríamos que las Maven Apps funcionaran así, de modo que construimos el framework en torno a la pregunta real que se plantea (conocimiento, capacidad o canal) y no en torno a un “conector” genérico.

Maven Apps: más que integraciones

Las Maven Apps pueden adoptar muchas formas, pero la mayoría se basa en unos pocos patrones comunes. Algunos ejemplos de lo que pueden hacer:

• Apps de conocimiento: leen e indexan contenido de un sistema externo para que el agente pueda responder a partir de él: solo lectura, con control de versiones y etiquetable por audiencia.
• Apps de capacidad: permiten que el agente haga algo de verdad en ese sistema: una llamada real a la API, encadenada en un flujo de trabajo de varios pasos (buscar el pedido, comprobar la política de devoluciones, emitir el reembolso y confirmárselo al cliente), todo dentro de una sola conversación. Mientras que un cajero automático ejecuta una transacción predefinida desde un menú fijo, una app de capacidad se comporta más como un asesor bancario personal: recibe un resultado, no una opción del menú, y hace lo necesario para conseguirlo, incluida la gestión de excepciones.
• Apps de canal: sitúan al agente donde ya están tus clientes o tu equipo de soporte: un widget integrado, una llamada telefónica, una bandeja de entrada o un panel de copiloto dentro de la consola que tus agentes usan a diario.

Una app prediseñada de nuestro directorio suele poder instalarse en minutos. Cuando el sistema de un cliente no está en el catálogo, un desarrollador usa el mismo framework, el mismo SDK, los mismos hooks de ciclo de vida y el mismo modelo de seguridad para crear una personalizada.

No existe un nivel “de grado empresarial” del framework que solo usen nuestros ingenieros; App Studio, nuestra plataforma para desarrollar apps, funciona sobre la misma arquitectura. Es TypeScript de verdad, un SDK de verdad (@mavenagi/mavenagi) y un pipeline de despliegue de verdad, no un lenguaje de scripting propietario que tengas que aprender solo para nosotros.

Si ya has trabajado con MCP, una Maven App te ofrece una idea similar, totalmente gestionada. Un servidor MCP estándar implica que tú tienes que levantarlo, registrarlo, mantenerlo en funcionamiento y escalarlo. Una Maven App se parece más a un endpoint MCP que se registra y escala solo, sin nada de esa infraestructura a tu cargo: tú escribes la lógica, y del endpoint, la autenticación y el alojamiento nos encargamos nosotros.

Cómo se diseñan las Apps para ser potentes

Una Maven App es una aplicación serverless que se ejecuta en un entorno seguro y aislado, y se comunica con la plataforma Maven a través de un SDK definido. En concreto:

Es multitenant. Una app se crea una vez y se instala muchas veces, en distintas organizaciones y agentes. Cada instalación tiene su propio contexto acotado (su propio ID de organización, ID de agente y configuración de ejecución), pero comparte el mismo código subyacente. Así, cuando lanzamos una mejora en la app de Salesforce, todos los clientes que la usan se benefician, y nadie se queda atascado con una versión obsoleta y hecha a mano de “su” integración.

Está aislada, no añadida a la fuerza. Cada app se ejecuta como su propia función en un entorno seguro, separada del backend central de Maven y de las apps de otros clientes. Tu lógica personalizada nunca se ejecuta dentro de un monolito compartido junto a la de otro. Las conexiones salientes a tus sistemas de registro pueden ir por VPN, VPC peering, OIDC o HTTPS simple con lista de IP permitidas: lo decides tú, no nosotros.

Reacciona a eventos reales, no a calendarios de sondeo. En lugar de un proceso de sincronización nocturno, una app puede implementar hooks de eventos llamados triggers: se creó una conversación, llegó un comentario, se actualizó una base de conocimiento, y la plataforma avisa a la app en el momento en que ocurre. Es un planteamiento distinto al de las herramientas de automatización que quizá ya conoces. Un trigger de Maven es pasivo: es la propia plataforma la que escucha los cambios de estado y los envía a cualquier app interesada, sin acoplamiento entre la app que provocó el evento y la que reacciona. En la práctica, una app de respuesta por correo electrónico y una app de sincronización con Salesforce totalmente independiente pueden reaccionar al mismo evento de “conversación actualizada” cada una por su lado, sin que ninguna sepa que la otra existe.

Es el mismo mecanismo de coordinación que usa una colonia de hormigas. Ninguna hormiga planifica el comportamiento de la colonia, y ninguna envía mensajes directamente a otra; una hormiga cambia algo en el entorno compartido (un rastro de feromonas) y todas las demás reaccionan a ese cambio de forma independiente, cada una siguiendo su propia regla sencilla. La inteligencia colectiva (rutas de búsqueda de alimento optimizadas, reparto de carga e incluso decisiones colectivas como trasladar el nido) surge de ahí, sin coordinador central y sin que ninguna hormiga conozca el plan. Las Maven Apps se coordinan igual: un evento cambia el estado compartido y cada app interesada reacciona por su cuenta.

Tiene un ciclo de vida real. Cada app implementa un pequeño conjunto de hooks de ciclo de vida:

• preInstall: valida credenciales y configuración antes de que nada entre en funcionamiento. Si tu clave de API es incorrecta, la instalación falla aquí de forma visible, y no en silencio 3 semanas después.
• postInstall: registra las acciones de la app y aprovisiona los recursos que necesite una vez completada la instalación.
• executeAction: ejecuta el trabajo que solicita un agente, expuesto a los clientes como una capacidad: buscar un pedido, crear un caso, emitir un reembolso, consultar el saldo de una cuenta.

La mayoría de las integraciones son un interruptor de luz: encendido o apagado, sin término medio. Las nuestras recorren un ciclo de vida completo de instalación, validación, ejecución y desmontaje, más parecido a una rutina que lee el contexto y se adapta (comprueba qué está abierto, confirma qué es seguro y luego actúa) que a un interruptor de 2 estados. Es justo la disciplina que esperarías de un software de producción, porque eso es exactamente lo que es.

Apps frente a integraciones

Una integración típica responde a una pregunta muy concreta, normalmente “¿pueden llegar los datos de A a B?”, y la trata como la meta. Una Maven App está pensada para responder a una pregunta más difícil y más útil: ¿puede un agente de IA saber con fiabilidad qué es cierto en tus sistemas ahora mismo y se puede confiar en que actúe en tu nombre cuando sea necesario?

La mayoría de las plataformas empresariales ofrecen alguna versión de “créalo tú si no lo tenemos de serie”. Lo que no suelen decirte es que crearlo tú implica gestionar tu propio servidor, tu propio escalado y tu propia revisión de seguridad, en tu propia infraestructura. Eso convierte una simple carencia del catálogo de conectores en una decisión de personal: ¿consigues presupuesto de ingeniería e infraestructura o te limitas a lo que ya viene prediseñado? Con Maven Apps, nuestros clientes no tienen que elegir la opción menos mala. Una app personalizada que creas tú o tu desarrollador se ejecuta en nuestra infraestructura, con la misma monitorización, escalado y nivel de seguridad que cualquier app prediseñada de nuestro directorio. Tú escribes el código; nosotros lo ejecutamos.

Por eso la arquitectura exige cosas de las que un simple webhook nunca tiene que preocuparse:

• Respuestas estructuradas y de tamaño acotado. Cada acción que ejecuta una app devuelve una respuesta clara más datos estructurados sobre los que el agente puede razonar, no un bloque en bruto e ilimitado que tenga que interpretar a ciegas.
• Autenticación mutua y firmada. La plataforma firma cada solicitud a una app para que esta pueda verificar que es realmente Maven quien llama, y la app se autentica ante la plataforma con sus propias credenciales. Ninguna de las partes tiene que confiar solo en la red.
• Configuración validada antes de llegar a producción. Como preInstall se ejecuta antes de que una app entre en funcionamiento, una credencial rota o un ajuste que falta se detecta en la instalación, no la primera vez que un cliente depende de ello.
• Infraestructura real por debajo, no solo una llamada a una función. Como las apps son aplicaciones completas, pueden mantener estado real: una caché, un contador de frecuencia, una pequeña base de datos, no solo una solicitud y una respuesta sin estado. Eso es lo que permite, por ejemplo, controlar si la tasa de resolución de un dominio concreto ha caído más de un 10 % en las últimas 24 horas y avisar a tu equipo cuando ocurra. Una simple llamada a la API no puede retener ese tipo de memoria. Una aplicación real sí, igual que una colonia de hormigas recuerda dónde está la comida aunque ninguna hormiga lo sepa por sí sola.
• Datos sensibles fuera del alcance del modelo. Algunos pasos no deberían pasar por una IA. Cuando un cliente está listo para comprar lo que tiene en el carrito, el agente activa el proceso de pago de la app, y la app recoge los datos de pago y personales directamente del cliente a través de su propia interfaz segura. El agente orquesta el flujo, pero los números de tarjeta y demás información sensible nunca entran en la conversación con la IA.
• Un solo código, todos los clientes, impacto aislado. El multitenant implica que las correcciones y mejoras se publican una vez y llegan a todos, mientras que el aislamiento garantiza que la lógica personalizada de un cliente nunca pueda afectar a la de otro.

Qué significa para ti

Si estás evaluando Maven, la conclusión práctica es esta: cuando decimos que un agente puede responder a una pregunta y actuar en consecuencia, queremos decir que detrás de esa acción hay una aplicación real, versionada, autenticada, aislada y construida sobre el mismo framework, tanto si la ha creado nuestro equipo como el tuyo. Esa es la diferencia entre un agente que puede hablar de tus sistemas y uno que está realmente conectado a ellos.

Creamos Maven Apps porque creemos que eso es lo que “integración” debería haber significado desde el principio.