Una empresa descubrió que uno de sus equipos había empezado un nuevo proyecto al detectar un aumento inesperado en el consumo de tokens. El trabajo estaba avanzando, los agentes estaban siendo utilizados, pero la actividad no había aparecido todavía en los sistemas con los que la organización gestionaba y supervisaba sus proyectos.
La anécdota, relatada por Tamar Yehoshua, Chief Product & AI Officer de Atlassian, durante Team’26 Europe en Ámsterdam, apunta a un problema que empieza a crecer a medida que los agentes de inteligencia artificial se incorporan al trabajo cotidiano. Herramientas como Codex, Claude Code o Cursor permiten investigar, tomar decisiones, generar código y abrir nuevas líneas de trabajo desde el ordenador de un empleado, sin que necesariamente quede constancia inmediata de todo ese proceso en las aplicaciones corporativas.
Atlassian quiere recuperar esa actividad y convertirla en trabajo visible, trazable y reutilizable por el resto de la organización. Con Agent Sessions, la compañía pretende conectar las sesiones locales y en la nube de los agentes con los proyectos y tareas a los que están relacionadas, conservar parte del contexto generado durante esas interacciones y permitir que los equipos decidan qué actividad debe incorporarse formalmente a sus procesos. Atlassian quiere convertir esas sesiones en una nueva unidad de trabajo.
El cambio afecta directamente al papel de Jira. Durante más de dos décadas, la aplicación ha funcionado principalmente como registro del trabajo que un equipo planifica antes de ejecutarlo. La proliferación de agentes altera ese orden: ahora pueden aparecer investigaciones, decisiones o implementaciones antes de que exista una tarea formal que las represente. Atlassian quiere que sus sistemas puedan recoger también ese trabajo emergente y mantenerlo conectado con el resto del conocimiento empresarial.
El problema va más allá de saber qué está haciendo cada empleado. Durante una sesión con un agente pueden aparecer decisiones sobre arquitectura, excepciones, dependencias o formas internas de trabajar que antes habrían quedado reflejadas en una reunión, un comentario o una revisión de código. Si esa conversación termina almacenada únicamente en un terminal, la empresa puede ganar velocidad y perder al mismo tiempo parte de su memoria organizativa. Esa es la brecha que Atlassian intenta cerrar.
Del ticket a la sesión del agente
Agent Sessions permitirá vincular ejecuciones locales y en la nube con los elementos correspondientes de Jira. Dave Meyer, responsable global del producto, explica que la intención es registrar qué agente y qué modelo participaron, las herramientas utilizadas, el consumo de tokens y un resumen de la interacción, y relacionar esa información con el trabajo que debía realizarse.
La diferencia es importante. Hasta ahora, una integración podía mostrar que un agente había terminado una tarea o había generado una pull request. Atlassian pretende capturar también parte del proceso intermedio y devolverlo al Teamwork Graph.
Meyer identifica ahí una pérdida de conocimiento que empieza a aparecer en los equipos de desarrollo. Durante una sesión con un agente, un programador puede descubrir que una especificación estaba incompleta, decidir que deben modificarse tres componentes en lugar de dos o explicar al sistema una convención interna. Hace unos años, parte de esa información podía aparecer en una reunión, una revisión de código o un comentario. Ahora puede quedarse en una conversación privada entre una persona y un agente ejecutándose en su portátil.
Al incorporar esas sesiones al grafo, Atlassian espera que una decisión tomada hoy pueda convertirse en contexto para el siguiente agente que afronte un problema relacionado.
Sharif Mansour, responsable de IA de la compañía, describe el movimiento como uno de los cambios más profundos realizados en Jira durante sus más de veinte años de historia. La herramienta ha estado orientada fundamentalmente al trabajo planificado. La IA está aumentando la cantidad de trabajo que aparece de manera espontánea y Atlassian quiere que los equipos puedan verlo, decidir qué merece seguimiento y qué debe permanecer fuera del plan.
El elemento de Jira empieza a parecerse a un prompt
La transformación funciona también en la dirección contraria: si Jira registra cada vez más trabajo de los agentes, el propio elemento de trabajo empieza a convertirse en la instrucción que los pone en marcha.
Meyer lo explica con una distinción importante. Los modelos actuales pueden generar código a gran velocidad, pero cada nueva sesión comienza con un conocimiento limitado de la organización. Una persona acumula contexto con cada conversación, documento, decisión o reunión. Un agente necesita que la información relevante vuelva a proporcionársele para cada tarea.
El problema que intenta resolver Atlassian consiste en decidir qué parte de todo el conocimiento de la empresa necesita ese agente en ese momento. Entregarle un manual técnico completo cuando solo necesita las convenciones de TypeScript aumenta el consumo de tokens y puede introducir información innecesaria. El Teamwork Graph debe localizar el fragmento pertinente y Jira proporcionar la definición concreta del trabajo.
«Sometimes the work item is essentially the prompt for the agent», explicó Meyer durante el encuentro con medios en Ámsterdam.
Esta lógica también aparece en Planner, una capacidad todavía en acceso temprano privado que intenta llevar la IA hacia las fases anteriores a la programación. El sistema puede utilizar información del Teamwork Graph para ayudar a elaborar requisitos, especificaciones técnicas y diseños, someterlos a revisión humana y convertir después el resultado en elementos de Jira que puedan asignarse a personas o agentes.
El movimiento responde a otra consecuencia de la automatización que Atlassian ya observa internamente. Si generar código se acelera, el cuello de botella puede trasladarse hacia producto, diseño, definición y revisión. El problema deja de ser únicamente escribir más rápido y pasa a ser decidir con suficiente precisión qué merece construirse.
Los agentes no eliminan el workflow
La imagen de una empresa llena de agentes completamente autónomos encuentra además un límite en la propia visión de Atlassian.
Meyer se muestra escéptico ante la posibilidad inmediata de que las organizaciones operen con grandes enjambres de agentes funcionando sin intervención humana. Incluso los laboratorios que desarrollan los modelos más avanzados tienen dificultades para controlar ese tipo de sistemas, argumenta.
El escenario que considera más probable es más estructurado: un evento activa un agente especializado en clasificación, el resultado pasa a otro capaz de implementar un cambio, una tercera etapa revisa el trabajo y el proceso mantiene puntos definidos de aprobación y control.
Es una forma de autonomía más cercana a automatizar un workflow que a delegar una función empresarial completa.
Esa diferencia ayuda a responder una de las cuestiones que quedó abierta después de Team ’26 en Los Ángeles: dónde está situando Atlassian la frontera entre ejecución automática y responsabilidad humana. Las nuevas funciones permiten ampliar la autonomía, pero la arquitectura que la compañía está presentando conserva identidades, permisos, registros y checkpoints.
AMP, la capa con la que Atlassian organiza la colaboración entre personas y agentes, formaliza esa aproximación. Una acción debe poder atribuirse a una persona, a un agente con identidad propia, a un agente que actúa en nombre de alguien o a una persona asistida por IA.
Más productividad puede significar menos visibilidad
El efecto organizativo es probablemente más importante que el cambio visual de Jira.
Durante años, las empresas han pedido a sus empleados que actualicen herramientas de gestión para que el resto de la organización pueda entender qué se está haciendo. Con los agentes aparece la posibilidad de automatizar parte de esa actualización, pero también el riesgo de que el volumen de actividad crezca más deprisa que la capacidad de supervisarlo.
Una persona puede mantener varias sesiones en paralelo. Un equipo completo puede generar decenas de líneas de trabajo que no existían cuando comenzó el sprint. La velocidad deja de ser suficiente como medida de productividad si el responsable no sabe qué está avanzando, por qué se inició o cuánto está costando.
Atlassian está intentando que Jira absorba esa complejidad y conserve su papel como sistema de registro aunque una parte importante de la ejecución suceda en otra aplicación.
La respuesta a la pregunta que planteaba Team ’26 Europe empieza así a ser más concreta. Los agentes pueden hacer que un equipo avance más deprisa, pero también fragmentan el lugar donde se toman decisiones. El valor de una herramienta como Jira dependerá menos de ser el sitio en el que se realiza el trabajo y más de su capacidad para reconstruir qué trabajo existe, quién o qué lo está haciendo y qué conocimiento debería conservar la empresa cuando la sesión del agente termine.
