A Atlassian quer transformar o Jira de um local onde o trabalho de engenharia é acompanhado num sistema que consegue identificar continuamente tarefas de backlog suficientemente preparadas, entregá-las a um agente de programação, executar testes e devolver um pedido de integração para revisão humana. A nova capacidade Agent loops surge juntamente com contexto entre vários repositórios, controlos de acesso dos agentes, normas de desenvolvimento, revisão automática e medição da utilização.
A mudança importante não é o simples facto de o Jira conseguir chamar um agente. Em julho, a Atlassian já tinha apresentado o Jira Automation como uma camada de coordenação para GitHub Copilot, Cursor e Claude. O anúncio de setembro acrescenta continuidade: o Jira pode procurar repetidamente trabalho elegível sem esperar por uma nova ordem de uma pessoa. A questão deixa, por isso, de ser apenas «o agente consegue escrever este código?» e passa a incluir «que trabalho pode entrar sozinho neste circuito, que informação o agente pode consultar e que decisões continuam reservadas a uma pessoa?».
O primeiro limite está na escolha do trabalho
No anúncio de 10 de setembro, a Atlassian explica que Agent loops procura continuamente tarefas não atribuídas e bem definidas, entrega-as ao Jira Coding Agent, trata da execução e dos testes e abre um pedido de integração pronto para revisão. A decisão de integrar a alteração continua a ser humana.
A expressão «bem definidas» é mais importante do que parece. O primeiro controlo acontece antes de o agente começar a programar. A organização tem de decidir que estados, critérios e tipos de tarefa autorizam a entrada no circuito. Se o backlog for tratado apenas como registo administrativo, uma classificação pouco rigorosa pode transformar-se sem intenção numa autorização para executar trabalho automaticamente.
A anterior expansão do Jira Automation já permitia delegar ações a vários agentes a partir de eventos. A nova função acrescenta um distribuidor persistente que pode voltar a procurar trabalho sem novo pedido. A qualidade do backlog, os critérios de elegibilidade e o tratamento de exceções passam assim a fazer parte do modelo de controlo.
Mais contexto não deve significar mais permissões
A Atlassian também separa duas questões que muitas vezes aparecem misturadas: a informação útil para a tarefa e a informação que o agente está autorizado a consultar. O Code Context, assente no Teamwork Graph, pretende dar ao Rovo e aos agentes de programação uma visão entre vários repositórios. O Agent Context Controls deverá permitir às equipas de plataforma escolher que agentes podem atuar em cada espaço e o que podem ver.
A separação é importante. Mais contexto pode melhorar o planeamento e evitar pesquisas desnecessárias, mas também expõe uma parte maior do código, da documentação e do conhecimento interno. Um sistema controlado precisa, portanto, de responder separadamente a duas perguntas: que informação ajuda nesta tarefa e que informação este agente tem autorização para utilizar?
A Atlassian cita uma análise interna da DX segundo a qual as equipas que usaram mais contexto do Teamwork Graph entregaram cerca de 64% mais por programador. É uma correlação reportada pelo próprio fornecedor, não uma demonstração de que o contexto adicional tenha causado o aumento de produtividade.
As verificações automáticas vêm antes da autorização humana
A função Standards permite associar normas de desenvolvimento da organização aos repositórios. O AI Review verifica depois os pedidos de integração com base nessas normas antes de chegarem a uma pessoa. Um painel no Jira deverá mostrar que agentes estão a ser usados, enquanto o DX for Agentic Development reúne indicadores de adoção, custo, ritmo de entrega e qualidade.
É a sequência destes controlos que torna a arquitetura interessante. O Jira determina que trabalho pode ser enviado; os controlos de contexto limitam a informação disponível; as normas do repositório definem expectativas; uma revisão automática avalia a alteração proposta; e a pessoa mantém a decisão final de integração.
Isso não torna o circuito seguro por si só. Se a mesma regra errada estiver presente na seleção do trabalho, nas normas e na revisão, vários controlos automáticos podem concordar com a mesma decisão incorreta. Para além de acrescentar etapas, uma organização precisa de responsáveis claros pelas políticas, registos auditáveis e um caminho de escalamento quando os mecanismos automáticos discordam.
A disponibilidade continua repartida por várias fases
O estado de maturidade é uma limitação relevante. A Atlassian diz que o Code Context está a chegar gradualmente, em beta aberta, aos clientes pagos. Agent loops, Standards e AI Review continuam em acesso antecipado privado. Agent Context Controls e o painel de utilização deverão chegar aos clientes pagos do Jira nos próximos meses, e o DX for Agentic Development tem disponibilidade geral prevista para este trimestre.
A cobertura independente do IT Pro confirma esta disponibilização faseada. O anúncio deve, por isso, ser lido como uma arquitetura de controlo em construção e não como prova de que grandes equipas já conseguem executar todo o circuito em produção, de forma madura e à escala.
Para quem avalia esta abordagem, a pergunta mais útil não é se o Jira consegue abrir um pedido de integração automaticamente. É saber se a organização consegue tornar explícitos três limites: que trabalho é elegível, que recursos o agente pode usar e que efeitos continuam a exigir autorização humana.
Com estes limites claros e observáveis, agentes persistentes podem retirar coordenação repetitiva sem transformar silenciosamente o backlog numa fila de execução com autoridade mal definida. Sem eles, manter o agente «sempre ativo» apenas faz um modelo de controlo fraco funcionar com maior frequência.