Como o ChatGPT Work arquiteta agentes para escalar a bilhões de usuários

A OpenAI lançou em 9 de julho o ChatGPT Work, seu produto de agente voltado a trabalho de conhecimento. Numa análise detalhada publicada no Latent Space, Shlok Khemani fez uma engenharia reversa do produto: cutucou o sistema por dentro (com ajuda do próprio Codex) para entender o que é, como funciona e para onde vai. O ponto que interessa a quem constrói: Greg Brockman confirmou que Work e Chat vão se fundir até o fim do ano. Ou seja, as escolhas de arquitetura do Work vão virar o default de um produto com cerca de 1 bilhão de usuários semanais. Não é um nicho para power users, é um preview.

O que é o Work, na prática

No núcleo, o Work é um agente que você conecta às ferramentas onde já trabalha (Slack, e-mail, Drive, calendários, CRMs) e que reúne contexto para produzir entregas prontas: planilhas, docs, slides e até Sites (web apps e dashboards hospedados com URL compartilhável).

Detalhe importante para quem pensa em infraestrutura: cada tarefa roda num microVM isolado e persistente. Contas Pro recebem 8 CPUs, 20GB de RAM e disco de 64GB; Plus fica com 14GB de RAM. Junto vem um serviço gerenciado de Chrome que o agente opera via tool calls. Por baixo, tudo roda no harness do Codex, herdando modelos, sub-agentes e a capacidade de moer uma tarefa por horas. A UI apenas esconde os vestígios de código (controles git, diffs) que denunciariam que você está falando com um agente de programação.

Memória: liberdade dentro da task, controle entre tasks

A decisão de design mais reveladora está na memória. Dentro de uma tarefa, o agente tem a liberdade de um computador Linux normal: cria pastas em /workspace/scratch, instala dependências, escreve scripts, mantém bancos de dados. Mas a continuidade entre tarefas não passa pelo sistema de arquivos, e sim por uma camada de produto opinativa do ChatGPT.

Cada nova thread recebe um resumo comprimido das tarefas recentes. Transcrições brutas não ficam no computador: quando precisa de contexto de outra conversa, o agente chama uma ferramenta dedicada (Personal Context) que consulta o histórico via serviço separado. Arquivos seguem lógica parecida, com a Library como repositório canônico, acessível só por ferramentas.

Isso tem um efeito colateral concreto que Khemani apontou: um arquivo enviado existe em dois lugares, uma cópia local na thread e um item canônico na Library, e os dois não sincronizam. Se a Thread A sobe um arquivo e a Thread B altera a versão da Library, a Thread A continua lendo a cópia desatualizada. É o tipo de armadilha que um dev integrando o produto precisa mapear.

Por que a OpenAI separou assim, em vez do modelo mais soberano de ferramentas como o OpenClaw, onde tudo vive no computador? A hipótese de Khemani cobre três frentes: reaproveitar primitivas que já servem um bilhão de usuários (refatorar seria caro), tratar a separação como guardrail de segurança (acesso irrestrito a um único ambiente com todos os arquivos e memórias é inseguro) e manter controle do produto sobre UI, sync entre dispositivos e versionamento.

Proatividade e tarefas agendadas

O Work dá um primeiro passo em direção à proatividade, o santo graal da IA pessoal. Ao abrir uma conversa, ele sugere tarefas geradas do seu contexto: notou um evento no calendário, inferiu que preparar a reunião ajudaria, puxou dados de Gmail e Agenda e montou um prompt. Mas nada acontece até você executar. Proatividade de verdade seria completar a tarefa sem você no loop.

As Automations (que a OpenAI chamava de Scheduled Tasks em janeiro de 2025) evoluíram para versão agêntica. Há dois tipos: a standalone, que abre uma tarefa nova a partir de um prompt salvo, e a agendada dentro de uma conversa existente, acionada por um heartbeat que reativa a task com o contexto intacto. Vale notar: heartbeats funcionam no desktop, mas ainda não estão expostos na versão web.

Plugins: a peça que interessa ao desenvolvedor

Esta é a parte mais relevante para quem constrói. Depois de anos oscilando entre Plugins (2023), GPTs, Actions, connectors e apps, a OpenAI parece ter convergido em plugins como o primitivo de conexão. Um plugin pode conter Apps (que geralmente expõem tools via servidor MCP), Skills (instruções mais material de apoio) e templates.

Desenvolvedores podem criar plugins pessoais conectando um MCP server próprio e, se quiserem distribuição, submeter à OpenAI para publicação no diretório, que já passa de 1.000 plugins.

O calcanhar de Aquiles, segundo o teste de Khemani, é a descoberta. O Work roteia tarefas para plugins instalados sem esforço, mas nunca sugere um plugin ausente quando ele resolveria melhor. Pedindo busca de voos, o agente ignorou plugins de viagem disponíveis e foi de web search, mesmo quando o autor citou a Expedia nominalmente. Para uma empresa que quer virar plataforma, é valor deixado na mesa. Para o dev que publica um plugin, é um alerta: estar no diretório não garante uso.

Como resume Khemani, o Work está longe de acabado (a arquitetura pode mudar em semanas), mas consolida anos de experimentos dispersos em algo coeso. Vale acompanhar de perto, porque essas decisões vão definir como um bilhão de pessoas usam agentes.

Fonte: Latent Space