Atlassian quiere convertirse en la capa que coordine cómo trabajan juntos personas y agentes de inteligencia artificial dentro de la empresa. Esa es la idea que articula sus principales anuncios en Team’26 Europe, que se celebra en Ámsterdam, y que lleva a la compañía a reorganizar su plataforma alrededor de cuatro elementos: contexto, identidad, permisos y registro del trabajo.
El planteamiento parte de una realidad que Atlassian da prácticamente por asumida. Las grandes organizaciones no van a utilizar un único modelo ni un solo agente. Combinarán sistemas de OpenAI, Anthropic, Google y otros proveedores, junto con herramientas propias y agentes especializados. En lugar de intentar concentrar toda esa actividad dentro de Rovo, Atlassian quiere que esos sistemas puedan acceder al conocimiento de la organización, actuar sobre sus procesos y devolver el resultado a una capa común de gobierno.
Ahí encajan Teamwork Graph, Jira, Confluence, Rovo y la nueva arquitectura que la compañía agrupa bajo el nombre de Agentic Multiplayer Protocol (AMP). La ambición es que, aunque cambien el modelo que razona o el agente que ejecuta una tarea, la organización pueda seguir sabiendo qué información utilizaron, quién inició la acción, con qué permisos actuaron y qué resultado dejaron en sus sistemas.
La estrategia lleva años en construcción, pero la proliferación de agentes amplía ahora su alcance. Teamwork Graph, que hace cinco meses superaba los 150.000 millones de conexiones, alcanza los 250.000 millones de objetos conectados y extiende la información que puede relacionar a conocimiento, trabajo, personas, comunicaciones, activos, código y datos estructurados. Esa base es la que Atlassian quiere utilizar para que agentes propios y de terceros trabajen sobre un contexto común sin perder trazabilidad.
El movimiento concreta varias de las preguntas que quedaron abiertas tras Team’26 en Los Ángeles. Entonces Atlassian presentó su visión de una empresa «AI native», con Teamwork Graph como capa de contexto y los agentes como nueva capacidad de ejecución. Cinco meses después, Team’26 Europe desplaza el foco hacia un problema más operativo: cómo mantener control, memoria y responsabilidad cuando una parte creciente del trabajo empieza a repartirse entre personas y agentes.
AMP no es otro MCP
El nombre puede inducir a una interpretación equivocada. AMP utiliza la palabra «protocol», pero Cannon-Brookes reconoce que no debe entenderse como un protocolo técnico equivalente a Model Context Protocol (MCP) o Agent2Agent (A2A).
Durante un encuentro con medios previo a la keynote de Ámsterdam, lo definió como un «diplomatic protocol»: una forma común de organizar cómo interactúan personas y agentes. AMP se apoya en estándares técnicos existentes, pero Atlassian no plantea publicar una nueva especificación que otros proveedores deban implementar.
La comparación que utiliza Cannon-Brookes es la evolución de las interfaces móviles. Los primeros smartphones obligaron a establecer patrones que hoy parecen naturales, desde cómo desbloquear una pantalla hasta cómo se representa una acción. Atlassian considera que el trabajo con agentes se encuentra en una etapa similar y que las empresas necesitan convenciones para distinguir qué ha hecho una persona, qué ha realizado un agente con identidad propia, cuándo un agente ha actuado en nombre de alguien y cuándo una persona ha trabajado asistida por IA.
Esa distinción empieza a ser relevante cuando el agente deja de limitarse a responder una pregunta. Actualizar documentación, modificar un elemento de Jira, ejecutar código o desencadenar otra acción obliga a conocer quién inició el proceso y quién responde por el resultado.
Atlassian prepara para ello cuentas específicas para agentes y un inventario de identidades no humanas. Los administradores podrán asignar permisos y revocar el acceso de un agente, una aplicación o una cuenta de servicio. En Europa, la compañía también está empezando a desplegar inferencia de IA local, que restringirá determinados procesos con modelos a infraestructura alojada en la UE.
El contexto intenta convertirse en la parte estable
El argumento central de Atlassian parte de que los modelos fundacionales cambiarán mucho más deprisa que el conocimiento de una empresa. Cannon-Brookes explicó que la compañía no pretende vincular Teamwork Graph a un único proveedor y que sus clientes ya combinan modelos de OpenAI, Anthropic, Google y otros actores.
La reciente ampliación de su colaboración con OpenAI encaja en esa arquitectura. ChatGPT o Codex pueden aportar capacidad de razonamiento y ejecución mientras Atlassian proporciona información sobre proyectos, personas, decisiones, código y procesos. El mismo esquema puede utilizarse con Claude, Gemini, Cursor u otros sistemas.
Cannon-Brookes resumió esa posición al relatar la explicación que uno de sus clientes dio para elegir Atlassian: los modelos seguirán cambiando, pero la empresa necesita que su contexto permanezca estable.
La idea responde a una de las cuestiones que Team’26 dejó abierta en Los Ángeles. Si acceder a un modelo potente deja de ser una ventaja exclusiva, una parte del valor se desplaza hacia la información que permite adaptar ese modelo a una organización concreta.
Atlassian sostiene que su grafo mejora un 44% la calidad de las respuestas y reduce un 48% el consumo de tokens en sus pruebas. Son datos internos de la compañía y los materiales facilitados hasta ahora no permiten reconstruir con suficiente detalle la metodología, los conjuntos de evaluación ni hasta qué punto el resultado se mantiene cuando la información de una empresa es incompleta o contradictoria.
Ese límite sigue siendo importante. Un grafo puede encontrar relaciones entre documentos, conversaciones, código y decisiones, pero la calidad del resultado continúa dependiendo de lo que la organización haya registrado.
Más información sin encerrar al agente en Atlassian
La expansión del Teamwork Graph intenta reducir otra limitación: que el conocimiento empresarial está repartido entre docenas de aplicaciones.
El grafo incorpora nuevos conectores con Zoom, Gong, Microsoft Entra ID y Google Identity, mientras Rovo Code Search puede interpretar código hasta el nivel de funciones, símbolos y clases. Los datos estructurados procedentes de lagos y almacenes de datos pasan también a convertirse en un tipo de contexto accesible mediante Atlassian Insights.
Al mismo tiempo, la compañía ha reconstruido Atlassian MCP para ampliar desde unas decenas hasta más de 200 herramientas. Atlassian asegura que el servicio recibe más de 15 millones de llamadas diarias y que la nueva arquitectura puede consumir hasta un 25% menos de tokens en determinadas tareas de Jira y Confluence, de nuevo sobre pruebas internas realizadas con modelos Claude.
El uso que Atlassian observa de MCP indica además que los agentes están pasando de consultar información a intervenir directamente en los sistemas de trabajo. Tamar Yehoshua, Chief Product & AI Officer de Atlassian, explicó en Ámsterdam que aproximadamente un tercio de las llamadas realizadas a través de MCP son ya operaciones de escritura. Es decir, los usuarios no se limitan a recuperar contexto desde otro asistente: utilizan esos agentes para crear o modificar información en Jira, Confluence y otras aplicaciones conectadas.
Eso acerca la discusión al problema que Atlassian quiere resolver con AMP. Cuando un agente externo puede leer contexto empresarial y además modificar trabajo, documentación o procesos, disponer de una conexión técnica deja de ser suficiente. Aparecen cuestiones de identidad, permisos, responsabilidad y auditoría.
Una plataforma abierta por necesidad estratégica
La estrategia también revela dónde considera Atlassian que puede competir.
Cannon-Brookes no espera que las empresas elijan un único modelo ni un único grafo. Tampoco Dave Meyer, responsable global de Jira, plantea que Atlassian deba dominar el IDE, el repositorio de código o cada agente que utiliza un equipo de desarrollo. La compañía quiere convertirse en el punto en el que esas herramientas encuentran contexto y donde el trabajo queda registrado.
Ese planteamiento convierte la apertura en una necesidad estratégica además de una decisión tecnológica. Cuantos más agentes puedan utilizar Teamwork Graph desde fuera de las aplicaciones de Atlassian, mayor puede ser el valor de esa capa de contexto. Y cuanto más trabajo regrese a Jira o Confluence, más información vuelve a alimentar el grafo.
El resultado es un circuito que Atlassian intenta reforzar: el trabajo genera contexto, el contexto mejora a los agentes y la actividad de esos agentes produce a su vez nuevas relaciones, decisiones y resultados que pueden incorporarse a la memoria de la organización.
Cinco meses después de presentar en California su visión de la empresa «AI native», Ámsterdam permite concretar una parte de aquella propuesta. Atlassian no está planteando que Rovo sustituya a todos los asistentes que utilizarán los empleados. Está intentando que, independientemente de qué modelo o agente utilicen, una parte creciente de ellos necesite pasar por el contexto, los permisos y los sistemas de trabajo que controla la compañía.
La cuestión pendiente se desplaza ahora hacia la calidad de esa memoria. Cuanto más dependa un agente del contexto empresarial para actuar, más relevantes serán la información que falta, las decisiones que nunca se documentaron y los procesos que una organización todavía no ha conseguido ordenar.
