Notion agora deixa o agente sugerir a edição em vez de aplicar — e esse é o botão que decide se sua automação sobrevive
O Dani Geek — arte original
Em 28 de agosto o Notion liberou o modo “suggest edits”: o agente propõe, você aprova linha por linha. Parece ajuste de UI. É a diferença entre o fluxo que você mantém há seis meses e o que você desligou na segunda semana.
O que mudou, e o que continua igual
A nota de release de 28/08/2026 é curta: “Your agents can now propose changes instead of making them directly. Ask your agent to suggest edits, then move top to bottom to approve each one.”
Repare no verbo: ask. O padrão do agente continua sendo aplicar direto. O modo sugestão é uma segunda opção, que existe se você pedir. A documentação de suggested edits descreve o resultado do jeito que qualquer um que já usou controle de alterações no Word ou revisou um pull request reconhece: um diff, com aceitar e rejeitar em cada bloco.
Isso não enfraquece o argumento — afia. A escolha não é da empresa, é sua, e você faz essa escolha toda vez que abre uma conversa com o agente. Que é exatamente o tipo de decisão que ninguém toma conscientemente e todo mundo paga depois.
E existe um segundo portão, mais alto, que quase ninguém achou
Enquanto verificava a release, esbarrei numa página de ajuda que resolve um problema maior: o Plan mode (Configurações → Mode → Plan). A frase do próprio Notion: “Planning is read-only: Notion Agents won’t make edits until you approve the plan.”
Com o Plan mode ligado, o agente não escreve nada enquanto planeja. Ele junta contexto, faz perguntas, monta uma página de plano. Você lê, corrige o que entendeu errado, e só então clica em Approve plan — aí ele executa.
São dois portões em alturas diferentes, e essa é a parte que importa:
- Plan mode trava a intenção, antes. Você aprova uma unidade: “ele entendeu o que eu quis dizer”.
- Suggest edits trava a execução, depois. Você aprova 40 pedacinhos: “ficou bom?”.
Quem não separa os dois acaba usando o portão errado para a dúvida errada — e reclama que revisar dá mais trabalho que fazer à mão. Dá mesmo, quando o portão está na altura errada.
Isso tem nome desde 1978
O que o Notion acabou de expor num menu é literatura antiga de fator humano. Sheridan e Verplank descreveram, num relatório do MIT de 1978, uma escala de níveis de automação — e os níveis 4 e 5 são precisamente estes: o computador sugere uma alternativa, e o computador executa a sugestão se o humano aprovar. Cinquenta anos de engenharia de aviação e de usinas nucleares para descobrir que o botão certo é “propor”.
O outro lado da moeda também é acadêmico. O clássico de Parasuraman e Riley, Humans and Automation: Use, Misuse, Disuse, Abuse (Human Factors, 1997), dá nome ao que você fez com aquele fluxo do n8n: disuse. Não é preguiça nem “resistência à mudança”. É o comportamento previsível de um operador que perdeu a confiança na automação e passou a fazer no braço, porque conferir o trabalho dela custava mais caro que refazer.
Automação que escreve sozinha transfere o custo para depois: agora você audita tudo, sem saber o que ela mexeu. Automação que propõe paga o custo na hora, num diff de dois segundos. O total pode até ser parecido. A distribuição é que decide se você continua usando.
A metade honesta: portão demais mata igual
Se propor fosse sempre melhor, a resposta seria ligar tudo e ir dormir. Não é.
Centros de operação de segurança são o experimento em escala: times afogados em alerta simplesmente param de olhar. O número que circula na literatura de alert fatigue é que cerca de 62% dos alertas são ignorados, com times processando milhares por dia — e há uma revisão da ACM Computing Surveys inteirinha sobre o problema. Aprovação que vira ritual não é controle, é carimbo.
E carimbo tem consequência medida. Em prescrição eletrônica, pesquisa sobre viés de automação mostra clínicos trocando a decisão certa deles pela sugestão errada do sistema — o alerta não só falhou em proteger, ele induziu o erro. Se isso acontece com médico e receita, acontece com você às onze da noite aprovando o quadragésimo bloco de um diff no Notion.
Ou seja: o portão só funciona enquanto você ainda lê o que passa por ele.
A regra prática que eu passei a usar
Escolha o portão pela dúvida, não pelo medo:
“Será que ele entendeu o que eu quis?” → Plan mode. Vale quando o agente vai mexer em várias páginas, quando a tarefa é vaga (“reorganiza a base de conteúdo por status”), quando o estrago é estrutural. Você revisa uma unidade com sentido em vez de 40 ações soltas — e é justamente isso que evita o carimbo automático do parágrafo anterior.
“Será que ficou bom?” → suggest edits. Vale quando a intenção é óbvia e a execução é que é discutível: passada de gramática, padronizar tom em 12 posts, reescrever descrições curtas. O diff aqui é rápido de ler porque cada linha é independente.
“Nenhuma das duas” → deixa aplicar direto. Tem tarefa que não merece portão nenhum: mover itens entre status, preencher campo derivado, criar página de template. Se o custo de desfazer é um Ctrl+Z, portão ali só ensina você a clicar sem ler.
O erro comum é ligar o portão mais alto em tudo, sentir o atrito e desligar tudo duas semanas depois. Já vi acontecer com pull request de time — e agora vai acontecer com agente.
O que eu ainda não sei (e é o parágrafo mais útil que falta)
Uma dúvida honesta, que a documentação não responde e eu não vou fingir que testei: o modo sugestão cobre propriedade de banco de dados ou só texto corrido?
Faz toda a diferença. Se o agente propõe alteração no parágrafo mas altera direto o campo Status da sua base de projetos, o portão está aberto justamente onde o estrago é silencioso — ninguém percebe uma data mudada; todo mundo percebe um parágrafo reescrito.
É teste de cinco minutos: uma base pequena, um pedido que mexa em texto e em propriedade, e ver o que aparece como sugestão. Vou rodar e volto com o resultado — inclusive se contrariar o que escrevi aqui.
O fio para puxar
O que me interessa nisso é que o Notion está convergindo, por conta própria, para um desenho que já existe em ferramenta de desenvolvedor: plano aprovado antes, diff depois. É o mesmo par de portões que o Claude Code e os editores de código com agente expõem hoje. Duas comunidades que não conversam chegaram na mesma arquitetura porque o problema é o mesmo — não é sobre IA, é sobre delegação, e delegação sem ponto de conferência sempre volta como retrabalho.
Se isso é verdade, o próximo passo é previsível: o portão vira granular por tipo de ação, e não por sessão. “Pode mexer no texto sozinho, mas pergunta antes de mudar qualquer coisa que outra pessoa consome.” Ninguém entregou isso ainda, em nenhuma ferramenta que eu use.
Qual automação você desligou, e qual dos dois portões teria salvado ela? Me conta no X ou no Threads — quero montar a próxima peça em cima de casos reais, não de teoria.