Seu dot entrega trabalho raso? Como preparar o contexto da empresa antes de delegar

Agente sem contexto devolve o óbvio, e o dot não é exceção

Fala aí, beleza? A OpenAI lançou os dots no DevDay 2026, em San Francisco, no dia 29/09/2026, e muita gente já está delegando tarefa pra eles 😀

Na definição oficial, os dots são agentes sempre ativos (always-on) que vivem dentro do ChatGPT e rodam no GPT-6 Astra

Cada um tem computador e navegador próprios na nuvem, aprende com o feedback ao longo do tempo e trabalha nos seus objetivos 24/7

Só que tem um detalhe que MUITA gente vai ignorar: o dot só enxerga o material da empresa que chega até ele

Se esse material é bagunçado, desatualizado ou nem existe, o dot faz o que qualquer um faria no lugar dele: chuta o genérico

Por isso a documentação, os padrões, o glossário e os exemplos da empresa são insumo, não detalhe

Neste post te mostro como preparar tudo isso antes de delegar, passo a passo 🙂

O que você precisa antes de preparar o contexto do dot

Antes de pensar em contexto, confere se você tem acesso, beleza?

• Plano: os dots estão em liberação para assinantes Pro e Business Premium em mercados elegíveis
• Brasil: está entre os mercados elegíveis desde o lançamento
• Regiões: o Pro exclui Espaço Econômico Europeu, Suíça e Reino Unido; o Business Premium recebe em todas as regiões suportadas pelo ChatGPT
• Preço do Pro: a partir de US$ 100/mês
• Custo do dot: o primeiro vem incluso no Pro ou no Business Premium, sem custo extra (no futuro vai dar pra adicionar mais dots e aumentar a velocidade ou o volume de trabalho mensal de cada um)
• Enterprise, Edu e Healthcare: é um beta que o administrador precisa habilitar, e ele começa desligado; as permissões podem valer pro workspace inteiro ou para membros e grupos via custom roles
• Onde criar: no app desktop do ChatGPT (macOS ou Windows) ou em chatgpt.com/dots no navegador desktop; pelo celular não dá

E o item que ninguém lista: o material interno já reunido

Docs, padrões de código, glossário do negócio e exemplos de entrega boa

Se isso ainda não existe organizado, é por aí que você começa (e é o que o resto do post cobre)

Passo a passo: como preparar o contexto interno antes de delegar ao dot

A ideia aqui é a mesma de receber um dev novo no time

Você não senta o cara na cadeira e fala "se vira", né? Tu entrega a documentação, explica como o time escreve código, traduz o jargão e mostra um trabalho bem feito como referência

Com o dot é igualzinho, só que ele não vai te perguntar no cafezinho o que significa aquela sigla haha

1. Entenda de onde o dot tira contexto

O porquê antes do como: pra preparar o material certo, você precisa saber por onde ele entra

O dot tem três fontes de memória:

• herda as memórias do seu ChatGPT
• forma memórias próprias a partir dos apps conectados
• se ajusta ao seu feedback

E aqui vem o limite que muda tudo: hoje não dá para ver, editar ou apagar memórias individuais do dot

Ou seja, o que entra precisa entrar certo

O erro comum deste passo: conectar material desatualizado achando que dá pra corrigir depois, memória por memória

Não dá! O caminho é caprichar na origem

2. Organize a documentação nos arquivos que você vai conectar

Pega a documentação que importa pro objetivo que você vai delegar e junta num lugar só, dentro dos arquivos que você pretende conectar

Remove versão antiga, marca o que é oficial e elimina duplicata

É a mesma lógica de preparar documentos antes do NotebookLM: a qualidade da resposta se decide antes da pergunta

O erro comum deste passo: docs espalhadas em vários lugares, com duas versões dizendo coisas diferentes

Se nem o time sabe qual está valendo, imagina o agente…

3. Registre os padrões de código num documento claro

Segundo a documentação, o dot atua mais como coordenador: pode usar agentes em segundo plano, abrir novas threads na nuvem e criar tarefas de Work ou Codex num computador conectado

Se ele vai coordenar trabalho de código, o padrão do time precisa estar escrito em algum lugar que ele enxergue

Nomenclatura, estrutura de pastas do projeto, como vocês tratam erro, o que é proibido no código e por aí vai

Um documento claro, em linguagem direta, dentro dos arquivos conectados

O erro comum deste passo: o padrão que só existe na cabeça do dev sênior

"Ah, aqui a gente sempre faz assim", mas ninguém nunca escreveu 😛

4. Escreva o glossário do negócio

Toda empresa tem seu dialeto: siglas, nomes internos de produto, apelido de cliente, etapa do funil com nome próprio

Pra você é óbvio, pro agente é ruído

Um glossário simples já resolve muiiito. Modelo ilustrativo (adapte pra sua empresa):

GLOSSÁRIO (modelo)

Onboarding D7: sequência de e-mails dos primeiros 7 dias do cliente novo
Conta Ouro: cliente com contrato anual e suporte prioritário
Bug P1: falha que impede o cliente de usar o produto; prioridade máxima
Release de quinta: janela semanal de deploy, sempre na quinta à tarde

O erro comum deste passo: assumir que o agente conhece o jargão da empresa

Ele não conhece, e vai preencher a lacuna com o significado genérico da palavra

5. Separe exemplos de entrega boa

Aqui mora a diferença entre entrega rasa e entrega que parece do time

Em vez de descrever "quero um relatório objetivo e bem estruturado", mostra 2 ou 3 relatórios que ficaram bons de verdade

Exemplo concreto vale mais que qualquer adjetivo

O erro comum deste passo: descrever o que você quer em vez de mostrar

"Objetivo" significa uma coisa pra você e outra pra qualquer outra pessoa (ou agente)

6. Conecte os apps no onboarding

A configuração inicial é assim: abre os dots no ChatGPT e segue o onboarding

Dá um nome, escolhe um avatar e conecta apps como e-mail, agenda e arquivos

Dá pra pular essa etapa e conectar depois, e isso é útil se o material ainda não está pronto

Os dots conseguem acessar mais de 4.000 apps pelo ecossistema de plugins da OpenAI, mas se liga: mais apps não significa mais contexto bom

Tem outro motivo pra curadoria: enquanto você não está conversando com ele, o dot vasculha os apps conectados procurando formas de ajudar (a OpenAI chama isso de proactive research)

Ele vai ler o que estiver lá, bom ou ruim

O erro comum deste passo: conectar tudo sem curadoria e o dot aprender com ruído

Pasta de rascunho abandonado, doc de 2021 e planilha de teste viram contexto também 😅

7. Delegue com objetivo claro e defina as Custom Rules

A delegação funciona assim: você dá um objetivo ao dot, conecta os apps de que ele precisa e define o que ele pode fazer sozinho

O objetivo tem que dizer o quê, pra quê e como fica uma entrega pronta. Modelo ilustrativo:

OBJETIVO (modelo)

Acompanhar os bug reports do produto e, toda sexta, montar um resumo
no formato do exemplo "relatorio-bom-marco", separando Bug P1 dos demais
(ver glossário). Me avisar na hora se surgir um Bug P1

Já o que ele faz sozinho fica nas Custom Rules

Cada regra define uma ação (compartilhar, comprar, acessar algo) e atribui um comportamento:

• agir sem perguntar
• agir se pré-aprovado
• perguntar antes de agir
• passar para você

E o Auto-review continua valendo: antes de uma ação que possa afetar suas contas ou compartilhar informação, uma revisão separada confere a ação contra suas instruções, permissões, Custom Rules e os requisitos de segurança da OpenAI

O exemplo da Central de Ajuda: antes de enviar um e-mail, ele confere o destinatário e a mensagem

As Custom Rules não desligam o Auto-review nem os requisitos básicos, beleza?

O erro comum deste passo: objetivo vago do tipo "cuida dos bugs pra mim"

Objetivo vago é convite pro óbvio

8. Revise o resultado e dê feedback

O dot devolve o resultado para revisão, e é nesse momento que ele melhora

Como ele se ajusta ao seu feedback (e você não edita memória individual), o feedback é o seu volante

Feedback bom é específico: "esse termo aqui significa X no nosso glossário", "segue o formato do exemplo tal", "isso é Bug P1, não P2"

O erro comum deste passo: aprovar tudo com "ok, valeu" ou só reclamar sem dizer o que estava errado

Aí ele não tem como aprender a diferença

Por que o dot entrega trabalho raso (e como corrigir)

Se o resultado veio fraco, quase sempre dá pra rastrear a causa. Olha o mapa:

Sobre o sintoma de "pergunta demais ou age demais", já passei por isso com outra ferramenta

Não foi com dot: foi quando testei o MiMo Code, uma IA de programar, e o vídeo está aqui embaixo

No vídeo eu mostro que o modelo ficava perguntando várias vezes coisas básicas antes de executar, e isso atrasava a entrega

Testei o modo "never ask", que trava o modelo pra ele seguir direto, mas pareceu valer só pro próximo prompt, porque ele voltou a perguntar depois

E esse tipo de trava pede cautela, senão a ferramenta faz coisa errada sem confirmação

O que funcionou melhor foi outra coisa: quando pedi a funcionalidade seguinte, escrevi um prompt detalhado com escopo restrito (o assistente não seria um chat aberto, só explicaria as ferramentas, com um botão "explicar com IA" em cada uma)

Mesmo assim, no fim o assistente veio configurado com um modelo diferente do que eu tinha pedido

Moral da história: liberar autonomia não substitui objetivo claro, e revisar a entrega continua obrigatório

No dot, as Custom Rules são justamente o lugar pra calibrar isso por ação, sem um "liga/desliga" genérico

Como prevenir

Mantenha a fonte de verdade atualizada nos apps conectados

Doc mudou? Atualiza lá. Padrão novo? Escreve lá. Termo novo no negócio? Entra no glossário

Como a pesquisa proativa vasculha esses apps, manter eles limpos é manutenção contínua, não tarefa de uma vez só

Onde o contexto bem preparado faz mais diferença no dot

Os exemplos oficiais de responsabilidade contínua são dois: manter um lançamento nos trilhos e acompanhar bug reports

Nos dois, o dot segue trabalhando entre uma conversa e outra e avisa quando precisa de uma decisão

É aí que o contexto pesa MAIS, porque ele vai tomar microdecisões sem você olhando

Manter um lançamento nos trilhos:

O que esse caso pede de material:

• Glossário: nome interno do lançamento, etapas, quem é responsável por quê
• Documentação: cronograma oficial e critérios do que é "pronto"
• Exemplos: um status report de lançamento anterior que ficou bom
• Custom Rules: o que ele pode compartilhar sozinho e o que precisa passar por você

Acompanhar bug reports:

O que esse caso pede de material:

• Glossário: o que é cada prioridade na sua empresa (o "P1" de vocês não é o P1 de todo mundo)
• Padrões de código: se ele for criar tarefas de Codex num computador conectado, o padrão do time precisa estar escrito
• Exemplos: um resumo de bugs bem feito, no formato que o time lê de verdade
• Objetivo: quando avisar na hora e quando só consolidar no resumo

E pra acompanhar, dá pra conversar com o dot pelo ChatGPT (desktop, web e mobile), por Slack e Teams, e também por chamada de voz

Ou seja, ele te encontra onde o time já está 🙂

Próximo passo: monte seu kit de contexto antes do primeiro objetivo

Recapitulando: o dot é tão bom quanto o material da empresa que ele enxerga

Ele herda as memórias do seu ChatGPT, aprende com os apps conectados e se ajusta ao feedback, e como hoje você não edita memória individual, o capricho tem que ser na origem

O próximo passo prático é montar o seu kit:

1. Reunir a documentação que importa, sem versão antiga
2. Escrever os padrões de código num documento claro
3. Montar o glossário do negócio
4. Separar 2 ou 3 exemplos de entrega boa
5. Conectar só o que é fonte confiável
6. Criar o primeiro objetivo claro e calibrar as Custom Rules
7. Revisar as primeiras entregas com feedback detalhado

Começa com um objetivo pequeno, do mesmo jeito que você faria pra testar um modelo no próprio projeto antes de adotar de vez

Deu certo? Aí sim aumenta a responsabilidade dele

E se o dot te devolver algo raso, volta na tabela de sintomas, porque a causa quase nunca é mistério haha

Até o próximo post!