Quatro Relatos de Escrita por Agente. Dois Descrevem uma Trava Antes da Escrita.

Em agosto lemos a cobertura do plugin da Salesforce para o Claude e encontramos exatamente um controle nomeado: herança de permissões. Limiares de aprovação, limites de taxa de escrita e reversibilidade ficaram fora de tudo o que a empresa escolheu destacar. Escrevemos na época que eles podiam existir de todo modo, e que um controle que você não consegue nomear é um controle que o seu time de risco não consegue revisar.

A documentação do próprio fornecedor agora nomeia um deles. “By default, Claude asks the seller to approve each proposed change before it’s written.” Em português: por padrão, o Claude pede ao vendedor que aprove cada mudança proposta antes de ela ser escrita. A frase está na documentação do produto, o que a torna o material mais forte disponível sobre essa pergunta. Ela também carrega duas palavras que fazem quase todo o trabalho: por padrão. Um padrão é uma posição inicial. A frase omite quem tem autorização para mudá-la.

Outros três relatos publicados em 14 e 15 de setembro de 2026 respondem à mesma pergunta, e respondem de forma suficientemente distinta para que os quatro relatos formem uma taxonomia. Um artigo de imprensa setorial sobre a Figma, publicado em 14 de setembro, corrobora a posição mais fraca dessa taxonomia.

O que a Salesforce entregou, e o que o anúncio ainda deixa aberto

A escala merece ser dita antes dos controles. O Salesforce in Claude traz 37 skills e 2 conectores, e a Anthropic relata 7.000 vendedores Salesforce, além de implantações no GitLab, na Siemens e na Legora. Está em beta em todos os planos pagos. Sete mil vendedores e beta em todos os planos pagos não é um piloto.

O modelo de identidade está citado literalmente: “Sellers sign in with their Salesforce credentials and Claude reads only what their permissions allow.” Os vendedores entram com as credenciais da própria Salesforce e o Claude lê apenas o que as permissões deles autorizam. Nada é criado para o agente. Ele toma emprestada uma concessão que o vendedor já tinha, a mesma propriedade que aceitamos pelo valor de face em agosto e que continua governando apenas quais registros estão ao alcance.

A frase sobre aprovação é a parte nova. Por mudança proposta, antes da escrita, com um humano no caminho. É uma resposta direta à pergunta de raio de alcance, e é a resposta que dissemos estar faltando.

Uma escrita aparece no anúncio sem etapa explícita de aprovação: adicionar como contatos da conta os stakeholders encontrados em threads de e-mail e Slack. Minha leitura é que o anúncio está traçando uma linha entre criar um registro de baixa consequência e alterar um registro existente. O anúncio não afirma que essa é a linha, então trate a leitura como minha, não como deles.

Quatro relatos, quatro posições

Aprovação por escrita. O padrão da Anthropic pede ao vendedor que confirme cada mudança proposta. A unidade de consentimento é a escrita individual.

Aprovação por classe de ação. A WorkOS publicou uma tabela de decisão com três desfechos dentro de um único fluxo: buscar cobranças é permitido, emitir reembolso exige aprovação, excluir o registro de um cliente é negado. A unidade de consentimento é o tipo de operação, decidido de antemão, e um dos três desfechos é uma recusa em vez de um aviso na tela. Essa diferença pesa mais do que parece. Uma negação dispensa humano em tempo de execução, então não há como desgastá-la com um vendedor clicando em aprovar quarenta vezes seguidas.

Aprovação no momento da concessão, com procedência em cada chamada. A Theory Ventures é uma gestora de venture capital descrevendo uma ferramenta que construiu para uso interno e opera há um ano. O acesso de escrita é concedido, nas palavras deles, “only when the task requires it and we are comfortable with the scope and consequences of the changes”: somente quando a tarefa exige e quando estão confortáveis com o escopo e as consequências das mudanças. O relato coloca a trava no momento em que a capacidade é entregue e não descreve pergunta a cada uso. O que compensa isso é instrumentação: toda chamada de ferramenta carrega um campo task_context e um ID de conversa compartilhado, e cada operação de escrita ganha a própria ferramenta em vez de dividir uma genérica. A atribuição está desenhada desde o início, exatamente a propriedade que encontramos faltando na trilha de auditoria do CRM.

Nenhuma trava no relato. O changelog do Linear sobre Loops descreve uma execução que “can automatically update the launch plan and post a Slack message explaining what changed, why, and who needs to act”: pode atualizar automaticamente o plano de lançamento e postar uma mensagem no Slack explicando o que mudou, por quê e quem precisa agir. Nenhuma etapa de aprovação aparece em qualquer parte desse changelog. O changelog aponta para a documentação de Loops do próprio Linear, que eu não li, então a afirmação honesta é que o changelog não descreve nenhuma. O que ele descreve é revisão posterior: “Each loop run starts a conversation with Linear Agent. Once it finishes, you can continue that conversation like any other agent session to review the work”. Cada execução abre uma conversa com o Linear Agent e, quando termina, você pode continuar essa conversa como qualquer outra sessão de agente para revisar o trabalho.

Revisão retrospectiva é um mecanismo real. É também um mecanismo de outra natureza. Uma conversa que você abre depois que o plano de lançamento mudou e a mensagem do Slack saiu conta o que aconteceu. Ela não decide se aquilo deveria ter acontecido.

O caso da Figma corrobora a quarta posição

Os plugins generativos da Figma estão em beta aberto, conforme o texto da imprensa setorial. Não podem ser monetizados e rodam dentro da interface nativa PropsKit, sem as chamadas a APIs de terceiros que os plugins clássicos podem fazer. Essa última restrição é uma fronteira de contenção, e das relevantes.

O que o artigo não descreve é qualquer trava sobre o código gerado: nenhum sandbox para a primeira execução, nenhum pedido de permissão, nenhum diff, nenhuma execução a seco, nenhuma revisão antes da publicação. A única salvaguarda citada é o conselho de testar com cuidado. O texto é comentário de imprensa setorial, não fonte primária, seus fatos principais remetem a quatro artigos da central de ajuda da Figma, e o autor sinaliza a própria especulação onde ela ocorre. A data em que o beta abriu não está em nenhuma fonte que eu tenha. Leia o caso como corroboração de um padrão, e apenas isso.

Uma única afirmação quantificada nos cinco relatos

Aqui está o número que decide quanto vale essa taxonomia. Nos cinco relatos existe exatamente uma afirmação quantificada de desempenho: o “100x multiplier on time-to-useful-result for some requests” da Theory, um multiplicador de 100x no tempo até um resultado útil para algumas solicitações, sem benchmark e ressalvado na própria frase pelo “algumas”. Não há nenhum número de acurácia e nenhum de taxa de erro em lugar algum.

Nenhum dos cinco relatos oferece evidência de que uma trava antes da escrita custa vazão, e nenhum oferece evidência de que uma escrita sem trava produz erro. A taxonomia não pode ser ordenada por resultado, porque nenhum resultado foi medido. O que ela revela é de quem cada desenho confia no julgamento, e em que momento pede por ele. Os dois desenhos que perguntam antes da escrita são os dois que descrevem escrita em registros de negócio. Os dois relatos sem trava descrevem escrita de documentos e artefatos: um plano de lançamento, um plugin. Os dois relatos soam como se essas escritas fossem baratas de errar.

Já tratamos da arquitetura ao redor no stack de contenção de quatro andares. Dois textos anteriores ficam ao lado deste: Não Confie no Agente, Medeie-o e Sua Frota de Agentes Roda Sem Kill Switch. O que esses quatro relatos acrescentam é mais estreito e mais útil: um conjunto de posições em que você pode estar, tenha escolhido uma ou não.

Faça isso agora: coloque cada caminho de escrita em uma das quatro posições

Reserve uma hora. Liste todo caminho pelo qual um agente escreve qualquer coisa na sua empresa, incluindo os que escrevem documentos em vez de registros. Para cada caminho, preencha três células.

A posição. Por escrita, por classe de ação, no momento da concessão, ou nenhuma. Escreva as palavras. Um caminho que você não consegue classificar é um caminho em que ninguém decidiu, e ele vai assumir o valor “nenhuma”.

Padrão ou invariante. Se a trava é um padrão, nomeie quem pode desligá-la e se essa mudança fica registrada. A frase da Anthropic é o modelo aqui: um padrão é uma boa posição inicial e uma garantia fraca. Uma invariante imposta na fronteira em que a escrita acontece é um controle. Um padrão que o usuário limpa numa quinta-feira corrida é uma preferência.

Uma operação negada. A tabela da WorkOS tem uma linha que recusa em vez de avisar. Escolha uma operação em cada caminho que o agente nunca pode executar, independentemente de quem aprove, e imponha isso onde a escrita é executada. Se toda linha da sua tabela for “exige aprovação”, você construiu uma fila de confirmações, e a fadiga de confirmação vai esvaziar essa fila no seu lugar.

Eu começaria pelos caminhos que escrevem documentos, porque são os que não têm trava descrita em nenhum dos relatos acima, e porque um plano de lançamento que mudou em silêncio é mais difícil de notar do que uma oportunidade reclassificada. Ninguém abre relatório de incidente por uma frase errada em um plano. As pessoas tomam decisões com base nela.

Fontes

Anthropic. “Bringing Salesforce into Claude.” Setembro de 2026.
WorkOS. “Who gets to define an AI agent’s intent?.” Setembro de 2026.
Theory Ventures. “Building a Company Brain People Actually Want to Use.” Setembro de 2026.
Linear. “Loops for product management.” Setembro de 2026.
Web Designer Depot. “Figma Is Turning Designers Into Plugin Makers.” Setembro de 2026.

A Victorino ajuda times a colocar cada caminho de escrita de agente em uma posição nomeada antes que o padrão se torne a política: contato@victorino.com.br | www.victorino.com.br