Agentes Gerenciados Agora Respondem ao Harness

Às quatro da tarde, a sessão do Claude Code de um desenvolvedor abre uma sessão de trabalho na Billing API para adicionar cobrança proporcional às mudanças de plano. Vinte minutos depois, enquanto essa sessão ainda está trabalhando, uma execução agendada do Archyl com o perfil backend-fixer pega um ticket sobre arredondamento de faturas, que também fica na Billing API.

Até esta semana, era isto que a execução agendada fazia. Ela abria a própria sessão de trabalho, como as execuções gerenciadas já faziam. O gate de preflight retornava warn, com o motivo 1 target element(s) are being worked on by other active sessions — coordinate before changing them. Esse veredito aparecia no feed de eventos da execução. Depois a execução começava mesmo assim, porque nada agia sobre o veredito, e ninguém estava acompanhando uma execução agendada com quem se coordenar.

Prefiro dizer com todas as letras: nas execuções hospedadas, o envoltório era quase só cosmético. O gate era exibido e ignorado. Os arquivos que o agente alterava nunca eram ligados à sessão dele, então a memória ia parar nos elementos que o texto da tarefa por acaso mencionava. E a sessão fechava com um resumo de uma linha, que deixava muito pouco para o próximo agente aprender.

Isso mudou esta semana. O harness agora conduz as execuções gerenciadas, e execuções hospedadas e agentes de código locais se coordenam sobre o mesmo modelo.

Rodar um agente está virando a parte fácil

Três dos maiores nomes da área agora oferecem um lugar hospedado para agentes rodarem. A documentação da Anthropic descreve o Claude Managed Agents como "um harness de agentes pré-construído e configurável que roda em infraestrutura gerenciada", com sandboxes na nuvem ou self-hosted, sessões persistentes e execuções agendadas via cron. A Agents API da OpenAI, anunciada em beta pública em 10 de setembro, roda o loop do agente na infraestrutura da OpenAI e cuida de "orquestração, sessões de longa duração e gerenciamento de contexto". O Cursor Projects, anunciado no mesmo dia, coloca um agente coordenador em uma máquina própria na nuvem, que delega a subagentes e pode rodar em um agendamento ou acompanhar suas pull requests.

São bons produtos, e apontam para o mesmo lado: sandbox, loop de tools, sessões e agendamentos estão virando algo que você escolhe de uma lista.

O que um runtime não consegue saber sozinho é o seu sistema. A qual container o código de faturas pertence. Quem é o dono dele. O contrato de que seus consumidores dependem. A decisão que tornou uma fronteira intencional. E a parte que importa quando ninguém está olhando: qual outro agente, incluindo os que esse runtime não iniciou, está trabalhando em qual parte dele agora.

Esse conhecimento não pode morar em um runtime, porque seus agentes não rodam todos no mesmo. Alguns rodam em um laptop, outros na CI, outros em um worker hospedado. Então o nosso jeito de ver é: seu runtime, nossa arquitetura. Seja o que for que roda o agente, o modelo ao qual ele responde é o mesmo.

As execuções gerenciadas de agentes do Archyl, lançadas em abril, são um runtime entre esses. Esta semana elas começaram a se comportar como um. Você também pode acompanhar e orientar uma execução ao vivo.

Uma execução agora pode ser recusada, com o motivo

A coordenação é opcional. Cada perfil de agente tem uma nova configuração em Coordenação, Respeitar o trabalho de outros agentes, desativada por padrão. Com ela ativada, a execução abre sua sessão de trabalho em modo exclusivo, e o veredito do gate decide o que acontece em seguida.

Se outro agente tem uma reserva nos mesmos elementos, a execução é recusada, seja esse agente o Claude Code no laptop de alguém ou outra execução gerenciada. A execução termina antes de qualquer coisa ser clonada, o evento do gate mostra Execução recusada, e o motivo diz quem está trabalhando ali e em quê. Para aquela tarde lá do começo:

session denied by preflight gate: "Billing API" is being worked on by
claude-code/vincent (add proration to plan changes)

O formato é o real; a tarefa é um exemplo. Quem lê a execução de manhã sabe exatamente com quem falar.

Se o gate só alerta, por exemplo porque um guardrail de nível error se aplica à tarefa, a execução nem começa nem falha. Ela espera em Aguardando aprovação sem ocupar nenhuma das vagas de concorrência da sua organização. A página da execução lista os motivos, com Aprovar e iniciar e Cancelar execução.

Aprovar não carimba o veredito antigo. O gate é avaliado de novo, então se um agente local pegou uma reserva nesses elementos enquanto a execução esperava, a execução aprovada continua sendo recusada. Uma execução que ninguém aprova em 24 horas é cancelada.

Por que uma execução em espera não segura nada

Enquanto uma execução espera, a sessão dela é descartada. A sessão que levantou o alerta é cancelada, as reservas vão junto, e a aprovação abre uma nova. Manter as reservas pareceria mais cuidadoso e seria pior: uma execução que ninguém nunca aprova manteria todos os outros agentes longe desses elementos por um dia, dizendo a cada um deles que havia algo trabalhando ali quando não havia nada.

Isso segue uma linha que traçamos em agosto. Reservas são consultivas, não locks. Exclusividade é algo que um perfil pede, não algo que a plataforma impõe, e uma execução esperando por uma pessoa não reivindica nada.

O Guard foi para dentro do worker

A sessão cobre a intenção. O Guard cobre o que é gravado. Agentes locais têm o Guard como hook do Claude Code desde agosto, e as execuções gerenciadas agora têm a mesma verificação dentro do worker.

Quando o projeto tem um repositório vinculado, cada write_file e edit_file que o agente faz é conferido contra as regras de conformidade do projeto antes que a alteração seja aplicada. Uma violação crítica recusa a gravação, e o agente lê qual regra violou e por quê:

blocked by Archyl Guard: 1 critical architecture violation(s) in
backend/internal/adapter/http/handlers/invoice.go. Change the content so it
conforms, then write again:
- [critical] No direct database access from HTTP handlers — move the query behind a service

O agente move a query e grava de novo. Uma violação de severidade alta deixa a gravação passar com um alerta. Se a própria verificação falhar ou estourar o tempo, a gravação passa: o Guard nunca bloqueia um agente por um erro próprio, porque uma verificação de governança que quebra o trabalho que ela governa acaba sendo desligada.

Cada verificação também leva o ID da sessão, que atribui o arquivo à sessão da execução enquanto o agente trabalha. Isso importa duas seções abaixo.

O agente conhece a sua sessão, mas não é dono dela

O prompt da execução agora nomeia a sessão e diz ao agente que a plataforma a abriu e vai fechá-la, "então não há tools de sessão para chamar". O agente não pode abrir uma segunda sessão nem encerrar esta antes da hora. O ciclo de vida pertence à plataforma, a única parte que sabe quando uma execução terminou.

O que é do agente é o relato do trabalho. Logo antes de terminar, ele chama report_outcome uma vez, com um resumo honesto, as decisões que merecem um ADR, próximos passos para o trabalho que ficou por fazer e as memórias do briefing em que se apoiou. A descrição da tool diz para ele deixar constatações circunstanciais fora das decisões, porque decisões são reapresentadas a sessões futuras e uma anotação de debugging não deveria amarrar ninguém.

O resultado vai para onde o trabalho foi

Quando a execução termina, o Archyl primeiro liga à sessão os arquivos que a execução alterou. Isso resolve a mais silenciosa das três lacunas. Os elementos que uma sessão reserva são inferidos do texto da tarefa, e texto de tarefa é um palpite. Os arquivos alterados são o que aconteceu. A memória agora vai para os elementos que o trabalho real tocou, não para tudo o que o ticket mencionava.

Depois ele fecha a sessão, guarda o resumo como memória nesses elementos e dá crédito às memórias que o agente diz ter usado, que é o sinal com que a ordenação da memória aprende.

Decisões só são registradas quando a execução foi bem-sucedida. Elas viram memória do projeto e abrem um Architecture Change Request em rascunho, para que uma pessoa revise como o modelo deve se atualizar. Uma execução que falhou mantém o resumo e os próximos passos, que são o que a próxima tentativa precisa, mas não registra decisões. Trabalho que não foi concluído não tem nada a sustentar.

A página da execução mostra tudo isso em um cartão Resultado da sessão de trabalho: resumo, decisões, próximos passos, os elementos tocados, as memórias citadas e um link para o Change Request. Um elemento que outra sessão mantém aparece marcado como Reservado por outra sessão de trabalho, para que uma execução que editou código dentro da reserva de outra pessoa não passe despercebida.

Dois tipos de agente, um modelo

Esta é a peça que muitos agentes, uma arquitetura buscava: coordenação entre agentes que nunca compartilham um processo, nas duas direções.

Uma execução gerenciada abre sua sessão como managed-agent/<profile name>. Inverta a cena do começo deste post: a execução agendada está na Billing API quando um desenvolvedor inicia o Claude Code nela. O briefing do Claude Code agora traz a execução como conflito:

- **Conflicts** (someone else is already working here):
  - Billing API — held by managed-agent/backend-fixer: fix rounding on prorated invoices

O agente local é orientado a se coordenar antes de alterar esse elemento, o console Fleet mostra as duas sessões, e a que terminar deixa memória que a outra lê da próxima vez.

Também saiu esta semana

Rapidamente, porque o resto se apoia nisso. Os perfis agora trazem skills embutidas e allowlists de tools, então um revisor somente leitura pode ser limitado a read_file, list_* e get_*. Heartbeats do worker detectam execuções mortas e as recolhem, a API key de cada execução é revogada quando a execução termina, e uma execução que falhou ainda publica seu trabalho como pull request em rascunho. As execuções sempre rodam no worker do próprio Archyl, no provedor de IA da sua organização quando o BYO está ativado.

O que isso não faz

A coordenação só enxerga agentes que usam o harness. Uma reserva existe porque um agente abriu uma sessão. Um agente editando o repositório sem sessão é invisível para o gate, e uma execução que respeita o trabalho de outros agentes vai começar bem ao lado dele.

O worker não roda seus testes. Ele tem tools de arquivos do workspace (ler, gravar, editar, listar, grep) e nenhum shell. Não consegue buildar o projeto nem rodar a suíte, então um cartão de resultado limpo significa que as gravações passaram pelo Guard, não que o código compila. A CI continua fazendo esse trabalho.

As decisões de um agente não são revisadas. Uma decisão no cartão de resultado é uma afirmação do agente até alguém revisar o Change Request. Essa revisão é o ponto, não uma formalidade.

O Guard precisa de algo com que comparar. Sem um repositório vinculado não há verificação de gravação, e um conjunto vazio de regras de conformidade deixa passar qualquer gravação.

Por onde começar

Escolha aquele perfil que roda em um agendamento sobre código que as pessoas também mudam à mão, e ative Respeitar o trabalho de outros agentes em Coordenação. Deixe os outros como estão.

Se ele recusar uma execução, o motivo nomeia o agente e a tarefa que se sobrepôs a ela. Até agora, essa sobreposição teria passado sem ninguém ficar sabendo.

Execuções gerenciadas de agentes, sessões de trabalho, o Guard e a memória fazem parte do archyl. Todas as configurações citadas acima estão na documentação de execuções gerenciadas de agentes, e o lado local está no guia do Harness. Leituras relacionadas: muitos agentes, uma arquitetura, sessões de trabalho para agentes de código, memória para agentes de código e o lançamento das execuções gerenciadas de agentes.