Claude Duet: a IA agora quer acompanhar seu trabalho, mesmo quando você fecha o chat

Tem uma parte do trabalho que quase nunca aparece na lista de tarefas: lembrar da própria lista. Conferir se aquela resposta chegou, descobrir se a pendência mudou de responsável, abrir de novo a planilha que faltava completar. Você passa o dia ocupado e, quando percebe, gastou uma boa parcela dele procurando o ponto em que havia parado.

Quem trabalha com várias frentes conhece essa sensação. O navegador vira uma coleção de assuntos inacabados. Cada aba promete: “depois você volta aqui”. Algumas já poderiam pagar aluguel.

É por isso que o Claude Duet chamou minha atenção. Vejo uma discussão interessante sobre continuidade: como uma ferramenta pode acompanhar um trabalho ao longo do tempo e devolver à pessoa o que realmente exige uma decisão?

A Anthropic anunciou o Claude Duet em 21 de outubro de 2026, como uma versão experimental por lista de espera, inicialmente para assinantes Pro e Max nos Estados Unidos. Portanto, esse anúncio não representa disponibilidade geral no Brasil. [1]

Minha análise parte da documentação pública. Não estou relatando um teste pessoal do Duet. Quero olhar para a proposta com a cabeça de quem desenvolve integrações e precisa fazer a automação caber na rotina.

O que muda quando a conversa continua

O Duet usa um computador na nuvem e recursos da conta Claude, incluindo memória e aplicativos conectados, para continuar tarefas e avisar quando precisa do usuário. [2]

O ponto que me interessa é o intervalo entre receber uma demanda e encerrá-la. Imagine uma pessoa preparando uma proposta comercial. Ela tem parte dos dados, aguarda uma confirmação e depende de um documento. Um resumo bem escrito ajuda, mas o trabalho continua aberto depois que esse resumo fica pronto.

Eu avaliaria um assistente desse tipo pela capacidade de acompanhar essas dependências. Ele identificou o que faltava? Deixou claro quem precisa agir? Diferenciou o documento recebido da versão aprovada? Conseguiu retomar o assunto sem obrigar a pessoa a narrar toda a história novamente?

Esse seria um avanço útil: diminuir o esforço de reconstruir o contexto a cada retomada. É também uma expectativa exigente. Um assistente que mantém uma lista bonita, mas perde o motivo de cada pendência, acaba terceirizando a organização de volta para o usuário.

O olhar de quem desenvolve integrações

No trabalho que desenvolvo com a Oombe, lido com automação de marketplaces e demandas que envolvem Mercado Livre, Shopee, publicação e transferência de anúncios, catálogos, compatibilidades e pagamentos. Essa experiência me faz prestar muita atenção ao que acontece entre uma solicitação e um resultado conferido.

Pense em uma alteração de catálogo. Existe o pedido inicial, a identificação dos itens, a regra aplicável, o processamento e a conferência. Dependendo do caso, ainda há alguma exceção que exige uma pessoa. Cada etapa carrega informação que precisa chegar à seguinte.

Quando olho para agentes que acompanham o trabalho, vejo uma possibilidade interessante de ajudar a organizar essa camada de pendências. A pergunta que eu faria seria: “você consegue me devolver uma visão verificável do que precisa de atenção?”.

Perceba a exigência da palavra verificável. Eu gostaria de saber de onde veio a informação, a que momento ela se refere e o que ainda falta confirmar. Um texto convincente sem esses elementos me daria mais uma etapa de investigação.

Isso não significa que exista integração nativa do Duet com a Oombe ou com o Mercado Livre. Os exemplos abaixo são hipóteses de trabalho, condicionadas a acesso autorizado, ferramentas compatíveis e testes. Eles servem para explicar o que eu procuraria em um piloto.

Três situações em que eu procuraria utilidade

Reunir pendências de uma operação

Eu começaria por algo delimitado: uma exportação autorizada de registros, preparada para análise, com os dados necessários à tarefa. O pedido seria organizar pendências por motivo, indicar quais informações faltam e produzir uma lista de conferência.

Imagine registros com observações sobre cadastro incompleto, informação divergente e validação pendente. Uma boa análise preservaria o identificador de cada item e apontaria a evidência usada para agrupá-lo. Quando não houvesse informação suficiente, o resultado esperado seria marcar a dúvida.

A partir daí, eu poderia avaliar se a organização me ajudou a escolher por onde começar. Seria especialmente útil identificar vários registros relacionados à mesma causa possível, desde que a hipótese permanecesse identificada como hipótese. O ganho estaria em facilitar a investigação, sem transformar semelhança de texto em diagnóstico confirmado.

Preparar uma resposta que alguém consiga revisar

Outra experiência possível seria fornecer uma solicitação e um conjunto autorizado de informações para preparar uma resposta. Eu pediria que o rascunho separasse o que já foi confirmado do que depende de verificação e destacasse qualquer compromisso de prazo.

Esse detalhe faz diferença. “Estamos verificando” e “estará resolvido amanhã” produzem expectativas muito diferentes. Ao revisar, eu precisaria conseguir identificar rapidamente qual afirmação tem suporte e qual exige uma decisão minha.

Também avaliaria se o texto responde à dúvida da pessoa. Um rascunho pode estar impecável em português e continuar fugindo do assunto. Nesse caso, o polimento só deixou a revisão mais traiçoeira. O objetivo do piloto seria obter uma resposta útil, com linguagem humana e fatos conferíveis, antes de qualquer envio autorizado.

Retomar um assunto sem recomeçar do zero

Uma terceira hipótese seria acompanhar uma pequena demanda com mudanças de estado: documento solicitado, material recebido, conferência em andamento, dúvida devolvida. Eu definiria esses estados antes e pediria um resumo das mudanças relevantes.

O resumo deveria dizer o que mudou desde a revisão anterior. Repetir tudo todos os dias pode criar uma rotina cansativa, especialmente quando o usuário precisa descobrir sozinho qual linha contém a novidade.

Eu também pediria que pendências antigas continuassem visíveis até existir um motivo para encerrá-las. Afinal, o silêncio de uma conversa não resolve automaticamente o assunto. Às vezes, só significa que todo mundo está esperando outra pessoa responder.

Conectar aplicativos é uma decisão de engenharia

Antes de qualquer piloto, eu faria um pequeno mapa: qual informação entra, por qual caminho, quem pode vê-la e que resultado deverá sair. Essa conversa costuma ser mais útil do que começar perguntando quantos aplicativos a ferramenta consegue conectar.

Para mim, uma integração precisa responder a perguntas concretas. O acesso permite consultar ou também alterar? O arquivo contém informações suficientes? Existe um identificador estável? Como reconhecer que a análise usou uma versão antiga? Quem confere o resultado?

Se o piloto depender de exportações, eu definiria a frequência e o formato de atualização. Se depender de um conector, conferiria as operações efetivamente disponíveis. Se houver navegação por uma interface, eu verificaria as condições e limitações daquele caminho antes de assumir que ele serve ao processo.

O mesmo cuidado vale para automatizar uma decisão. Eu começaria mantendo as regras objetivas em um lugar que possa ser conferido: critérios de agrupamento, prioridades e condições de encerramento. A contribuição da IA seria avaliada dentro desse desenho.

É um trabalho de tradução entre necessidade e funcionamento. Quem conhece a operação tem um papel central nessa conversa, porque sabe o que cada campo quer dizer e quais situações parecem iguais na tela, mas pedem tratamentos diferentes.

Memória útil precisa de contexto atualizado

Eu gostaria que um assistente lembrasse preferências de apresentação e o andamento das demandas. Ao mesmo tempo, trataria regras que mudam como informações que precisam de data e revisão. Uma orientação antiga pode continuar soando perfeitamente razoável depois de deixar de servir ao processo.

Por isso, num piloto, eu registraria a origem das regras e quando elas devem ser conferidas novamente. Também separaria preferências pessoais, instruções de uma tarefa e critérios permanentes da operação. Essa distinção ajuda a decidir o que deve acompanhar o trabalho seguinte.

Há um detalhe concreto na documentação: desconectar um aplicativo interrompe novos acessos, mas não apaga automaticamente o que já entrou na memória; o usuário pode redefini-la. [3]

Eu incluiria essa verificação no encerramento de qualquer experiência. Testar uma ferramenta também envolve entender como retirar acessos e limpar o contexto que deixou de fazer sentido.

Aprovação precisa ajudar a decidir

A Anthropic descreve aprovações para ações relevantes, checagem externa ao modelo e proteções ainda sujeitas a erros. [3]

No meu desenho de piloto, uma aprovação útil mostraria exatamente a ação proposta, seu destino e as informações utilizadas. Eu precisaria entender a consequência antes de confirmar, sem ter de reconstruir o trabalho inteiro.

Se uma mensagem estiver pronta para envio, quero revisar o destinatário e o texto. Se a proposta for atualizar um registro, quero comparar o estado atual com a alteração sugerida. Se faltar informação, prefiro receber a pergunta específica que destrava o trabalho.

Também definiria quais decisões precisam chegar até mim. Quando tudo pede atenção, fica difícil reconhecer o que é realmente importante. O desenho dessa rotina deveria proteger o tempo de quem revisa e preservar uma possibilidade real de dizer “espere, isso precisa mudar”.

Como eu organizaria um primeiro piloto

Eu escolheria um único processo, com começo, término e responsável claros. Reunir pendências de uma exportação seria um bom candidato inicial. “Organizar toda a empresa” deixaria o resultado impossível de avaliar e daria à ferramenta espaço demais para interpretar o objetivo.

Antes de começar, eu executaria uma rodada pelo método habitual e anotaria o trabalho necessário: localizar arquivos, conferir campos, agrupar itens, revisar conclusões e preparar a próxima ação. Isso criaria uma referência concreta.

Depois, prepararia os dados de teste e definiria o resultado esperado. Por exemplo: uma relação de pendências com identificador, motivo, evidência, próxima ação sugerida e indicação de dúvida. Se o caso exigir interpretação, eu deixaria explícito que a ferramenta deve apresentar alternativas em vez de escolher silenciosamente.

A primeira revisão teria duas perguntas: consigo rastrear cada conclusão até o material fornecido? O resultado está pronto para o uso combinado? Um relatório pode estar correto e ainda exigir tanto ajuste de formato que a tarefa continua quase inteira nas mãos da pessoa.

Na rodada seguinte, eu acrescentaria uma pequena atualização ao mesmo processo. Assim, avaliaria a continuidade: o assistente percebeu a mudança, preservou o que seguia pendente e evitou refazer o que já estava resolvido?

Por fim, documentaria as exceções encontradas e decidiria se vale ampliar o teste. Essa ampliação deveria acompanhar o que foi demonstrado. Se a ferramenta organizou bem arquivos, o próximo passo pode ser outra tarefa de organização. Alterar preços ou comprometer prazos exige uma avaliação própria.

O relógio deve contar a revisão também

Eu mediria o tempo total gasto pela pessoa para chegar a um resultado aproveitável. Entrariam na conta a preparação do material, as instruções, a conferência, as correções e o acompanhamento. Tempo de processamento da ferramenta seria registrado separadamente.

Também observaria a qualidade das interrupções. Quantos avisos ajudaram a agir? Quais eram dispensáveis? Houve alguma pendência importante que só apareceu quando a pessoa voltou a investigar manualmente? A experiência precisa reduzir a carga de acompanhamento, além de produzir documentos.

Sobre o produto, há limites concretos: o trabalho em segundo plano consome a franquia compartilhada do plano, as verificações ocorrem em intervalos e a ferramenta pode interpretar mal a urgência. [4]

Eu levaria essas condições para o planejamento. Um processo que exige resposta imediata merece um mecanismo adequado a esse prazo. Já uma revisão periódica de pendências pode tolerar outra cadência. Essa escolha depende do trabalho e precisa ficar clara antes de alguém começar a confiar no acompanhamento.

O conhecimento da operação ganha outra função

A parte dessa discussão que mais me anima é transformar experiência em orientação utilizável. A pessoa que conhece a rotina pode explicar por que determinada pendência merece prioridade, qual evidência confirma uma conclusão e quando uma exceção precisa ser encaminhada.

Esse conhecimento ajuda a desenhar o piloto, avaliar os resultados e melhorar a automação. Para desenvolvedores e integradores, vejo espaço em construir essas passagens com critérios claros, dados bem definidos e resultados que possam ser conferidos.

Vou acompanhar o Claude Duet por esse ângulo: quanto da organização e da continuidade ele consegue assumir de forma útil, dentro das condições que oferece?

Para mim, um bom resultado seria terminar o dia com menos assuntos abandonados entre abas, mensagens e arquivos, sabendo o que foi feito e o que ainda precisa de mim. Já seria uma bela ajuda. E talvez desse para fechar algumas daquelas abas que estão quase entrando no contrato de locação.

Fontes

[1] Anthropic. Introducing Claude Duet. Publicado em 21/10/2026.

[2] Anthropic. Claude Duet: página oficial do produto.

[3] Anthropic. Claude Duet Safety, Privacy, and Security. Publicado em 23/10/2026.

[4] Claude Help Center. Get started with Claude Duet.

Documentação consultada em 25/10/2026. Recursos e condições da versão experimental podem mudar.