Copilot Studio sem Topics: vale migrar agora nas cooperativas?

Copilot Studio sem Topics: a decisão que cooperativas de crédito não podem adiar

A nova experiência do Copilot Studio removeu os Topics. Quem constrói agentes hoje precisa orquestrar toda a conversa usando apenas instructions e skills, sem o grafo visual de nós, condições e trigger phrases que sustentou a maioria dos agentes de atendimento publicados nos últimos dois anos. Para cooperativas de crédito, que já têm agentes clássicos rodando em centrais de atendimento, portais do associado e canais de WhatsApp, essa mudança não é um detalhe de versão. É uma decisão de arquitetura com impacto direto em compliance, auditoria e continuidade operacional.

A resposta curta é: não migre agentes críticos agora, mas comece a testar a nova experiência em casos de baixo risco. Copilot Studio sem Topics ainda é uma arquitetura em maturação. Para fluxos que envolvem PLD, KYC, abertura de conta ou negociação de dívida, o determinismo dos Topics continua insubstituível. Para agentes novos, de escopo simples e sem exigência de trilha auditável rígida, a nova experiência já entrega valor e vale o investimento de aprendizado.

O que muda de fato na arquitetura sem Topics

No modelo clássico, cada Topic é um nó de decisão explícito. Trigger phrases disparam um fluxo, condições If/Else desviam o caminho, variáveis são setadas em pontos previsíveis do grafo. Um analista de compliance consegue abrir o Topic de abertura de conta e mostrar exatamente qual pergunta acontece antes de qual validação. Isso é auditoria por desenho.

Na nova experiência, o comportamento nasce de um bloco único de instructions em linguagem natural, complementado por skills que são carregadas sob demanda quando o modelo julga que a condição foi atendida. Não existe mais um grafo fixo. O modelo interpreta a instrução, decide qual skill invocar e conduz a conversa de forma probabilística, não determinística. A vantagem é flexibilidade: menos manutenção de nós, menos duplicação de lógica, agentes que generalizam melhor para variações de linguagem do associado. A desvantagem é perda de previsibilidade estrita, o mesmo ponto que fazia dos Topics uma escolha segura para processos regulados.

Vale registrar que isso não é um corte da noite para o dia. A Microsoft mantém o modelo clássico operante em paralelo com a nova experiência, o que muda é o destino do investimento de produto e da atenção de roadmap. Agentes já publicados com Topics continuam funcionando, mas quem cria um agente novo hoje encontra a nova experiência como caminho padrão em boa parte dos cenários.

Critério de decisão: quando migrar agora e quando esperar

A pergunta certa não é “a nova experiência é melhor”, porque em abstrato ela não é nem melhor nem pior, é diferente. A pergunta certa é: o meu caso de uso tolera orquestração probabilística, ou ele exige um caminho determinístico e auditável? Cooperativas de crédito respondem essa pergunta caso a caso, e o critério muda conforme o processo.

Migre agora se

• O agente é novo, sem Topics legado para portar, e o escopo é conversacional simples: tirar dúvida sobre produto, explicar taxa, orientar sobre documentação de associação.
• O processo não gera obrigação de auditoria linha a linha. Um agente de FAQ de cartão de crédito não precisa provar, nó a nó, por que respondeu o que respondeu.
• A equipe técnica tem tempo para iterar. Ajustar instructions e testar comportamento em preview é um ciclo mais lento e menos visual do que editar um Topic, e isso exige paciência de quem valida.
• Existe apetite para experimentar skills como unidades independentes, versionadas e testáveis fora do fluxo principal, o que favorece agentes que crescem em funcionalidades ao longo do tempo sem inchar as instructions centrais.

Espere se

• O agente já está em produção com Topics e atende um processo sensível: abertura de conta, atualização cadastral, PLD, KYC, negociação de dívida ou qualquer fluxo que o compliance da cooperativa audita periodicamente.
• A área de risco ou auditoria interna exige rastreabilidade de decisão por etapa, algo que o grafo de Topics entrega nativamente e que instructions em prosa não reproduzem com a mesma clareza para um auditor não técnico.
• Não há orçamento ou prazo para redesenhar a lógica de conversação do zero, o que é exatamente o que a migração exige, e não uma tradução de tela.
• A integração depende de conectores ou de Dataverse em profundidade que hoje têm suporte mais maduro no modelo clássico do que na nova experiência.

A armadilha: achar que dá para portar Topics para Skills sem redesenhar

O erro mais comum, e o que provavelmente já está passando pela cabeça de quem lê este texto, é tentar pegar um Topic existente e transformá-lo mecanicamente em uma skill. Pegar o Topic de consulta de saldo, com seus nós condicionais, suas variáveis de sessão e seu fluxo de confirmação, e simplesmente reescrever aquilo em um arquivo skill.md, linha por linha, esperando o mesmo comportamento.

Isso não funciona, e a razão é estrutural. Um Topic é um grafo determinístico: o motor de execução segue o caminho definido pelas condições, sempre da mesma forma, para a mesma entrada. Uma skill carregada por instructions é interpretada por um modelo de linguagem que decide, a cada turno, se aquela skill é relevante e como aplicá-la. Não existe garantia de que a ordem de passos que você escreveu em prosa será seguida com a mesma rigidez de um If/Else visual. O modelo pode pular uma etapa que parecia implícita, pode interpretar uma instrução ambígua de forma diferente do esperado, pode não invocar a skill certa se a descrição dela não for específica o suficiente.

A consequência prática em uma cooperativa é grave. Um Topic de simulação de crédito consignado que sempre pedia CPF, depois validava o vínculo com a folha, depois calculava a parcela, na versão portada sem redesenho pode inverter a ordem, pular a validação de vínculo em uma conversa mais informal, ou responder com um valor de parcela antes de confirmar o prazo. Não é um bug de código, é a natureza do modelo probabilístico executando uma lógica que foi pensada para um motor determinístico.

O caminho correto é tratar a migração como um projeto de redesenho de conversação, não como uma tradução de artefato. Isso significa reescrever o core da lógica como instructions que descrevem o papel do agente, a sequência de passos em linguagem imperativa clara, e as regras gerais que valem para toda a conversa, exatamente como qualquer bom prompt de sistema é escrito. As skills entram depois, isoladas, para os caminhos que só acontecem sob condição específica, como consultar um documento externo ou tratar uma exceção. Skills bem descritas, com nome e propósito inequívocos, aumentam a chance do modelo invocá-las no momento certo. Skills genéricas ou mal descritas produzem exatamente o comportamento errático que assusta quem está avaliando a mudança.

Coexistência: clássico e novo modelo lado a lado

A boa notícia para quem tem portfólio de agentes publicados é que a coexistência é viável, e deve ser a estratégia padrão pelos próximos ciclos. Não existe necessidade de migrar tudo de uma vez, nem sentido em fazer isso. Uma cooperativa pode manter o agente de abertura de conta e o agente de atendimento a associado inadimplente rodando no modelo clássico, com Topics auditáveis, enquanto testa a nova experiência em um agente de suporte interno ao time de TI ou em um assistente de FAQ sobre linhas de crédito rural.

Essa convivência tem um custo de governança que precisa entrar na conta: duas arquiteturas diferentes para manter, dois modelos mentais para o time de desenvolvimento dominar, e a necessidade de documentar claramente qual agente usa qual modelo, para evitar que alguém tente aplicar um padrão de Topics em um agente que já nasceu na nova experiência, ou o inverso. Times de Power Platform de cooperativas costumam ser enxutos, então essa divisão de arquitetura precisa ser decidida no nível de liderança técnica, não deixada para cada desenvolvedor escolher isoladamente.

O ponto de atenção real não é técnico, é de maturidade do harness de orquestração da própria Microsoft. A capacidade do modelo de decidir corretamente quando invocar uma skill, de manter contexto de conversa longa sem instructions, e de lidar com exceções fora do roteiro escrito, ainda está evoluindo release a release. Esperar alguns ciclos antes de migrar processos críticos não é conservadorismo vazio, é gestão de risco proporcional ao que está em jogo quando o agente fala em nome da cooperativa com um associado.

Quando não usar a nova experiência agora

Existem cenários em que a resposta simplesmente não é “ainda não”, é “não, para esse caso, o modelo clássico continua sendo a escolha certa” até que a arquitetura amadureça de forma perceptível.

• Processos com exigência regulatória de trilha de decisão. Se o compliance da cooperativa precisa demonstrar ao Banco Central ou a um auditor externo qual pergunta o agente fez antes de qual validação, o grafo de Topics ainda é a ferramenta certa. Instructions em prosa não substituem essa evidência com o mesmo nível de clareza.
• Agentes com múltiplos fluxos de exceção interdependentes. Quando o Topic atual tem dezenas de ramificações condicionais que se cruzam, como um agente de negociação de dívida com regras de desconto por faixa de atraso, o esforço de redesenho para instructions e skills pode ser maior que o ganho de flexibilidade obtido.
• Times sem capacidade de teste iterativo intenso. A nova experiência exige mais ciclos de preview e ajuste fino de prosa do que o modelo visual de Topics. Sem essa disciplina de teste, o agente vai para produção com comportamento imprevisível.
• Integrações profundas com Dataverse ou conectores customizados que ainda não têm paridade total na nova experiência. Vale checar, caso a caso, a documentação atual da Microsoft antes de assumir que um conector que funciona bem no modelo clássico se comporta igual na nova arquitetura.

A decisão que fica

Copilot Studio sem Topics não é uma atualização de interface, é uma mudança de paradigma de orquestração, de determinístico para probabilístico. Para cooperativas de crédito, o critério prático é simples de enunciar e difícil de ignorar: migre agora os agentes novos, de baixo risco regulatório, onde o time pode iterar com calma. Espere para migrar os agentes que já sustentam processos auditados, e trate qualquer migração futura como projeto de redesenho de conversação, nunca como port de Topic para skill.md.

A Trinapse acompanha cooperativas de crédito na avaliação de arquitetura de agentes de IA, desde a decisão de manter, migrar ou coexistir até o redesenho da lógica de conversação quando a migração faz sentido.