Deixamos um agent planejar a própria semana

A gente entregou a um agent uma agenda em branco e a mesma instrução que você daria a um novo contratado competente: aqui está o objetivo, planeje sua semana, vai. Na segunda ele escolheu uma primeira tarefa sensata. Na terça escolheu a próxima. Na quarta ele tinha decidido que o objetivo precisava de três sub-tarefas a mais do que alguém pediu, agendou-as, e começou a trabalhar numa lista que ele tinha escrito pra si mesmo. Ninguém mandou ele parar, porque a gente não tinha construído a coisa que diz parar.

Esse é o momento em que a demo deixa de ser charmosa. Um agent que consegue planejar a própria semana é, por construção, um agent que consegue planejar a própria semana pra sempre.

A parte perigosa de um agent auto-agendante nunca é o trabalho que ele faz. É que nada manda ele parar. A lição é o freio, não o acelerador.

Este post é sobre o freio, do que ele é feito, por que cada peça é não-opcional, e por que o sistema de aparência mais autônoma que rodamos é o que tem mais limites cabeados nele.

A versão ingênua: dê o objetivo e confie no loop

O jeito óbvio de construir um agent auto-dirigido é o jeito que ele se lê num design doc. Você dá a um agent um objetivo, um conjunto de ferramentas, e um loop. A cada ciclo, ele olha o que está pronto, decide o que é o próximo, faz, e repete. Planejar, agir, observar, planejar de novo. Ele agenda o próprio trabalho porque o loop é o scheduler.

Pra uma tarefa limitada, isso é maravilhoso. Dê a ele “resuma estes três documentos” e ele planeja três leituras e uma escrita e termina. O loop termina porque o objetivo termina.

O problema começa no momento em que o objetivo é aberto, “mantenha o projeto andando,” “fique por cima do pipeline,” “cuide da caixa de entrada.” Agora não há último passo natural. Sempre há uma próxima coisa que o agent poderia razoavelmente fazer. E um agent cuja única condição de parada é “o objetivo está completo” nunca vai parar num objetivo que nunca está completo.

Aqui está a falha, concretamente. Suponha que o objetivo seja “avance o lançamento.” O agent faz o trabalho óbvio, então repara que o lançamento iria melhor com um checklist, então faz um. Aí o checklist tem itens, então ele começa os itens. Aí um item poderia usar um sub-plano, então ele o planeja. Cada passo é localmente razoável. Nenhum deles é o que você pediu. O loop não deu defeito, ele fez exatamente o que um loop faz, que é rodar. Você não construiu um assistente. Você construiu uma coisa que gera a própria próxima razão pra continuar.

A dor não é que ele faz trabalho ruim. É que ele faz trabalho plausível, indefinidamente, sob a própria autoridade, e a primeira vez que você descobre até onde ele foi é quando você confere.

Autonomia sem condição de parada é só uma disparada

A lição que os times aprendem aqui é a que os engenheiros mecânicos aprenderam um século antes: o problema difícil com um motor potente não é fazê-lo andar. É fazê-lo parar sob comando, de forma confiável, toda vez, inclusive na vez em que algo já deu errado.

Um agent auto-agendante tem um acelerador, o loop. O que falta a ele é tudo o que torna seguro deixar o acelerador rodando. Não um planejador mais inteligente. Um conjunto de limites que existem fora do próprio julgamento do agent, pelos quais o agent não consegue raciocinar pra escapar, porque o ponto inteiro é que eles prendem precisamente quando o julgamento dele derivou.

A gente parou em quatro. Nenhum deles é esperto. Juntos eles são a diferença entre um colega autônomo e uma disparada.

Os quatro são um cost cap (quanto ele pode gastar), um wall-clock cap (quanto tempo ele pode rodar), um write-boundary (onde ele pode fazer mudanças), e um heartbeat (prova de que ele ainda está vivo e na tarefa). Vamos pegar um de cada vez, porque cada um fecha um jeito diferente em que o loop dispara.

Freio um: um cost cap, porque “continuar” tem um preço

O pressuposto ingênuo é que um agent ocioso não custa nada, então um ocupado está só sendo útil. O oposto é verdade. Um agent auto-agendante está ocupado por default, o estado de repouso dele é “achar a próxima coisa e fazer.” Cada ciclo do loop gasta dinheiro real: chamadas de modelo, chamadas de ferramenta, o compute embaixo dos dois. Um agent sem limite de gasto e com um objetivo aberto é um medidor que só gira pra um lado.

O modo de falha é silencioso, que é o que o torna caro. Nada quebra. O agent só continua planejando e agindo, cada passo barato, a soma enorme, e você descobre no rodapé de uma fatura em vez de no topo de um alerta. Digamos que um único ciclo de planejar-e-agir custe alguns centavos. Isso não é nada, até o loop rodar dez mil ciclos durante a madrugada porque ninguém definiu o número que diz “pare neste tanto.”

Então a primeira coisa que todo agent auto-dirigido ganha, antes de ganhar uma única ferramenta, é um orçamento. Um teto rígido, declarado lá no início, que o orquestrador impõe, não uma sugestão no prompt que o agent consegue racionalizar pra contornar, mas um limite checado pela coisa que roda o agent, fora do alcance do agent. Bateu no teto e o loop termina, no meio de um plano se for preciso. O agent não tem voto, porque a razão inteira do cap é o caso em que o próprio julgamento do agent é a coisa que está errada.

O cap não está lá pra deixar o agent barato. Está lá pra que o pior caso seja limitado, pra que um objetivo mal-julgado custe uma quantia conhecida e não uma desconhecida.

Freio dois: um wall-clock cap, porque “pra sempre” é um número real

Dinheiro não é a única coisa que uma disparada queima. Ela queima tempo, e tempo tem a própria forma de falha. Um agent que está gastando devagar mas rodando infinitamente não vai disparar um cost cap por um bom tempo, mas ainda é um processo que deveria ter terminado horas atrás, segurando um espaço, parecendo ocupado, produzindo menos a cada ciclo conforme deriva mais longe do pedido original.

O instinto ingênuo é deixar rodar até estar pronto. A gente já conhece a armadilha: num objetivo aberto, “pronto” nunca chega. Então “até estar pronto” significa “pra sempre,” e pra sempre não é um cronograma. É a ausência de um.

O wall-clock cap transforma pra sempre num número. Esta rodada ganha um intervalo fixo, uma hora, uma noite, uma janela definida, e quando a janela fecha, o agent para e reporta onde chegou, ache ele que está pronto ou não. O cap converte uma pergunta aberta (“quando isto vai terminar?”) numa fechada (“neste horário, não depois”). Isso não é uma limitação na ambição do agent. É a coisa que te deixa dar ambição a ele afinal, porque você sabe que a ambição tem uma borda.

Há uma segunda razão pra o wall-clock cap importar, e é sobre o humano, não a máquina. Um agent com um prazo é um agent que você pode deixar sozinho. Você pode despachá-lo antes de dormir e saber que ele estará parado e reportando de manhã, não ainda girando. Um limite em que você pode confiar é o que torna a autonomia sem supervisão algo que você de fato arriscaria.

Freio três: um write-boundary, porque alcance é o raio de explosão

Custo e tempo limitam quanto o agent roda. Nenhum dos dois limita o que ele pode tocar enquanto roda, e esse é o limite que decide quão ruim uma semana ruim pode ficar.

A versão ingênua dá ao agent um alcance amplo porque alcance amplo é conveniente. Deixe-o editar qualquer coisa, escrever em qualquer lugar, agir por todo o sistema, e ele nunca será bloqueado por uma permissão que falta. Isso parece poder. Na verdade é o maior raio de explosão possível cabeado diretamente ao processo menos supervisionado que você roda.

Imagine a disparada de novo, agora sem cerca. O agent que inventou três sub-tarefas extras não só as planejou, ele agiu sobre elas, em cada canto do sistema que conseguia alcançar, e a bagunça está em todo lugar de uma vez. A deriva não foi contida porque nada a conteve. Limpar não é uma questão de desfazer uma coisa. É uma questão de achar tudo o que um loop sem supervisão tocou enquanto estava confiantemente fora do rumo.

A autoridade de um agent deveria ser exatamente tão ampla quanto a tarefa dele, e nem um centímetro mais ampla.

Então todo agent auto-dirigido roda dentro de um write-boundary: um conjunto declarado de lugares que ele pode mudar, e mais nada. Ele pode ler amplamente, contexto é barato e seguro, mas ele só pode escrever dentro da faixa dele. Um agent, uma faixa, sem exceções, imposto pelo sistema e não pelas boas intenções do agent. Se um plano que ele inventa exige escrever fora da fronteira, o plano não roda. A fronteira é como um mau julgamento continua uma pequena bagunça em vez de uma grande, o raio de explosão é a faixa, por design.

Freio quatro: um heartbeat, porque silêncio não é segurança

Os três primeiros freios limitam o que o agent pode fazer. O quarto responde uma pergunta diferente: como você sabe que ele ainda está fazendo?

O pressuposto ingênuo é o mais perigoso do sistema inteiro: nenhuma notícia é boa notícia. O agent está rodando, você não ouviu uma reclamação, então deve estar tudo bem. Mas um agent auto-agendante que ficou em silêncio não está necessariamente bem. Ele pode estar preso num loop, repetindo o mesmo passo que falha. Ele pode ter saído do objetivo e estar ocupadamente fazendo a coisa errada. Ele pode ter quebrado e não deixado bilhete. Silêncio cobre todos esses igualmente, o que significa que silêncio não te diz nada, e um sistema onde “nada” se lê como “tudo bem” é um sistema que descobre as próprias falhas por último.

Então um agent de longa duração emite um heartbeat: um “estou vivo, aqui está onde estou, aqui está no que estou trabalhando” periódico e estruturado. Não um log que ninguém lê, um sinal que o orquestrador observa. Se o heartbeat continua chegando com progresso, ótimo. Se ele para, o orquestrador sabe dentro de uma batida perdida que algo está errado, em vez de descobrir horas depois quando o trabalho era pra estar pronto. Se o heartbeat continua chegando mas o progresso não, mesmo plano, mesmo passo, sem movimento, isso é um loop preso, e agora está visível em vez de enterrado.

O heartbeat é o que transforma “o agent rodou durante a madrugada” de um ato de fé num fato observável. É a diferença entre despachar um agent e abandonar um.

Junte os quatro e repare na forma. O cost cap limita o gasto. O wall-clock cap limita o tempo. O write-boundary limita o alcance. O heartbeat torna os três observáveis enquanto eles prendem. Cada um é um lugar em que o loop poderia disparar, e cada um é um muro contra o qual ele agora bate.

Por que os limites tornam a autonomia real, não menor

Aqui está a parte que parece ao contrário até você sentar com ela. Os quatro freios não tornam o agent menos autônomo. Eles são a única razão pela qual você jamais concederia autonomia real a ele.

Pense em como a confiança de fato funciona entre pessoas. Você não entrega ao novo contratado as chaves da empresa e um cheque em branco no primeiro dia, não porque ele não é confiável, mas porque confiança é conquistada contra um downside conhecido. Você dá a ele uma tarefa limitada, um orçamento, um prazo, e um check-in regular. Os limites não são um insulto. São a estrutura que te deixa delegar agora em vez de depois de um ano observando. Conforme ele se prova, os limites se ampliam. Confiança é uma escada que você sobe, e cada degrau é um limite que você já consegue ver.

Um agent é igual, só que mais, porque um agent vai executar o mau julgamento dele na velocidade da máquina e nunca cansa nem fica sem graça por isso. Os caps e o heartbeat são como você coloca um agent auto-dirigido no primeiro degrau, limitado o bastante pra que o pior caso seja sobrevivível, observável o bastante pra que você notaria a deriva, cercado o bastante pra que a deriva fique local. É isso que torna “vai planejar sua semana” uma frase que você pode dizer a um software afinal.

Os times que se queimam com agents autônomos quase nunca se queimaram pelo agent ser burro. Eles se queimaram pelo agent ser ilimitado, capaz, ocupado, bem-intencionado, e rodando sem borda em direção nenhuma. O modelo não foi o problema. O freio que faltava foi.

A virada: o limite é o ato de confiança, não a ausência dele

Tire o agent e o que sobra é uma verdade antiga sobre entregar trabalho a qualquer um, pessoa ou processo.

A gente tende a pensar em liberdade e limites como opostos, que confiar em alguém é remover os guardrails. É o contrário. A razão pela qual você consegue deixar um novo colega ser dono de algo real é que a empresa já tem as bordas que tornam a posse segura: o orçamento dentro do qual ele trabalha, o escopo pelo qual é responsável, o ritmo de check-ins que revela um problema enquanto ele é pequeno. Isso não é uma jaula em torno da autonomia dele. É a coisa que deixa a autonomia existir sem a empresa inteira prendendo a respiração.

Um agent auto-agendante é a versão mais literal dessa lição que a gente já teve de construir. A gente genuinamente deixa ele planejar a própria semana, escolher as tarefas, ordenar o tempo, decidir o que é o próximo. E a razão pela qual conseguimos fazer isso sem hesitar é que a gente gastou a maior parte da engenharia não no planejamento, mas nas quatro bordas que o pegam se o plano der errado. A liberdade é real porque o freio é real. Remova o freio e você não tem mais autonomia. Você tem uma coisa que roda até você por acaso olhar.

---

É isso que estamos construindo na Apollo, agents que são donos de trabalho real, cercados pelos limites que tornam a posse real segura de conceder. A parte perigosa de um agent auto-agendante nunca é o trabalho que ele faz; é que nada manda ele parar. Então a primeira coisa que a gente constrói, toda vez, antes do agent fazer qualquer coisa, é a coisa que diz parar.