La visión de la plataforma abierta de HubSpot para la era de los agentes

El CRM «headless» no se trata aquí como una preferencia arquitectónica de nicho, sino como un cambio realmente importante en el lugar donde se desarrolla el trabajo. Si el sistema de registros puede leerse y gestionarse desde fuera de su propia interfaz, entonces la interfaz deja de ser el producto y pasa a ser una superficie más entre muchas. HubSpot afirma que ya lo vio venir: dice que fue el primer CRM en lanzar un servidor MCP, en abril de 2026, en un momento en el que la mayoría de los presentes ni siquiera había oído hablar del MCP. Hay un toque irónico en el relato: por aquel entonces, la tarea consistía en dar a conocer el protocolo, mientras que «hoy en día todo el mundo lo conoce».

La explicación que se ofrece del MCP —el Model Context Protocol— es deliberadamente poco glamurosa: se trata de «un lenguaje común para que los agentes se conecten con cualquier cosa», el puerto USB-C de la era de los agentes. Si tu dispositivo tiene el puerto, lo conectas y ya está. Ese enfoque es importante, porque replantea la integración, pasando de ser un proyecto de ingeniería a medida a algo más parecido a un estándar de conexión.

Ahora hay tres vías que llevan a los agentes a HubSpot: el servidor MCP, una capa de SDK orientada a los agentes y un conjunto de API REST en constante expansión. Y el servidor MCP se describe explícitamente como «solo el principio»: se indica que la compatibilidad nativa llegará en un par de meses. Cuando un socio aporta su propio agente y su propio servidor MCP, ese agente puede conectarse y utilizarse; HubSpot proporciona el lenguaje común y el servidor.

Ampliación del «Builder»: los tres niveles de desarrollo

Democratizar la creación de aplicaciones no es lo mismo que pretender que todo el mundo sea ingeniero. El modelo presentado está estructurado en niveles, y la honestidad de esta clasificación es lo que lo hace útil. En el primer nivel se encuentra Breeze Assistant, que permite crear aplicaciones dentro del propio HubSpot: es fácil de usar, sencillo de implementar y cuenta con una gobernanza y una seguridad claras, ya que se heredan en lugar de inventarse. Un paso más allá en complejidad se encuentran los constructores de terceros, como Lovable, para quienes desean un mayor control sobre la interfaz que están creando.

Los desarrolladores profesionales siguen teniendo un papel destacado, y la ponencia principal deja claro cuándo son la respuesta adecuada: cuando una solución debe ser escalable, cuando es realmente compleja o cuando tiene que perdurar. La distinción que se establece es entre el software que tiene que durar y el que simplemente tiene que ayudar.

«No todo lo que merece la pena crear necesita eso. Si puedes resolver los problemas de tu equipo hoy mismo, eso ya es un valor».

Breeze Assistant ya puede crear vistas personalizadas, y la nueva funcionalidad mostrada en el escenario —actualmente en beta privada — consiste en crear páginas de aplicaciones basadas en datos de CRM. La demostración partió de la situación más habitual que se pueda imaginar y dejó que se desarrollara de forma natural. Un responsable de ventas pregunta a Breeze qué operaciones se van a cerrar este mes y no se han revisado en las últimas semanas. Muy útil. Luego vuelve a preguntar al día siguiente, y al otro. En ese momento, la pregunta deja de ser una simple consulta y se convierte en un producto: si la haces a diario, es probable que tu equipo la necesite como vista compartida.

Así que el responsable le pide a Breeze que cree un panel de control que muestre todas las operaciones que se cerrarán este mes con la última actividad de cada una. Lo que sigue es la parte que normalmente se omite en las demostraciones y que, en realidad, es la más importante: el proceso de instalación y permisos. El usuario instala la aplicación para activarla, y ese paso de instalación es lo que permite a la aplicación actuar en nombre de quien esté viendo el panel de control. La conexión se realiza mediante OAuth, considerado el método más seguro para mantener conexiones API.

Compartir funciona de la misma manera: un compañero debe instalar la aplicación antes de poder ver el panel de control y, lo que es más importante, no hereda la perspectiva del creador. Si un administrador crea un panel de control que abarca datos de todo el CRM, los demás usuarios no ven lo mismo que el administrador: cada persona recibe su propia vista filtrada según sus permisos. El creador se centra en el problema empresarial; los permisos, la gobernanza y la auditabilidad se gestionan en segundo plano.

La gobernanza de aplicaciones, anunciada este año, ofrece a los administradores cuatro controles: qué aplicaciones se aprueban para la cuenta, a qué datos pueden acceder esas aplicaciones, qué usuarios y equipos pueden utilizarlas, y la reversión completa sin necesidad de limpieza manual. La demostración utilizó una implementación típica de conectores —los conectores son aplicaciones a nivel de usuario que la mayoría de las personas de una cuenta instalarían, con MCP leyendo y escribiendo en los datos—.

• Paso uno: una prueba piloto limitada. Aprobar el conector para un puñado de usuarios y limitar el acceso a contactos, empresas y oportunidades de venta, con más de 90 permisos adicionales disponibles para su aprobación posterior. Solo los usuarios aprobados pueden instalarlo desde el marketplace; el resto puede enviar una solicitud de acceso, lo que convierte convenientemente la demanda no satisfecha en una señal que los administradores pueden interpretar.
• Paso dos: ampliar a los equipos. Extenderlo a equipos enteros, como los de operaciones y ventas, y abrir más objetos del CRM. Los tickets, las líneas de tiempo, los archivos y HubDB cuentan ahora con permisos de lectura y escritura independientes, y se han prometido permisos más detallados en los próximos meses.
• Paso tres: conceder permisos de escritura. Añade permisos de escritura en objetos específicos una vez que se haya ganado la confianza. Es, en palabras del ponente, «algo importante, pero que abre las puertas a muchísimos casos de uso».
• Estado final: a nivel de cuenta. Habilitar el conector para todos, habiendo llegado a ese punto de forma deliberada y no por defecto.

La ambición declarada para lo que viene a continuación es sencilla de expresar, pero exigente de cumplir: cada agente debería poder manejar HubSpot con las mismas capacidades que tiene un usuario en la interfaz. Ni un subconjunto reducido de la API, ni un reflejo de solo lectura: paridad. El escenario que se deriva de ello es gestionar todo el ciclo de vida de la comercialización desde el agente que elijas, con flujos de trabajo de ventas, atención al cliente y marketing en marcha simultáneamente.

Se han anunciado tres ampliaciones. El entorno de HubSpot que se está creando para agentes, desarrolladores de soluciones para agentes y proveedores de extensiones sigue creciendo. Las áreas en las que los agentes pueden operar se están ampliando: más páginas y paneles personalizados, y más formas de incorporar datos. Además, la cartera de plataformas de terceros con las que se puede conectar sigue ampliándose, de modo que los agentes ven el contexto en tiempo real y permanecen conectados con los sistemas que los equipos ya utilizan.

La gobernanza se adapta a la autonomía en lugar de ir a su estela: ámbitos más granulares, políticas más detalladas y controles de ámbito a nivel de equipo y de usuario. El objetivo declarado es que las organizaciones puedan «adoptar la IA con confianza sin comprometer la seguridad». En este segmento no se detallaron los plazos ni la disponibilidad de estas interfaces ampliadas, los conectores y los controles de ámbito; conviene considerarlos como una línea de actuación más que como un calendario de lanzamiento.