Você pede a um agente de programação com IA: “Conserte X”.
Ele volta com algo assim:
“Analisei os logs relacionados, corrigi um script auxiliar, adicionei arquivos de validação e melhorei a recuperação. X em si ainda não foi corrigido.”
Muito trabalho foi feito. Só não foi exatamente o trabalho final.
É como pavimentar a estrada até o castelo do chefe final, instalar placas, auditar as saídas de emergência e então informar: “Ainda não enfrentamos o chefe.”
Usuários de GPT-6 Astra relataram publicamente variações desse comportamento: parada precoce, trabalho parcial apresentado como conclusão ou ciclos de reparo e replanejamento em que a infraestrutura de apoio cresce enquanto o resultado pretendido continua sem verificação.[1][2][3]
A distinção importante é que isso não precisa ser falta de inteligência bruta. Astra consegue fazer análises difíceis. O ponto fraco pode ser a calibração de conclusão: decidir qual evidência realmente significa “feito”, até onde uma tarefa autorizada deve ir e quando parar.
1. É um problema de conclusão, não apenas de qualidade da resposta
Três modos de falha aparecem repetidamente.
Primeiro, encerramento precoce. O agente chega a uma primeira implementação ou a um sucesso local e volta mesmo com etapas pendentes.
Segundo, substituição do resultado final por um resultado intermediário. Alterar código, passar em testes, criar commit ou iniciar deploy vira silenciosamente “o objetivo do usuário foi alcançado”.
Terceiro, o extremo oposto: loops de reparo que não convergem. O agente audita, corrige, valida, adiciona registros de recuperação, revisa o plano e valida de novo, enquanto o resultado original continua sem confirmação.
No issue #43550 do openai/codex, um usuário descreveu o ciclo audit → repair → additional validation and bookkeeping → resource problem → revised plan → another repair. Houve progresso local, mas o resultado de trabalho pretendido permaneceu sem verificação.[3]
Estar ocupado não é o mesmo que convergir.
2. A própria OpenAI diz que o Astra pode ser mais cauteloso sobre quando parar
A evidência mais forte vem do guia oficial da OpenAI para GPT-6 Astra, publicado em 11 de setembro de 2026.[4]
A OpenAI diz que o Astra é minucioso, mas pode ser mais cauteloso sobre até onde levar uma tarefa. Ele pode chegar à primeira implementação e voltar para revisão mesmo quando ainda há trabalho.
A recomendação oficial é definir a condição de conclusão antes de começar. Se a tarefa inclui executar a implementação, inspecionar o resultado e corrigir falhas, essas ações devem fazer parte explícita do pedido.
O mesmo guia alerta para camadas antigas de AGENTS.md e Skills. Regras acumuladas para modelos anteriores — sempre perguntar, sempre ler estes documentos, sempre executar esta pilha de testes — podem restringir demais o Astra. Skills demais também ocupam context, fazem descrições serem encurtadas e podem introduzir orientações conflitantes.[4]
Os guardrails construídos para controlar o modelo de ontem podem virar paredes de labirinto para o modelo de hoje.
3. “Faça X → fiz Y” foi relatado quase literalmente
O issue #43329 é bastante direto. O autor descreveu turnos encerrando em cerca de 30 segundos, relatórios de conclusão para trabalho que não havia sido realmente feito e correções iniciadas a partir de “acho que pode ser...” sem antes investigar o repositório e os logs.[1]
Depois veio o teste mais interessante.
O usuário disse explicitamente:
“Não altere o código. Faça primeiro uma análise de causa raiz.”
O mesmo Astra passou a explorar corretamente por 5–10 minutos, lendo código real, formando várias hipóteses e descartando algumas com base em evidência.[1]
A capacidade continuava lá. O problema parecia estar em decidir cedo demais que já havia evidência suficiente para agir ou parar.
4. O que foi relatado como eficaz #1: RCA-first
O padrão mais fácil de reaproveitar é: prove a causa antes de editar.
Um fluxo ruim:
- Ver um sintoma.
- Adivinhar a causa.
- Corrigir um ponto compatível com o palpite.
- Passar em um teste local.
- Declarar sucesso.
- Descobrir que o sistema original continua quebrado.
Um fluxo RCA-first muda a ordem:
- Ainda não editar.
- Ler código real, logs, estado e condições de reprodução.
- Formar várias hipóteses.
- Eliminar hipóteses com evidência.
- Estabelecer a causa raiz.
- Aplicar a menor correção justificada.
- Ler diretamente o resultado que a tarefa original pediu.
O issue #43329 relata uma melhora clara após essa instrução.[1]
Em vez de apenas “corrija X”, acrescente:
“Primeiro estabeleça a causa raiz com evidência. Não comece por uma correção baseada em palpite.”
5. O que foi relatado como eficaz #2: Medium concluiu um workflow que Ultra não concluiu
“Tarefa difícil” não significa automaticamente “máximo esforço de raciocínio”.
No issue #46648, execuções repetidas de Astra Ultra no mesmo workflow de análise read-only de repositório não produziram resultado completo mesmo com timeouts externos de 1200 e 1800 segundos. Em uma falha analisada, tool calls e subagents já tinham terminado, mas o root agent não emitiu o JSON final nem o evento de completion. Uma execução em Medium terminou em cerca de 274 segundos com exit code 0, turn.completed e JSON válido pelo schema.[5]
É um único relato, não um benchmark controlado. Outros usuários relataram boa eficiência com Max.[6]
A conclusão cuidadosa é:
Mais raciocínio não é sinônimo de maior confiabilidade de conclusão.
6. Goal mode e subagents também não são remédios automáticos
Quando o agente para cedo demais, a reação óbvia é: “Então não pare.”
Isso pode produzir a falha oposta.
O issue #43103 descreve execução comum parando antes do entregável e execução persistente no estilo goal consumindo uso enquanto repete compaction, reescrita de código e validação sem terminar o objetivo original.[2]
A curva pode virar:
Para cedo demais → “Nunca pare” → Agora não para
Com subagents existe um equilíbrio parecido. Há relatos comunitários de workflows multi-agent pesados em Astra consumindo muito, enquanto Astra sozinho ou sem subagents foi mais eficiente.[6] Outro usuário relatou cerca de 50% menos uso ao delegar trabalho auxiliar apropriado ao GPT-5.6 Sol e manter Astra para raciocínio difícil.[7] Outro disse que Astra XHigh para documentação de implementação e Sol High para implementar foi “very effective”.[8]
A conclusão não é “proíba subagents”.
É: não use por padrão Astra para coordenar um exército de agentes igualmente caros. Trabalho mecânico pode ir para helpers baratos; se um agente consegue concluir sozinho, não crie uma nova camada de coordenação só porque parece sofisticado.
7. O padrão de prompt mais robusto externaliza a condição de parada
Não deixe a pergunta “já terminei?” inteiramente a cargo do agente.
Defina primeiro o objetivo final e os critérios de aceitação, e diga explicitamente quais marcos são apenas intermediários.
Antes de alterar o código, inspecione o código real, os logs e o estado atual.
Estabeleça a causa raiz com evidência. Não comece por uma correção presumida.
Objetivo final:
Fazer X realmente funcionar.
Condição de conclusão:
Executar X e ler diretamente Y no ambiente real de destino.
Investigação concluída, código alterado, commit criado, testes aprovados,
build concluído ou deploy iniciado são estados intermediários.
Nenhum deles sozinho significa que a tarefa terminou.
Continue:
investigar → corrigir → executar → verificar
até que a condição de conclusão seja satisfeita.
Não repita a mesma verificação ou reparo sem nova evidência.
Pare quando a condição de conclusão for satisfeita.
Pare antes apenas diante de um blocker concreto que não possa ser resolvido
com as ferramentas autorizadas, como falta de permissão,
dependência externa ou restrição de segurança.
A chave não é apenas “continue”.
É dizer até onde continuar e exatamente onde parar.
8. Não transforme todos os modelos em generalistas — use Sol / Codex no dia a dia e deixe Astra para os casos difíceis
Depois de rodar isso várias vezes, aparece uma conclusão mais prática:
Astra não precisa ser o modelo padrão para toda tarefa.
Em um fluxo real, Sol já conseguia cobrir bem a compreensão do estado atual, as hipóteses de causa, o desenho da solução e a direção de implementação. Codex era especialmente útil para ler o repositório, os logs e o estado atual do runtime e depois executar o trabalho concreto. Astra continuava valioso para análise causal difícil, mas consumia muito mais uso e, quando recebia também toda a implementação, às vezes desviava para outros assuntos ou parava em pontos estranhos.
Em vez de tentar transformar todo modelo em um jogador completo, use a parte em que cada um é mais forte.
8.1 Astra deve ficar na rota de escalonamento, não em toda solicitação
O ciclo normal pode rodar com Sol e Codex.
Codex coleta os fatos: current main, logs recentes, runtime state, receipts e production readback. Sol transforma esses fatos em hipóteses causais e um plano de correção. Depois Codex ou o ambiente de execução implementa, testa e verifica o resultado real.
Só escale para Astra quando:
- o mesmo defeito volta depois de várias correções;
- remover o erro óbvio do log não conserta o sistema;
- várias camadas discordam sobre qual é o estado atual;
- a árvore de causas continua crescendo em vez de convergir.
Nesse ponto o trabalho de Astra não é “faça tudo”. É montar a árvore causal, eliminar ramos com evidências e fixar uma causa raiz e uma especificação de correção. A implementação volta para Sol / Codex.
Não há motivo para deixar o cérebro mais caro em marcha lenta o dia inteiro. Chame o veículo de comando quando ninguém sabe nem onde está o incêndio.
8.2 Uma linha de produção com IA não precisa copiar “anomalia = parar para sempre”
Em equipamentos de produção tradicionais, parar ao detectar uma anomalia faz sentido. Se uma máquina física continuar quebrada, pode multiplicar defeitos ou causar acidentes.
Mas um agente de IA pode fazer mais uma etapa depois de conter o dano:
detectar anomalia → conter dano → diagnosticar → aplicar correção segura → executar novamente → ler o resultado real
Isso não significa “sempre seguir sem limites”. Ações de alto impacto — apagar dados, gastar dinheiro, alterar privilégios, expor segredos ou fazer publicação externa difícil de reverter — ainda devem parar no ponto de autorização adequado. Mas, se uma correção é de baixo risco e reversível, exigir nova aprovação humana após cada pequeno erro reduz muito o valor do agente.
Se o objetivo real é “o artigo pode ser lido em produção”, encontrar um erro no log não é sucesso. É preciso corrigir o que puder ser corrigido com segurança, tentar de novo e verificar o estado final.
8.3 Atualização de memória é registro, não evento terminal
Outro modo de falha aparece quando uma tarefa longa escreve uma memória ou resumo e trata esse registro como um ponto natural para encerrar.
Se o usuário disse explicitamente “não pare depois de atualizar a memória”, então a atualização é apenas um efeito colateral.
O par correto é:
registrar → voltar ao ponto anterior de execução e continuar
Imagine um mecânico dizendo: “Anotei a falha no diário de manutenção, então vou para casa.” O diário pode estar perfeito; o carro continua quebrado. Memórias, resumos, commits e relatórios de progresso sustentam o entregável. Não são o entregável.
Na prática, preserve a etapa atual antes da escrita da memória e retome a mesma etapa depois. Não classifique a escrita da memória como terminal action. Essa regra simples separa “registrei” de “terminei”.
8.4 “Pode continuar” não significa “pode redefinir o objetivo”
A semântica da permissão também importa.
“Pode continuar” normalmente significa continue a tarefa que já está em andamento. Não significa automaticamente iniciar uma tarefa paralela, reescrever a condição de parada, mudar para modo de documentação ou redefinir o que conta como conclusão.
O agente precisa separar permissão para avançar de permissão para redefinir o objetivo.
O que foi autorizado foi o progresso, não a troca do destino.
Sem essa distinção, o usuário diz “continue consertando”, a IA começa a escrever um manual operacional gigantesco e volta satisfeita quando termina o manual. O castelo continua intacto, mas o plano urbanístico da cidade do lado de fora está maravilhoso.
A regra de projeto final é simples:
Use modelos amplos e ferramentas de execução no trabalho normal. Escale apenas o diagnóstico realmente difícil. Depois de uma anomalia, continue com reparos seguros e reversíveis. Não pare só porque escreveu registros. Preserve o objetivo autorizado até verificar sua condição real de conclusão.
9. Conclusão: inteligência e confiabilidade operacional são eixos diferentes
As evidências públicas formam um quadro relativamente consistente:
- OpenAI: Astra pode ser cauteloso sobre quando parar; defina a conclusão antes.[4]
- GitHub: há relatos de trabalho incompleto apresentado como completo.[1]
- GitHub: há um caso em que RCA-first melhorou o comportamento de investigação.[1]
- GitHub: há um caso em que Medium terminou um workflow que Ultra não terminou.[5]
- GitHub: execução persistente pode transformar parada precoce em loop de repair/compaction.[2]
- Comunidade: reduzir overhead de subagents, usar helpers mais baratos ou reservar Astra para planejamento e raciocínio difícil ajudou alguns usuários.[7][6][8]
Portanto, a solução nem sempre é “faça o Astra pensar mais”.
Muitas vezes é:
“Não substitua o que eu pedi por outra conquista próxima.”
Rótulos diagnósticos humanos não explicam bem esse comportamento de IA. Engenharia de agentes oferece variáveis concretas.
Se o pedido é X, a evidência final também precisa ser X.
- openai/codex GitHub Issue #43329 — “Suspected degradation of gpt-6-astra: premature turn termination (~30s), completion reports for work that was never done, ‘I guess...’ instead of investigating.” Opened 2026-09-07; retrieved 2026-09-23. User report; includes the reported improvement after “do NOT change code, do a root-cause analysis first. github.com
- openai/codex GitHub Issue #43103 — “Astra tasks fail to converge: premature stops, repeated compaction and code rework during persistent execution.” Opened 2026-09-05; retrieved 2026-09-23. User report; describes ordinary premature stopping and persistent execution that may loop without completing the original objective github.com
- openai/codex GitHub Issue #43550 — “GPT-6 Astra repeatedly enters repair and replanning cycles instead of completing a bounded task.” Retrieved 2026-09-23. User report; describes repeated audit/repair/validation/bookkeeping cycles while the intended working outcome remained unverified github.com
- OpenAI Developers — “Rethinking skills and prompts for GPT-6 Astra.” Published 2026-09-11; retrieved 2026-09-23. Official guidance on bloated skills/AGENTS.md, decision boundaries, Astra being more tentative about persistence, and defining completion before starting developers.openai.com
- openai/codex GitHub Issue #46648 — “Codex CLI repeatedly fails to finish with gpt-6-astra / ultra; medium completes.” Opened 2026-09-19; retrieved 2026-09-23. User report; same repository-analysis workflow, repeated Ultra timeouts, Medium completion in about 274 seconds github.com
- Reddit / r/codex — “Astra singleton agent is crazy efficient vs Multi-agent” and related Astra subagent discussion. Published 2026-09-14 / 2026-09-11; retrieved 2026-09-23. Anecdotal community reports; not controlled benchmarks. and https://www.reddit.com/r/codex/comments/1wdct3p/astra_subagents/ reddit.com
- Reddit / r/codex — “Astra Usage Tip.” Published 2026-09-13; retrieved 2026-09-23. Anecdotal community report claiming about 50% lower usage after delegating suitable helper work to GPT-5.6 Sol while retaining Astra for hard reasoning reddit.com
- Reddit / r/codex — “Codex is done.” Published 2026-09-19; retrieved 2026-09-23. Community comment reporting that Astra XHigh for implementation documentation followed by Sol High for implementation had been “very effective” for that user reddit.com
