Na v\u00e9spera do DevDay 2026 da OpenAI, come\u00e7ou a circular o nome de um novo produto: um agente persistente, batizado internamente de Aeon (ou possivelmente lan\u00e7ado com o nome p\u00fablico “o”). O que interessa aqui n\u00e3o \u00e9 o nome nem o marketing. Interessa entender o que muda, na engenharia, quando voc\u00ea sai de um chatbot que responde e para em um agente que continua trabalhando com a aba fechada.<\/p>\n
A OpenAI deve apresentar no DevDay 2026, em 29 de setembro em S\u00e3o Francisco (Fort Mason), um agente persistente reportado sob o codinome Aeon e possivelmente com marca comercial “o”. A cobertura veio da Verge, com detalhes t\u00e9cnicos posteriores publicados pelo TestingCatalog, OrcaRouter e CellCog.<\/p>\n
O que est\u00e1 publicamente verificado \u00e9 pouco. At\u00e9 24 de setembro de 2026 a OpenAI n\u00e3o tinha anunciado Aeon; at\u00e9 26 de setembro, o changelog de API, model docs e news feed n\u00e3o continham entrada com esse nome. O que existe s\u00e3o strings de configura\u00e7\u00e3o aparecendo brevemente na tela de upgrade do ChatGPT, com “o” como display name e “-o” como sufixo de email. A ideia por tr\u00e1s, entretanto, \u00e9 concreta e tem literatura t\u00e9cnica s\u00f3lida: agentes de longa dura\u00e7\u00e3o, sempre ativos, que rodam em loop no servidor.<\/p>\n
Este artigo \u00e9 sobre esse mecanismo. N\u00e3o sobre o an\u00fancio.<\/p>\n
Um chatbot cl\u00e1ssico \u00e9 request-response. Voc\u00ea manda uma mensagem, o modelo produz uma resposta, o processo morre. Um chatbot padr\u00e3o processa requisi\u00e7\u00f5es isoladas: responde \u00e0 sua pergunta e esquece a conversa. Ele n\u00e3o consegue monitorar trabalho em andamento, acompanhar mudan\u00e7as ao longo do tempo, nem executar a\u00e7\u00f5es em sistemas de neg\u00f3cio.<\/p>\n
Um agente persistente inverte isso. Ele n\u00e3o espera voc\u00ea abrir o chat. Ele fica rodando, observando gatilhos (email chegou, hora do calend\u00e1rio bateu, arquivo mudou), decide o que fazer, chama ferramenta, olha o resultado, decide de novo. E continua fazendo isso enquanto a tarefa n\u00e3o termina, ou enquanto a pol\u00edtica de execu\u00e7\u00e3o n\u00e3o mandar parar.<\/p>\n
Uma analogia \u00fatil, e vou marcar onde ela quebra: pense num forno com termostato versus um cozinheiro trabalhando na cozinha. O termostato reage a um evento pontual (temperatura passou do limite, desliga). O cozinheiro tem uma meta (o jantar \u00e0s oito), consulta rel\u00f3gio, prova a comida, ajusta o fogo, decide se precisa comprar mais um ingrediente. Ele est\u00e1 num loop de percep\u00e7\u00e3o, decis\u00e3o e a\u00e7\u00e3o, e o loop s\u00f3 termina quando o objetivo \u00e9 atingido. A analogia quebra porque o cozinheiro tem um corpo e o agente n\u00e3o: para o agente, “perceber o ambiente” \u00e9 literalmente ler entradas estruturadas, e “agir” \u00e9 chamar uma fun\u00e7\u00e3o. N\u00e3o existe intui\u00e7\u00e3o, existe tool call.<\/p>\n
O n\u00facleo de qualquer agente \u00e9 um loop, geralmente uma varia\u00e7\u00e3o de ReAct (reason then act). O comportamento em runtime \u00e9 governado pelo agent harness, a infraestrutura de orquestra\u00e7\u00e3o que transforma um LLM stateless em um agente persistente, com uso de ferramentas e auto-corre\u00e7\u00e3o. O loop ReAct fica no centro, cercado pelos subsistemas que o alimentam, restringem e persistem seu trabalho.<\/p>\n
Uma itera\u00e7\u00e3o t\u00edpica desse loop faz, em ordem: pr\u00e9-check e compacta\u00e7\u00e3o de contexto, pensamento, auto-cr\u00edtica, a\u00e7\u00e3o, execu\u00e7\u00e3o da ferramenta e p\u00f3s-processamento. Depois volta para o come\u00e7o. Isso \u00e9 o motor. Um agente “sempre ativo” \u00e9 esse loop rodando num container ou processo que n\u00e3o desliga quando voc\u00ea fecha o browser.<\/p>\n
LLM tem context window finita. Se o agente vai rodar por horas, ele vai gerar muito mais texto (pensamentos, sa\u00eddas de ferramentas, logs) do que cabe no prompt. Um agente de longa dura\u00e7\u00e3o quase certamente vai exceder a janela de contexto de qualquer modelo atual se tentar manter tudo em mem\u00f3ria de uma vez. A solu\u00e7\u00e3o n\u00e3o \u00e9 um context window maior, \u00e9 uma arquitetura de mem\u00f3ria.<\/p>\n
Na pr\u00e1tica, isso vira uma mem\u00f3ria em camadas:<\/p>\n
O trabalho da orquestra\u00e7\u00e3o \u00e9 decidir, a cada itera\u00e7\u00e3o do loop, o que sobe para a mem\u00f3ria de trabalho e o que fica s\u00f3 em epis\u00f3dica. Isso se chama compacta\u00e7\u00e3o de contexto e \u00e9 onde muita coisa quebra.<\/p>\n
Para tarefas longas, o padr\u00e3o que aparece na literatura \u00e9 dividir. A chave \u00e9 separar o planner do executor. Um componente decide o que fazer, outro faz. Essa separa\u00e7\u00e3o deixa o planner reavaliar e ajustar sem interromper o trabalho corrente do executor.<\/p>\n
Isso importa porque quando um passo falha (a API caiu, o site mudou o layout, o email foi rejeitado), voc\u00ea quer que s\u00f3 o executor daquele passo saiba lidar, sem invalidar o plano inteiro. E quando o plano precisa mudar (surgiu informa\u00e7\u00e3o nova), voc\u00ea quer que o replan aconte\u00e7a sem descartar o trabalho j\u00e1 feito.<\/p>\n
O que a OpenAI j\u00e1 exp\u00f4s publicamente, mesmo antes do DevDay, d\u00e1 pista da dire\u00e7\u00e3o. Em 10 de setembro a OpenAI abriu a Agents API em beta p\u00fablico, expondo o harness gerenciado do Codex: a OpenAI roda a orquestra\u00e7\u00e3o de sess\u00e3o, compacta\u00e7\u00e3o de contexto e recupera\u00e7\u00e3o, enquanto o desenvolvedor fornece a task, o modelo, as ferramentas e o ambiente de execu\u00e7\u00e3o, com sandboxes hospedados pela OpenAI, self-hosted, ou em infraestrutura parceira.<\/p>\n
Traduzindo: o loop, a mem\u00f3ria e o retry ficam do lado deles. Voc\u00ea entrega o qu\u00ea e as ferramentas. Um agente “consumer” always-on \u00e9 o mesmo harness com um scheduler na frente e uma UI diferente.<\/p>\n
Um esqueleto minimalista de agente persistente, sem framework, parece com isto:<\/p>\n
state = load_state(agent_id) # memoria episodica + plano atual\nwhile not state.done:\n trigger = wait_for_trigger(state) # evento, timer, ou continuacao\n context = build_context(state, trigger) # compactacao aqui\n thought = llm.reason(context)\n action = thought.next_action\n if action.needs_approval:\n request_human_approval(action)\n result = tools.execute(action)\n state = update_state(state, thought, action, result)\n persist_state(agent_id, state)\n<\/code><\/pre>\nCada linha a\u00ed esconde uma decis\u00e3o de engenharia. wait_for_trigger<\/code> pode ser uma fila, um webhook, um cron. build_context<\/code> \u00e9 onde voc\u00ea resolve o problema de mem\u00f3ria: quais epis\u00f3dios anteriores entram, quais saem, o que vira resumo. tools.execute<\/code> roda dentro de uma sandbox com timeouts e limites.<\/p>\nJ\u00e1 usei orquestra\u00e7\u00e3o desse tipo, escrita na m\u00e3o, com o mesmo desenho conceitual que a Agents API descreve: sess\u00e3o, contexto, recupera\u00e7\u00e3o, tudo separado da l\u00f3gica da task. Em um sistema multi-agente de captura e enriquecimento de lead, optei por orquestra\u00e7\u00e3o expl\u00edcita em vez de framework, porque quando quebra voc\u00ea precisa saber exatamente qual passo quebrou. O custo \u00e9 claro: escrever a orquestra\u00e7\u00e3o na m\u00e3o custa tempo no come\u00e7o e devolve em depura\u00e7\u00e3o.<\/p>\n
O ponto de aprova\u00e7\u00e3o humana (needs_approval<\/code>) merece aten\u00e7\u00e3o. A restri\u00e7\u00e3o arquitetural \u00e9 que a\u00e7\u00f5es rodam dentro de limites de runtime e de aprova\u00e7\u00e3o, n\u00e3o \u00e0 discri\u00e7\u00e3o do modelo. Uma chamada de alto risco, comitar c\u00f3digo ou tocar em produ\u00e7\u00e3o, passa por um gate de aprova\u00e7\u00e3o humana antes de executar. Um agente que manda email em seu nome sem gate \u00e9 um agente que vai mandar email errado eventualmente.<\/p>\nOnde quebra<\/h2>\nCusto<\/h3>\n
Loop rodando \u00e9 dinheiro rodando. Agentes always-on consomem muito mais recursos de servidor que chatbots request-response. Cada itera\u00e7\u00e3o \u00e9 uma chamada de LLM, e um agente que fica “vigiando” mesmo sem fazer nada relevante gasta tokens em pr\u00e9-checks e reasoning. Isso pesa na conta e explica por que as strings encontradas descrevem um plano ChatGPT chamado Pro Max a US$ 500 por m\u00eas, duas vezes e meia o Pro de US$ 200. Ele parece vender velocidade em vez de mais uso. Sua descri\u00e7\u00e3o de uma linha \u00e9 “Fastest Work and Codex”, e screenshots adicionam mem\u00f3ria m\u00e1xima e 100GB de armazenamento.<\/p>\n
Seguran\u00e7a e liability<\/h3>\n
Se um agente manda email em seu nome contendo um erro, ou pior, compromete voc\u00ea com algo que n\u00e3o pretendia, o quadro de responsabilidade fica complicado r\u00e1pido. No material da Verge h\u00e1 relato de vulnerabilidade j\u00e1 corrigida em agente concorrente que permitia takeover de conta, e reclama\u00e7\u00f5es de usu\u00e1rios sobre exposi\u00e7\u00e3o de endere\u00e7o residencial sem permiss\u00e3o. Anedotas individuais s\u00e3o dif\u00edceis de verificar, mas a categoria de risco \u00e9 real: prompt injection via conte\u00fado lido, exfiltra\u00e7\u00e3o via ferramenta com escopo largo demais, autentica\u00e7\u00e3o delegada que vaza.<\/p>\n
Observabilidade fica n\u00e3o-trivial<\/h3>\n
Um sistema multi-agente planner-executor lida bem com workflows longos e complexos, mas adiciona overhead de coordena\u00e7\u00e3o, mais pontos de falha e maior exig\u00eancia de observabilidade. Um agente que rodou por seis horas e falhou no final precisa ter deixado rastro suficiente para voc\u00ea entender por que. Sem trace estruturado por itera\u00e7\u00e3o do loop, voc\u00ea tem um log gigante e nenhuma pista.<\/p>\n
J\u00e1 senti isso analisando texto aberto de avalia\u00e7\u00e3o de cliente para decidir feature: quando o sistema produz um n\u00famero agregado, o caso extremo, que costuma ser o que importa, some. Com agente persistente \u00e9 a mesma l\u00f3gica: se voc\u00ea s\u00f3 olha “deu certo\/deu errado” ao final, perde o passo espec\u00edfico onde o agente entrou numa espiral.<\/p>\n
Quando n\u00e3o vale a pena<\/h3>\n
Se a tarefa \u00e9 bem definida, previs\u00edvel, e cabe num workflow determin\u00edstico, n\u00e3o use agente. Um workflow padr\u00e3o segue uma sequ\u00eancia fixa de passos. Um agente de longa dura\u00e7\u00e3o \u00e9 adaptativo, pode decidir, replanejar quando algo d\u00e1 errado e tomar caminhos diferentes. Workflows s\u00e3o previs\u00edveis, agentes s\u00e3o flex\u00edveis. Voc\u00ea paga a flexibilidade em custo, complexidade e imprevisibilidade. Se voc\u00ea n\u00e3o precisa dela, n\u00e3o pague.<\/p>\n
O que n\u00e3o d\u00e1 para afirmar ainda<\/h2>\n
Sobre o Aeon especificamente, quase tudo \u00e9 especula\u00e7\u00e3o at\u00e9 a keynote. Detalhes sobre tasks suportadas, permiss\u00f5es, agendamento, mem\u00f3ria ou disponibilidade permanecem desconhecidos. O TestingCatalog agora acha que Aeon pode ser o nome interno para os custom agents existentes de Workspace da OpenAI, n\u00e3o do produto novo. O nome p\u00fablico pode ser “o”, pode ser outra coisa, pode n\u00e3o existir ainda no an\u00fancio.<\/p>\n
Sobre a arquitetura descrita aqui: ela reflete o consenso t\u00e9cnico atual de como agentes persistentes s\u00e3o constru\u00eddos, incluindo o que a pr\u00f3pria OpenAI exp\u00f4s na Agents API em beta. N\u00e3o \u00e9 especula\u00e7\u00e3o sobre o Aeon. \u00c9 o mecanismo que qualquer produto dessa categoria (Aeon, Muse, Grok Bot, Gemini Spark) precisa implementar de alguma forma. Detalhes propriet\u00e1rios de como a OpenAI faz compacta\u00e7\u00e3o, escalonamento e sandboxing continuam fechados.<\/p>\n
Como testar isso voc\u00ea mesmo<\/h2>\n
O caminho mais curto para entender agente persistente na pr\u00e1tica \u00e9 construir um pequeno, rodando localmente, sem framework:<\/p>\n
\n- Escolha uma tarefa com trigger claro e passo m\u00faltiplo. Exemplo: “a cada hora, olhe minha caixa de entrada, identifique emails que pedem resposta, rascunhe uma resposta e me mostre para aprovar”.<\/li>\n
- Implemente o loop principal em Python com tr\u00eas fun\u00e7\u00f5es:
reason(state) -> action<\/code>, execute(action) -> result<\/code>, update(state, result) -> state<\/code>.<\/li>\n- Persista o estado em SQLite. Cada itera\u00e7\u00e3o grava thought, action, result. Isso \u00e9 sua mem\u00f3ria epis\u00f3dica e seu trace de observabilidade no mesmo lugar.<\/li>\n
- Adicione compacta\u00e7\u00e3o: quando o contexto passar de N tokens, resuma tudo antes do \u00faltimo passo em uma linha e substitua.<\/li>\n
- Coloque um gate humano antes de qualquer a\u00e7\u00e3o irrevers\u00edvel (mandar email, gastar dinheiro, apagar arquivo).<\/li>\n
- Rode por 24 horas. Leia os logs. Encontre onde ele decidiu errado. Ajuste o prompt do
reason<\/code> ou os limites do execute<\/code>. Repita.<\/li>\n<\/ol>\nDepois disso, quando algum vendor (OpenAI, Meta, Google) descrever o agente always-on deles, voc\u00ea vai ler a documenta\u00e7\u00e3o com outros olhos. Vai saber onde perguntar sobre compacta\u00e7\u00e3o, sobre limite de itera\u00e7\u00e3o, sobre gate humano, sobre custo por hora ociosa. \u00c9 o \u00fanico jeito de sair do lado espectador dessa discuss\u00e3o.<\/p>\n","protected":false},"excerpt":{"rendered":"
Como funciona por baixo um agente de IA sempre-ativo: loop de execu\u00e7\u00e3o, mem\u00f3ria em camadas, harness e por que isso custa mais que um chatbot.<\/p>\n","protected":false},"author":2,"featured_media":746,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-747","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/747","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/comments?post=747"}],"version-history":[{"count":0,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/747\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media\/746"}],"wp:attachment":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media?parent=747"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/categories?post=747"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/tags?post=747"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}