Season 7 15 Episódios 55 min 2026

Microsoft Copilot Studio

Edição de 2026. Uma análise técnica aprofundada ao Microsoft Copilot Studio, abrangendo Generative Orchestration, Agent Flows, ferramentas, Enterprise Grounding e muito mais (2026).

Frameworks de AI/ML Orquestração de LLM Prototipagem Visual

🌐 English 🇪🇸 Español 🇫🇷 Français 🇵🇹 Português 🇮🇹 Italiano 🇵🇱 Polski 🇩🇪 Deutsch 🇷🇴 Română

A Reproduzir

Click play to start

0:00

Generative Orchestration

Descubra a mudança de paradigma das clássicas frases de ativação para o Generative Orchestration no Microsoft Copilot Studio. Saiba como a IA seleciona dinamicamente Topics e ferramentas com base em descrições, eliminando totalmente a necessidade de um mapeamento conversacional rígido. Este episódio explica como o encaminhamento inteligente lida com consultas de múltiplas intenções sem esforço.

3m 53s

Criação de Agentes Baseada em IA

Saiba como utilizar a linguagem natural para acelerar o processo de criação do seu bot. Exploramos a criação de agentes baseada em IA, permitindo-lhe gerar Topics, Prompts e fluxos complexos simplesmente descrevendo-os. Entenda como os LLMs são utilizados em tempo de compilação para criar protótipos de agentes rapidamente.

3m 30s

Topics e Nodes

Mergulhe na anatomia estrutural de um agente. Este episódio analisa os Topics de System versus Custom, e a lógica determinística de Nodes necessária para regras de negócio específicas. Aprenda a delinear caminhos conversacionais precisos utilizando variáveis e condições.

3m 28s

State e Variables

Dê memória ao seu agente. Descubra como trabalhar com Variables no Copilot Studio para passar o contexto entre Topics, eliminando perguntas repetitivas. Exploramos também a utilização de environment variables para armazenar com segurança os segredos do Azure Key Vault.

3m 28s

Entities e Slot Filling

Extraia dados estruturados a partir de linguagem natural não estruturada. Este episódio explica as prebuilt entities, listas fechadas personalizadas, regex entities e a magia do Proactive Slot Filling, que permite à IA saltar perguntas quando o utilizador fornece informações antecipadamente.

4m 15s

Enterprise Knowledge Grounding

Transforme os dados empresariais existentes num especialista conversacional. Saiba como ligar o SharePoint, o Dataverse e websites públicos como fontes de conhecimento (Knowledge) para as Generative Answers. Descubra os limites e as capacidades de fazer o grounding da sua IA.

3m 55s

Tenant Graph Grounding

Liberte todo o poder do Microsoft Graph e da pesquisa semântica para uma obtenção de dados de alta precisão. Este episódio explora o Tenant Graph Grounding, utilizando licenças do Microsoft 365 Copilot para pesquisar documentos empresariais massivos com uma profunda compreensão semântica.

3m 43s

Prompt Tools

Capacite o seu agente para executar tarefas específicas de processamento de dados ou sumarização em tempo real. Saiba como criar Prompt Tools, definir modelos, especificar inputs e configurar formatos de resposta diretamente no Copilot Studio.

3m 46s

Agent Flows

Ligue o Copilot Studio a automações de backend complexas e de várias etapas utilizando Agent Flows. Este episódio detalha como adicionar fluxos do Power Automate como ferramentas, enfatizando o limite crítico de execução de 100 segundos e os requisitos de resposta síncrona.

3m 45s

Power Platform Connectors

Aceda a milhares de APIs existentes nos ecossistemas da Microsoft e de terceiros. Descubra como utilizar os Power Platform Connectors como ferramentas ativas nos seus agentes do Copilot Studio para interagir com serviços externos sem esforço.

3m 50s

Computer Use Tool

Automatize sistemas legados que não possuem APIs utilizando automação baseada em visão. Descubra a Computer Use Tool em preview, que tira partido de modelos como o Claude Sonnet 4.5 para interagir com interfaces gráficas de utilizador através de um rato e teclado virtuais, com todas as barreiras de segurança empresariais.

3m 18s

Autenticação de Utilizadores

Proteja o seu agente e desbloqueie experiências personalizadas. Mergulhe na Autenticação de Utilizadores no Copilot Studio, comparando a opção 'Authenticate with Microsoft' com configurações manuais de OAuth2. Aprenda a configurar scopes e a garantir o acesso de menor privilégio (least privilege access).

3m 16s

Voz e IVR

Tire o seu agente do teclado e leve-o para a linha telefónica. Descubra as capacidades de Interactive Voice Response (IVR) do Copilot Studio. Aprenda sobre reconhecimento de voz, DTMF (entradas de teclado), barge-in e como personalizar as vozes dos agentes com SSML.

4m 03s

Agent Analytics

Não é possível melhorar o que não se mede. Este episódio analisa o dashboard de Analytics no Copilot Studio, explicando a visualização híbrida para sessões conversacionais versus autónomas, e como exportar transcrições para uma análise profunda.

3m 47s

Model Context Protocol

Prepare os seus agentes para o futuro com a norma aberta para contexto de IA. Saiba como integrar o Copilot Studio com servidores externos de Model Context Protocol (MCP) para ingerir Resources, Tools e Prompts de forma dinâmica.

3m 54s

Episódios

Generative Orchestration

3m 53s

Download

Olá, daqui fala o Alex da DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 1 de 15. A maioria dos criadores de bots passa horas a tentar prever e mapear todas as frases possíveis que um utilizador possa escrever. Adicionas cinquenta variações de um pedido de suporte, e o sistema continua a falhar quando alguém escreve uma frase que não previste. A Orquestração Generativa elimina completamente essa necessidade através do matching dinâmico de descrições. Muitas vezes, quando as pessoas ouvem a palavra generativo neste contexto, assumem que significa gerar texto conversacional. Não é o caso aqui. A Orquestração Generativa tem estritamente a ver com routing dinâmico e seleção de tools. É a inteligência que decide que ação tomar, em vez de apenas escrever uma resposta. Na orquestração clássica, constróis um topic e defines manualmente uma lista de trigger phrases. O motor de natural language understanding depende dessas frases exatas para fazer o routing do utilizador. A Orquestração Generativa remove as trigger phrases por completo. Em vez disso, escreves uma descrição clara em plain-text para cada topic e tool no teu agente. O large language model subjacente lê a query do utilizador, avalia todas as tuas descrições disponíveis e determina dinamicamente o melhor match. Já não estás a mapear inputs para triggers. Estás simplesmente a descrever o que as tuas tools fazem. Isto muda completamente a forma como um agente lida com inputs complexos. Imagina um utilizador que pergunta: Qual é a previsão do tempo em Seattle e a que horas abre a loja? Num setup clássico, isto falha. O sistema deteta dois intents em conflito e, ou adivinha um, ou lança um erro de fallback. A Orquestração Generativa lida com isto sem qualquer esforço. O modelo faz o parse da frase inteira e reconhece dois objetivos distintos. Ele faz o scan das tuas descrições. Primeiro, encontra uma tool de meteorologia. Extrai Seattle da query do utilizador, passa-o para a tool de meteorologia como um input parameter e executa-a. A seguir, lembra-se da segunda metade do prompt do utilizador. Volta a analisar os teus topics, encontra aquele que está descrito como gerir o horário de funcionamento da loja, e faz o trigger. Aqui está o ponto chave. O agente faz o chain destas ações automaticamente. Ele processa o pedido de meteorologia e, a seguir, transita de forma fluida para o topic do horário da loja, combinando os resultados. Não escreves qualquer lógica de routing ou código de transição para que isto aconteça. Esta mudança significa que a qualidade do teu agente agora depende inteiramente da qualidade das tuas descrições. Se a descrição da tua tool de meteorologia disser simplesmente meteorologia, o modelo pode ter dificuldades em fazer o routing com precisão. Se a descrição disser obtém as condições meteorológicas atuais para o nome de uma cidade específica, o routing torna-se exato. Além disso, se um utilizador fizer trigger a essa tool de meteorologia, mas se esquecer de especificar a cidade, o motor generativo repara automaticamente que falta um required parameter. Ele vai gerar dinamicamente uma pergunta para pedir a cidade ao utilizador antes de executar a tool. A principal conclusão é esta. A Orquestração Generativa transforma o routing de um exercício frágil de phrase-matching numa pesquisa inteligente de capacidades, libertando-te para te focares no que o teu agente consegue fazer, em vez de adivinhares como é que o utilizador o vai pedir. Se quiseres apoiar o programa, podes encontrar-nos ao pesquisar por DevStoriesEU no Patreon. Por agora é tudo. Obrigado por ouvires, e continua a construir!

Criação de Agentes Baseada em IA

3m 30s

Download

Olá, daqui é o Alex da DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 2 de 15. Normalmente, criar um flow conversacional significa arrastar nodes para um canvas, ligar manualmente árvores lógicas e adivinhar todas as possíveis trigger phrases que o teu utilizador final possa escrever. Mas e se pudesses simplesmente dizer a uma IA exatamente o que queres construir, e deixar que ela gere a lógica estrutural por ti? Este mecanismo chama-se agent authoring baseado em IA. É fundamental distinguir isto do comportamento da IA em runtime. Os developers costumam confundir IA generativa em build time com IA generativa em runtime. O runtime é quando um utilizador real faz uma pergunta e o agente gera dinamicamente uma resposta usando uma knowledge base externa. O authoring em build time é completamente diferente. É quando usas um assistente de IA dentro do studio para construir a framework estática do próprio agente. Começas no canvas de authoring. Em vez de clicares para adicionar elementos individuais, interages com o painel de authoring do Copilot. Imagina que precisas de um flow para lidar com devoluções de hardware. Escreves uma descrição em inglês simples a pedir um tópico que pergunte ao utilizador o número da encomenda, verifique se o artigo é um portátil ou um dispositivo móvel, e depois forneça a morada de devolução correta com base no tipo de equipamento. Quando submetes esse prompt, o modelo de compreensão de linguagem natural processa as tuas instruções e mapeia-as diretamente para o schema interno de nodes do Copilot Studio. Ele gera automaticamente um conjunto de trigger phrases diversas que um utilizador real poderia dizer para iniciar este flow específico. Coloca um node de pergunta no canvas para capturar o número da encomenda e atribui-lhe uma variável. Estabelece um node de condição para ramificar a lógica entre um portátil e um dispositivo móvel. A seguir, preenche os nodes de mensagem finais com moradas de devolução em placeholder. Todo o esqueleto do tópico aparece no teu ecrã instantaneamente. Aqui está o ponto-chave. Este processo de authoring é estritamente iterativo. Não és obrigado a aceitar a geração inicial como produto final. Se olhares para o flow gerado e perceberes que precisas de capturar a data de compra, não tens de quebrar as ligações manualmente e inserir um novo node. Basta dizeres ao Copilot de authoring para adicionar uma pergunta a pedir a data de compra, logo antes de pedir o número da encomenda. O modelo subjacente analisa o estado atual do teu canvas, compreende o ponto de inserção sequencial e modifica o flow com segurança. Como a IA traduz a linguagem natural diretamente em componentes standard do Copilot Studio, tu manténs o controlo arquitetónico completo. Os nodes gerados não são caixas negras. São exatamente os mesmos elementos que terias criado manualmente. Podes clicar nas branches de condição, ajustar os tipos de variáveis, ou reescrever o texto do prompt à mão. O modelo de linguagem simplesmente trata da montagem mecânica do canvas. O verdadeiro poder do authoring baseado em IA não é escrever flows conversacionais perfeitos à primeira tentativa, mas sim transformar o lento processo mecânico de ligar nodes num diálogo rápido sobre a intenção de negócio. Obrigado por estares aí. Espero que tenhas aprendido algo novo.

Topics e Nodes

3m 28s

Download

Olá, daqui fala o Alex da DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 3 de 15. Mesmo os agentes de IA mais avançados acabam por precisar de lógica determinística para regras de negócio específicas. Quando um cliente pergunta sobre a tua política de devoluções ou o horário de funcionamento da loja, não te podes dar ao luxo de usar um palpite probabilístico de um modelo de linguagem. Precisas de uma resposta estrita e garantida. Os Topics e os Nodes dão-te esse controlo estrutural exato. Pensa num Topic como um caminho de conversação discreto. É uma árvore de diálogo predefinida que dita exatamente como o teu agente lida com uma intent específica. O teu agente, no geral, é essencialmente uma coleção destes Topics a trabalhar em conjunto para encaminhar o utilizador. Um ponto frequente de confusão é a distinção entre System topics e Custom topics. É mais simples do que parece. Os System topics lidam com os comportamentos fundamentais do agente. Estes governam eventos centrais como cumprimentar um utilizador, encerrar uma conversa, escalar para um humano, ou apanhar um erro quando o agente não entende o input. Podes modificar o texto deles para corresponder à voz da tua marca, mas não os podes apagar. São elementos permanentes da arquitetura do sistema. Os Custom topics são os caminhos que tu próprio constróis, totalmente sob o teu controlo, para lidar com os teus cenários de negócio específicos. Dentro de cada Topic, a conversa é executada de cima para baixo através de passos individuais chamados Nodes. Os Nodes são os blocos de construção funcionais do caminho. Para entenderes como interagem, imagina um Custom topic desenhado para lidar com questões sobre o horário da loja. Quando o utilizador aciona este Topic, o primeiro passo no teu flow pode ser um Question node. Um Question node pede informações ao utilizador e espera por um tipo específico de resposta. Neste caso, o agente pergunta que cidade o utilizador planeia visitar. Quando o utilizador responde, o Node captura essa resposta. Isto introduz a gestão de Variables. O Question node guarda automaticamente a resposta do utilizador numa variable. Agora tens um pedaço distinto de state em memória, permitindo-te encaminhar a conversa dinamicamente com base no que o utilizador acabou de dizer. É aqui que a coisa fica interessante. Em vez de dares uma resposta genérica, adicionas um Condition node para avaliar essa variable. Um Condition node atua como uma bifurcação lógica no caminho. Ele verifica o state atual da tua variable em relação às regras que definires. Se a cidade guardada for Nova Iorque, o Node direciona o flow por uma branch. Se a cidade for Londres, direciona o flow por outra. Podes adicionar as branches que precisares para diferentes states, mais uma fallback branch caso a variable não corresponda a nenhuma cidade conhecida. Finalmente, no final de cada branch condicional, colocas um Message node. Um Message node simplesmente exibe texto ou media de volta para o utilizador. A branch de Nova Iorque chega a um Message node a informar que a loja abre às nove da manhã. A branch de Londres chega a um Message node diferente a informar que a loja abre às dez. Ao encadear Question, Variable, Condition e Message nodes, ditas exatamente como a lógica flui. A principal conclusão aqui é que os Topics isolam as tuas regras de negócio determinísticas em caminhos previsíveis, garantindo que o teu agente responde de forma fiável quando a precisão importa mais do que a geração. Obrigado por ouvires. Até à próxima!

State e Variables

3m 28s

Download

Olá, daqui é o Alex do DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 4 de 15. A maneira mais rápida de frustrar um utilizador é fazê-lo repetir informação que te acabou de dar. Se o teu bot pede um nome, arranca um novo workflow, e depois pede o nome outra vez, a experiência do utilizador quebra por completo. O mecanismo que impede esta amnésia é o state e as variáveis. Uma variável no Copilot Studio guarda dados extraídos do utilizador ou obtidos de um sistema de backend. A decisão mais importante que tomas ao criar uma variável é definir o seu scope. Os ouvintes costumam confundir variáveis ao nível do topic com variáveis globais. Uma variável ao nível do topic é estritamente local. Só existe enquanto o seu topic pai estiver ativo. No momento em que esse topic termina, a variável é limpa da memória. Uma variável global, por outro lado, persiste durante toda a conversa. Qualquer topic a pode ler, e qualquer topic pode fazer overwrite. É tentador transformar cada pedaço de dados partilhado numa variável global. Não faças isso. O uso excessivo de variáveis globais cria mudanças de state imprevisíveis quando os topics se interrompem uns aos outros. Em vez disso, passa variáveis locais diretamente entre topics. Pensa num topic chamado Greeting. Ele pede o nome ao utilizador e guarda-o numa variável local. O topic Greeting termina, e o flow é redirecionado para um novo topic chamado Talk to Customer. Para passares o nome, configuras o topic Talk to Customer para receber valores de outros topics. Defines uma variável de input neste topic de destino. Depois, de volta ao teu topic Greeting, o node de redirect vai automaticamente pedir-te para mapeares um valor para esse input. Passas a variável local do nome através do node. O topic de destino apanha-a, o bot continua a conversa usando o nome correto, e o teu state global continua limpo. Quando esse topic de destino termina o seu trabalho, também pode devolver valores ao topic original que o chamou usando variáveis de output. Isto cobre os dados gerados durante um chat. Agora, a segunda parte envolve dados de que o teu agent precisa antes sequer de um chat começar. Se o teu agent se liga a sistemas externos, precisa de credenciais. Nunca deves guardar API keys ou connection strings em variáveis de conversa. Para isso, usas environment variables. As environment variables vivem inteiramente fora da sessão do utilizador. Guardam dados de configuração que se aplicam ao próprio agent, permitindo-te mover o teu bot de um ambiente de desenvolvimento para testes, e finalmente para produção, sem fazeres hardcoding de valores. Presta atenção a esta parte. Ao lidar com dados altamente sensíveis, as environment variables integram-se diretamente com o Azure Key Vault. Em vez de colares uma password no Copilot Studio, crias uma environment variable marcada como secret. Esta variável guarda uma referência para uma key específica no teu Azure Key Vault. Durante o runtime, o agent vai buscar o secret de forma segura para autenticar o request ao backend. O secret nunca é exposto no authoring canvas, nunca é impresso nos logs do chat, e é excluído das tuas exportações de source control. O state mais seguro é um state com scope, por isso mantém as variáveis de conversa locais sempre que possível, passa-as explicitamente entre os limites dos topics, e delega sempre as credenciais de sistema para environment variables seguras. Obrigado por ouvirem, happy coding a todos!

Entities e Slot Filling

4m 15s

Download

Olá, daqui é o Alex do DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 5 de 15. Crias um bot para receber pedidos, mas ele força os utilizadores a passar por cinco perguntas chatas. O utilizador já te deu todos os detalhes na primeira mensagem, mas o teu bot ignora esse contexto e continua a perguntar um por um. Este comportamento rígido frustra os utilizadores, e é exatamente este o problema resolvido por Entities e Slot Filling. As Entities são a forma como o Copilot Studio reconhece assuntos do mundo real no meio de linguagem natural confusa. Pensa numa entity como um data type específico que o teu bot é treinado para identificar dentro de uma frase. Em vez de analisar toda a frase "Gostava de gastar vinte euros", a IA simplesmente procura a entity de dinheiro e extrai o valor vinte. O Copilot Studio vem com um grande conjunto de prebuilt entities. Estas lidam com conceitos de dados standard out of the box. As prebuilt entities reconhecem idades, datas, cores, números, nomes e dinheiro. Elas normalizam os dados automaticamente. Quer o utilizador escreva vinte dólares, o símbolo de dólar seguido de 20, ou vinte paus, a prebuilt entity de dinheiro extrai o valor numérico exato e a moeda. Mas o teu negócio opera com terminologia específica. Para capturar isso, crias custom entities. Existem dois tipos principais de custom entities que vais usar. O primeiro é uma closed list entity. Defines uma lista estrita de itens permitidos e, a seguir, associas sinónimos a cada item. Se vendes equipamento de ar livre, podes criar uma entity de categoria de produto com um item principal chamado hiking. Depois, adicionas sinónimos como trekking, backpacking e trail walking. Quando o utilizador escreve qualquer um desses sinónimos, a IA mapeia o seu input diretamente para o valor principal hiking. O segundo tipo custom é a entity de expressão regular, ou regex. Usas regex entities quando os utilizadores precisam de fornecer strings formatadas em vez de palavras específicas. Um use case comum é um ticket de suporte ou um order ID. Se o teu sistema usa tracking numbers que começam sempre com as letras TRK seguidas de cinco dígitos, defines esse pattern usando regex. A IA vai analisar a mensagem do utilizador e extrair de forma limpa essa string exata, ignorando qualquer texto à volta. Identificar a entity é apenas o primeiro passo. Precisas de armazenar esses dados para os usar. Esta ação chama-se slot filling. Mapeias uma entity extraída para uma variável, preenchendo o slot com os dados do utilizador. É aqui que a coisa fica interessante. O Copilot Studio usa uma feature chamada proactive slot filling. Por default, o motor de natural language understanding avalia cada mensagem do utilizador em relação a todas as variáveis que o teu tópico de conversa exige. Se a IA detetar as entities necessárias no input inicial do utilizador, preenche esses slots imediatamente. Imagina um utilizador que faz trigger ao teu tópico de compras dizendo: Quero comprar botas de hiking por menos de 100 dólares. Tens uma custom closed list entity para a categoria de produto, e estás a usar a prebuilt money entity para o orçamento. Por causa do proactive slot filling, a IA processa essa frase inteira de uma só vez. Isola hiking, mapeia para a tua variável de categoria e armazena-a. Isola 100 dólares, mapeia para a tua variável de orçamento e armazena-a. Como esses slots já estão preenchidos, o bot faz skip automaticamente aos nodes de pergunta "Que categoria procuras?" e "Qual é o teu orçamento?". O flow de conversa salta diretamente por cima deles e avança logo para a próxima informação em falta. Ao definires entities estritas e confiares no proactive slot filling para lidar com a extração, paras de escrever decision trees rígidas e começas a construir agentes conversacionais que respeitam o tempo do utilizador. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Enterprise Knowledge Grounding

3m 55s

Download

Olá, daqui fala o Alex da DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 6 de 15. A parte mais difícil de criar um agente conversacional costumava ser prever todas as perguntas dos utilizadores e escrever as respostas manualmente. Passavas semanas a mapear árvores de diálogo, apenas para os utilizadores perguntarem algo um pouco fora do script e chegarem a um beco sem saída. O Enterprise Knowledge Grounding inverte completamente este modelo. Em vez de escreveres respostas, os teus dados corporativos existentes fazem todo o trabalho pesado. Um large language model genérico é altamente articulado, mas não sabe absolutamente nada sobre a tua empresa específica. O Enterprise Knowledge Grounding preenche esta lacuna ao ligar o copilot diretamente aos teus dados de negócio reais, como sites públicos, diretórios do SharePoint, ficheiros de que fizeste upload e tabelas do Dataverse. Imagina um cenário de suporte ao cliente. Precisas de um agent que responda a perguntas sobre o teu hardware. Em vez de criares centenas de custom topics, fazes upload dos teus manuais de produtos em PDF para o copilot e colas o URL do teu site de documentação pública. Quando um utilizador pergunta como fazer reset a um modelo específico de router, o copilot pesquisa nestas fontes ligadas, recupera o texto relevante e sintetiza uma resposta direta. Também fornece um link de citação para o manual ou página web específica, para que o utilizador possa verificar a informação. Um ponto comum de confusão é onde exatamente este conhecimento reside na arquitetura. Podes anexar conhecimento em dois locais distintos: ao nível do agent ou ao nível do topic. O conhecimento ao nível do agent é global. Atua como uma rede de segurança em todo o copilot. Se um utilizador fizer uma pergunta e nenhum topic criado manualmente for triggered, o sistema faz fallback para este conjunto global de conhecimento. Pesquisa todas as tuas fontes ligadas ao nível do agent para gerar uma resposta. Isto significa que obténs valor imediato sem precisares de escrever quaisquer custom conversation flows. Aqui está o ponto-chave. Às vezes, precisas de controlo rigoroso sobre quais os dados que a IA usa, e é aí que entra o conhecimento ao nível do topic. Configuras isto ao arrastar um node de Generative Answers diretamente para o authoring canvas de um custom topic específico. Se um utilizador fizer trigger a um custom topic para processar um pedido de garantia, não queres que a IA vá buscar respostas ao teu site de marketing geral. Ao usar um node de Generative Answers dentro desse topic específico, podes restringir a sua fonte de dados exclusivamente a uma pasta do SharePoint que contém documentos de garantia legal. A IA fica com o scope exato do contexto dessa etapa da conversa. Ao ligar estas fontes corporativas, o sistema gere o acesso de forma inteligente. Para sites públicos, o copilot simplesmente indexa as páginas públicas. Para fontes internas, como o SharePoint, o copilot usa as credenciais do Entra ID da pessoa que interage com o bot. Respeita rigorosamente as permissões de ficheiro existentes. Se um funcionário não tiver acesso a um documento interno específico no SharePoint, o copilot não lerá esse documento e não o usará para responder à sua pergunta. Para dados estruturados, podes ligar-te diretamente a tabelas do Dataverse, permitindo que o copilot faça o grounding das suas respostas nos registos em tempo real das tuas aplicações de negócio. Usar um node de Generative Answers dentro de um custom topic permite-te controlar rigorosamente os limites exatos do conhecimento da IA em pontos específicos de uma conversa, evitando que dados globais amplos interfiram em workflows altamente específicos. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Tenant Graph Grounding

3m 43s

Download

Olá, daqui fala o Alex da DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 7 de 15. A pesquisa standard por keywords falha no momento em que um utilizador faz uma pergunta complexa sobre uma política interna. Não precisas de melhores keywords. Precisas de um sistema que entenda o verdadeiro significado da pergunta em datasets massivos. É exatamente aí que entra o Tenant Graph Grounding. O Tenant Graph Grounding traz uma compreensão semântica profunda diretamente aos dados da tua empresa. Primeiro, vamos esclarecer um equívoco comum. Esta não é a pesquisa standard do Dataverse, e não tem nada a ver com fazer scraping de sites públicos. Trata-se de uma capacidade avançada de retrieval enterprise que liga o teu copilot diretamente ao Microsoft Graph. Foi desenvolvido especificamente para lidar com conhecimento interno complexo armazenado em todo o teu tenant. Para usares esta feature, o teu ambiente tem de cumprir alguns requisitos rigorosos. Precisas de uma licença do Microsoft 365 Copilot. Os teus dados precisam de ser indexados pelo Semantic Index for Copilot. Mais importante ainda, o teu copilot tem de estar configurado com autenticação Microsoft Entra ID. Isto não é opcional. O copilot tem de passar de forma segura a identidade da pessoa que faz a pergunta para o Microsoft Graph. Considera um copilot interno de RH desenhado para pesquisar manuais massivos de colaboradores. Estes manuais muitas vezes residem no SharePoint ou no OneDrive como documentos enormes. As ferramentas de retrieval standard costumam ter dificuldades com ficheiros grandes, mas o Tenant Graph Grounding suporta ficheiros com tamanhos até 512 megabytes. Quando um colaborador pergunta sobre um cenário muito específico, como a política de licença parental para um cuidador secundário a trabalhar em part-time, um motor de pesquisa tradicional procura exatamente por essas palavras. Se o manual usar termos diferentes, a pesquisa falha. Aqui está o insight principal. Como esta feature usa o Semantic Index, ela mapeia as relações conceptuais entre a query do utilizador e os dados enterprise. Entende que a query sobre licença parental mapeia conceptualmente para uma secção intitulada licença familiar, mesmo que as keywords não alinhem perfeitamente. O fluxo lógico opera inteiramente dentro da fronteira segura do teu tenant. Um utilizador submete um prompt ao copilot. O copilot usa o token do Entra ID desse utilizador específico para fazer uma query ao Microsoft Graph. O Microsoft Graph depois pesquisa no Semantic Index, mas apenas analisa os ficheiros que esse utilizador específico já tem permissões para ler. Se um documento for restrito, o Graph simplesmente ignora-o para esse utilizador. O Graph faz o retrieval dos matches semânticos altamente relevantes e devolve-os ao copilot. O copilot usa então esses chunks de dados exatos para gerar uma resposta precisa e grounded. Toda a transação acontece com uma precisão quase instantânea, evitando a latência e a imprecisão de tentares construir os teus próprios indexes de pesquisa customizados sobre os dados do SharePoint. O Tenant Graph Grounding transfere toda a carga de retrieval da tua lógica customizada diretamente para a infraestrutura semântica do Microsoft 365, garantindo que o teu copilot respeita as fronteiras de dados enterprise existentes, ao mesmo tempo que oferece uma precisão contextual incomparável. Se quiseres apoiar o programa, podes encontrar a DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Prompt Tools

3m 46s

Download

Olá, daqui fala o Alex da DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 8 de 15. Às vezes, não precisas de construir uma API complexa ou integrar um serviço de parsing externo para processar os dados recebidos. Só precisas de um large language model para olhar para uma string de texto confusa e processá-la exatamente da maneira que queres. É aí que entram as Prompt Tools. Primeiro, precisamos de esclarecer uma confusão comum. As Prompt Tools são completamente diferentes das Generative Answers. As Generative Answers examinam uma knowledge base externa ou um site para responder às perguntas dos utilizadores de forma dinâmica. As Prompt Tools não procuram respostas. São instruções específicas e altamente trabalhadas que dizem a um large language model para executar uma tarefa estritamente definida nos dados que forneces. Pensa numa Prompt Tool como uma função reutilizável onde a lógica subjacente é escrita em linguagem natural em vez de código. Crias a ferramenta definindo um prompt template, especificando variáveis de input e fornecendo regras de contexto rigorosas. Considera um cenário comum. Recebes um bloco de feedback de cliente não estruturado e confuso. Queres extrair o sentimento subjacente e gerar uma lista limpa de action items específicos. Em vez de escreveres expressões regulares complexas ou um script de parsing personalizado, crias uma Prompt Tool. Começas por definir os inputs. No Copilot Studio, crias uma variável de input chamada feedback text e defines o seu tipo de dados. Este passo simples diz à ferramenta para esperar uma string dinâmica sempre que for invocada pelo sistema. A seguir, escreves o prompt template. Este é o conjunto principal de instruções enviado para o language model. Escreves com precisão o que o modelo tem de fazer. Instruis o modelo a ler a variável feedback text, a determinar se o tom é positivo, negativo ou neutro, e a identificar quaisquer tarefas que a equipa de suporte ao cliente precise de tratar com base no texto. Aqui está o ponto chave. O template é praticamente inútil sem um contexto rigoroso. Não pedes simplesmente o sentimento ao modelo e esperas que ele responda de forma simpática. Defines a estrutura exata de output dentro do contexto do prompt. Instruis explicitamente o modelo a devolver o resultado formatado como um objeto JSON rigoroso, contendo uma key de sentimento e um array de action items. Proíbes qualquer conversa de enchimento. Este contexto transforma uma resposta genérica e faladora do language model num payload de dados estruturado e previsível, do qual os teus sistemas downstream podem realmente fazer o parsing. Quando o teu agente aciona esta ferramenta durante uma conversa ao vivo, o fluxo de execução é totalmente automatizado. O agente pega na resposta do cliente em tempo real e passa-a para o teu input de feedback text. A ferramenta injeta dinamicamente essa string no teu template, envia o pacote de instruções completo para o modelo e devolve o JSON estruturado. O agente pode então usar esses action items extraídos para atualizar automaticamente uma base de dados ou encaminhar o utilizador para uma fila de suporte especializada. Defines a ferramenta uma única vez, e o agente chama-a automaticamente sempre que reconhece a necessidade de processar texto não estruturado. Uma Prompt Tool bem construída transfere o peso do processamento complexo de texto do código da tua aplicação para o language model, permitindo-te extrair dados perfeitamente estruturados do caos completo usando apenas algumas linhas de inglês simples. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Agent Flows

3m 45s

Download

Olá, daqui é o Alex da DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 9 de 15. O teu agente precisa de executar um workflow de backend complexo que abrange vários sistemas. Talvez precise de fazer uma query a uma base de dados isolada, filtrar os dados e atualizar um sistema de inventário, tudo ao mesmo tempo. Uma única API call não consegue lidar com essa orquestração. A solução é um Agent Flow. Os Agent Flows fazem a ponte entre o Copilot Studio e o Power Automate. Permitem-te empacotar uma automação de várias etapas como uma tool independente que o teu agente pode fazer trigger de forma autónoma. O agente depende inteiramente do nome e da descrição que dás ao flow. Com base nesse texto, o agente decide se o flow pode resolver o request atual do utilizador. Quando encontra um match, o agente extrai os parâmetros necessários da conversa, passa-os para o flow, aguarda pela execução e usa o output final para gerar uma resposta. A estrutura de um Agent Flow é rígida. Tem de começar com um trigger específico desenhado para o Copilot, que define explicitamente os inputs de texto ou número. Tem de terminar com uma action específica que responda de volta ao Copilot, definindo os outputs de texto ou número. Tudo entre esses dois nodes é lógica standard do Power Automate. Podes fazer loop por arrays, chamar custom connectors ou fazer parse de ficheiros. Considera um cenário em que o teu agente precisa de ir buscar o histórico de encomendas a uma base de dados SQL legacy. O utilizador pede as suas encomendas recentes. O agente faz trigger do flow, passando a string do customer ID como input. Dentro do flow, constróis a lógica para te ligares à base de dados SQL, executar a query e formatar as linhas raw da base de dados numa string JSON limpa. O flow passa então essa string formatada de volta para o agente através do node de response. O agente lê a string, extrai os detalhes da encomenda e responde ao utilizador em linguagem natural. Aqui está o ponto chave. A execução tem de ser totalmente síncrona. O agente inicia o flow e mantém a connection aberta, à espera da response. Se construíres um flow assíncrono, não vai funcionar como uma tool do agente. Não podes incluir steps que pausem a lógica. Se o teu flow enviar um email de aprovação e ficar à espera que um humano clique num botão, o agente vai quebrar. O pattern da tool exige um retorno imediato de dados. Isto leva-nos a um hard limit do sistema. Tens exatamente cem segundos. A partir do momento em que o agente faz trigger do flow, a lógica tem cem segundos para executar cada step, fazer a query à base de dados, formatar o output e enviar a response de volta. Se o servidor SQL legacy estiver sob carga, ou se o teu flow iterar por demasiados registos, a execução vai exceder o limite de timeout. Quando isso acontece, o agente deixa cair a connection por completo e devolve uma mensagem de erro ao utilizador. Para lidar com este limite, tens de manter a automação com um scope bem definido. Se um processo de backend demorar cinco minutos, não o corras dentro do Agent Flow. Em vez disso, usa o flow para iniciar um background job externo e devolver imediatamente um tracking ID ao agente. A tua arquitetura de automação tem de respeitar a janela de timeout. Desenha os teus flows para executarem rapidamente, irem buscar exatamente o que é preciso e devolverem o controlo ao agente, garantindo que o utilizador nunca fica a falar para uma connection parada. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Power Platform Connectors

3m 50s

Download

Olá, daqui é o Alex da DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 10 de 15. Passas dias a escrever e a manter integrações de API personalizadas só para que o teu agente possa falar com o mundo exterior. Entretanto, milhares de wrappers pré-construídos já estão no teu environment, à espera de serem executados. Hoje, vamos olhar para os Power Platform Connectors. Os conectores são wrappers de API standard. Eles fornecem uma forma previsível de o Microsoft Copilot Studio comunicar com serviços externos. Antes de vermos como funcionam, precisamos de esclarecer uma confusão comum. Os utilizadores muitas vezes confundem usar um sistema externo como fonte de conhecimento versus usá-lo como uma tool. Se o teu agente faz uma query a uma base de dados apenas para recuperar factos e fundamentar as suas respostas na conversa, isso é conhecimento passivo. Usar um conector como uma tool é diferente. É uma operação ativa. Estás a dar ao agente a autoridade para executar ações, criar registos ou fazer trigger de processos externos em nome do utilizador. Existem três categorias de conectores disponíveis. Os conectores standard cobrem serviços básicos da Microsoft e endpoints públicos comuns. Os conectores premium exigem licenciamento específico e ligam-se a sistemas enterprise como o Salesforce ou o ServiceNow. Se o sistema a que precisas de aceder for uma API proprietária interna, podes construir um custom connector. Um custom connector é apenas um wrapper OpenAPI que tu próprio defines. Uma vez registado no teu environment, comporta-se exatamente como os standard e os premium. O agente não quer saber quem o construiu. Vamos ver como esta lógica flui usando um cenário concreto. Queres que o teu agente compile um resumo do projeto e o envie por email para a tua equipa de engenharia. Em vez de construíres manualmente um HTTP request, adicionas o conector do Office 365 Outlook diretamente no teu copilot como uma action. Cada conector expõe operações específicas. Neste caso, selecionas a action para enviar um email. Esta é a parte que interessa. Não escreves código procedural para ditar exatamente quando este email é enviado. Em vez disso, defines os parâmetros que o conector requer para funcionar. O conector do Outlook precisa de um endereço de destino, uma linha de assunto e o texto do body. Configuras estes inputs e forneces uma descrição clara, em linguagem simples, do que a action faz. O Copilot depende inteiramente dessa descrição para determinar quando fazer trigger à tool. Quando um utilizador diz ao agente para enviar o status update semanal para a equipa de engenharia, o agente avalia as suas tools disponíveis. Ele faz match do request do utilizador com a descrição do teu conector do Outlook. De seguida, o agente extrai dinamicamente o nome do destinatário e o texto do resumo da conversa em curso. Ele mapeia esses valores extraídos para os inputs do conector e dispara a action. Assim que a API externa processa o request, o conector passa uma response de volta para o agente. Pode ser um simples código de sucesso ou um payload com detalhes específicos sobre a transação. O agente recebe estes dados, verifica se a action foi concluída, e gera uma response em linguagem natural a dizer ao utilizador que o email foi enviado. Ao padronizar a interface, estes wrappers removem a necessidade de gerir authentication tokens, headers e error handling para cada serviço individual. Configuras a connection uma única vez, e o agente orquestra a execução. Os conectores transformam o teu agente de uma interface conversacional estática numa tool operacional que realmente altera o state em toda a tua infraestrutura. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Computer Use Tool

3m 18s

Download

Olá, daqui é o Alex do DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 11 de 15. Se uma aplicação não tem uma API, a automação tradicional bate numa parede. Ou escreves scripts frágeis que partem no momento em que um botão muda de sítio, ou aceitas a introdução manual de dados. A tool de Computer Use resolve isto permitindo que a tua IA veja literalmente o ecrã e opere a máquina por si própria. Disponível em preview, esta feature permite que o teu agent interaja com uma interface gráfica usando um rato e teclado virtuais. Baseia-se em Computer-Using Agents, alimentados por models com capacidade de visão, como o Claude 3.5 Sonnet da Anthropic. É preciso esclarecer o que isto não é. Isto não é o tradicional Robotic Process Automation. O RPA standard depende de hooks estruturais subjacentes, como tags do DOM ou IDs de elementos da UI. A tool de Computer Use opera inteiramente com pixels. O fluxo lógico é um loop contínuo. A tool tira um screenshot do ambiente desktop e passa-o para o model. O model analisa o layout visual, raciocina sobre o request do utilizador e calcula as coordenadas precisas para o seu próximo movimento. Faz output de instruções de volta para o sistema. O sistema traduz isto em mover o cursor virtual para uma posição X e Y específica, clicar num botão do rato, ou enviar uma string de keystrokes. Depois de executar a ação, a tool tira outro screenshot para avaliar o novo estado do ecrã, verificando se uma janela abriu ou se apareceu texto, antes de decidir o seu próximo passo. Considera um cenário em que precisas de extrair dados de uma aplicação desktop Windows legacy e inseri-los num web form moderno. O agent olha para o screenshot da app legacy, localiza visualmente o número da fatura e guarda essa informação. Depois, faz output de instruções para mover o rato para a janela do browser, clicar dentro do campo do web form de destino e digitar os dígitos. Navega pela interface exatamente como um operador humano faria, guiado inteiramente pelo contexto visual no ecrã. Dar a um model de IA o controlo físico sobre um desktop exige controlos de segurança rigorosos. Aqui está o insight principal. Nunca fazes deploy disto num servidor de produção ou na workstation principal de um utilizador. O agent tem de operar dentro de uma máquina virtual ou container dedicado e isolado. Concedes a este ambiente o mínimo absoluto de privilégios necessários para concluir a tarefa específica. Como o model consegue navegar em browsers por si próprio, tens de impor controlos de rede rigorosos. Aplicas uma allow list de URLs para que o agent só possa aceder a domínios aprovados, impedindo-o de interagir com websites não seguros ou serviços externos. Também garantes que a máquina virtual não contém dados sensíveis fora do workload imediato. Ao tratar a interface gráfica como apenas mais uma stream de input visual, preenches a lacuna entre o raciocínio inteligente e o software legacy inacessível sem escreveres uma única linha de código de integração. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Autenticação de Utilizadores

3m 16s

Download

Olá, daqui é o Alex do DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 12 de 15. Um agente só é tão poderoso quanto os dados a que consegue aceder. Mas se o teu agente consultar um sistema privado e acidentalmente mostrar o teu calendário pessoal a um funcionário completamente diferente, tens uma falha de segurança enorme. Para evitar isto, tens de configurar corretamente a autenticação de utilizadores. O erro mais comum que os developers cometem aqui é confundir as credenciais fornecidas pelo maker com as credenciais do end-user. Se embutires as tuas próprias API keys ou credenciais de service principal numa action do agente, o bot executa essas actions como se fosses tu. Todas as pessoas que falarem com o agente vão contornar os seus próprios limites de segurança e aceder aos dados usando as tuas permissões. A autenticação de utilizadores força o agente a correr as queries exatamente como a pessoa que está a escrever o prompt, dependendo inteiramente da sua identidade única. No Copilot Studio, escolhes principalmente entre dois estados de autenticação: Authenticate with Microsoft e Authenticate manually. O Authenticate with Microsoft é o caminho simplificado para ferramentas internas. Se o teu agente opera exclusivamente dentro do Microsoft Teams ou do Power Apps, esta configuração usa automaticamente o token do Microsoft Entra ID da pessoa que tem o login feito na aplicação. Não há um prompt de login separado. O contexto do utilizador simplesmente flui para o agente. Mudas para o Authenticate manually quando o teu agente vive num website externo customizado, ou quando precisas de um controlo rigoroso e granular sobre as permissões. Este método depende da configuração de uma ligação OAuth2 a um identity provider, que normalmente é uma App Registration no Microsoft Entra ID. Pensa num cenário concreto. Estás a construir um agente que verifica a agenda pessoal de um funcionário. Configuras o Authenticate manually e ligas isso à tua App Registration do Entra ID. Aqui está o ponto chave. O agente não obtém acesso total a toda a conta Microsoft do utilizador. Em vez disso, defines scopes rigorosos na tua configuração. Configuras o node de autenticação para pedir um scope específico chamado Calendars dot Read. Quando um utilizador pede a sua agenda ao agente, o agente pausa a sua lógica e mostra um sign-in card no chat. O utilizador clica no link, autentica-se através do browser, e vê um ecrã a pedir-lhe para conceder ao agente acesso de leitura ao seu calendário. Assim que consente, o Microsoft Entra ID gera um access token e passa-o de volta ao agente com segurança. Este access token está estritamente ligado a esse utilizador individual e restrito apenas ao scope do calendário. Quando o agente faz o HTTP request real para ir buscar a agenda, inclui este token. A API de backend inspeciona o token, confirma a identidade do utilizador, e devolve com segurança apenas os seus eventos de calendário específicos. Configurar bem a autenticação de utilizadores é o que transforma um chatbot genérico num assistente personalizado, provando aos teus sistemas de backend exatamente quem está a pedir os dados, para que nunca deixes vazar informações privadas entre sessions. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Voz e IVR

4m 03s

Download

Olá, daqui fala o Alex da DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 13 de 15. O futuro do apoio ao cliente não se resume a texto num ecrã. As pessoas ainda ligam para as linhas de suporte e, quando o fazem, esperam uma resposta imediata e inteligente, em vez de uma árvore de menus interminável. Para colmatar essa falha, é preciso ligar a tua IA diretamente às redes telefónicas. É isso que vamos abordar hoje: Voz e IVR. Pegar num agent criado no Copilot Studio e fazê-lo atender o telefone significa configurá-lo para um channel telefónico, geralmente através do Dynamics 365 ou do Azure Communication Services. Isto transforma a tua lógica num sistema de IVR, dependendo de speech recognition nativo para converter o áudio de quem liga em texto, e de motores de text-to-speech para responder. Mas traduzir a lógica de chat para a lógica de voz exige lidar com as realidades físicas de uma chamada telefónica. Imagina um cliente a ligar para uma linha de suporte. O bot atende e começa a ler uma saudação legal obrigatória ou uma lista de opções. A pessoa que liga já sabe que precisa do departamento de faturação. Se isto fosse um chat de texto, simplesmente escreveria a sua pergunta. Num telefone, a pessoa fala por cima do bot. Isto requer uma feature chamada Barge-in. Sem o Barge-in ativado, o sistema ignora o áudio recebido até que o bot termine completamente o seu playback. Com o Barge-in ativo, o speech recognizer ouve em simultâneo. No momento em que deteta o utilizador a falar, interrompe instantaneamente o output de text-to-speech do bot e processa o áudio recebido. Isto replica o fluxo natural de uma conversa humana e evita que quem liga se sinta preso por uma máquina. Depois de interromper o bot, é pedido um número de conta ao utilizador. Poderia dizer os números em voz alta, mas talvez esteja numa sala cheia de gente. Em vez disso, toca nos números no ecrã. Isto leva-nos ao DTMF, ou Dual-Tone Multi-Frequency. As pessoas costumam confundir o handling de DTMF com inputs de texto standard, mas são mecanismos completamente distintos. O DTMF lida com as interações do teclado do telefone globalmente em toda a rede telefónica. Quando quem liga pressiona uma tecla, a rede envia um tom de frequência específico. O Copilot Studio captura estes tons diretamente. Configuras input nodes para ouvir sequências DTMF, extrair os dígitos resultantes e guardá-los como variáveis. Podes impor um número máximo de dígitos, definir timeouts e definir um caráter de terminação, como instruir o utilizador a pressionar a tecla cardinal quando terminar de os marcar. Aqui está o ponto-chave. Apenas capturar o input não é suficiente; a forma como o teu agent responde determina se quem liga desliga a chamada. O text-to-speech default pode soar monótono. Para corrigir isto, usas SSML, ou Speech Synthesis Markup Language. Em vez de enviar plain text para o motor de voz, envolves as tuas respostas em markup tags. O SSML permite-te controlar o pitch, ajustar o speaking rate e impor pronúncias específicas. Se o nome da tua empresa for uma sigla, podes usar SSML para forçar o motor a lê-la letra a letra, em vez de adivinhar como soa como uma palavra. Podes inserir silêncios precisos, adicionando uma pausa de meio segundo após uma instrução complexa para permitir que quem liga processe a informação. Desenvolver para voz exige tratar a linha telefónica como uma interface única, tendo em conta interrupções, tons do teclado e o ritmo do áudio. Os voice agents mais eficazes não forçam os utilizadores a menus de áudio rígidos; combinam um Barge-in seamless e um handling preciso de DTMF para simplesmente saírem do caminho de quem liga. Obrigado por ouvires. Até à próxima!

Agent Analytics

3m 47s

Download

Olá, daqui é o Alex da DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 14 de 15. Finalmente fazes o deploy do teu agente, testas tu mesmo, e tudo parece perfeito. Uma semana depois, a satisfação dos utilizadores está a cair e os processos em background estão a falhar silenciosamente. O problema não é a tua build inicial, é a tua falta de visibilidade sobre o comportamento em produção. A ferramenta para resolver isto é o Agent Analytics. O Agent Analytics oferece uma visão unificada do desempenho do teu agente quando lida com workloads reais. A primeira coisa que vês é a página de Summary. Esta funciona como o centro de comando. Agrega indicadores-chave de performance, como o total de sessões, engagement rate, resolution rate e escalation rate. Em vez de tentares adivinhar se o teu agente está a ajudar os utilizadores, os AI insights do Summary analisam a intenção do utilizador e mostram-te exatamente quais os tópicos que estão a gerar resoluções bem-sucedidas e quais os que fazem com que os utilizadores abandonem a sessão ou peçam por um humano. Aqui está o insight principal. O Copilot Studio faz o tracking de dois tipos de sessões fundamentalmente diferentes, e o dashboard apresenta-as numa vista híbrida. Primeiro, tens as sessões conversacionais. Estas são exatamente aquilo que parecem. Um utilizador abre uma janela de chat e conversa com o agente. O analytics faz o tracking dos turnos de diálogo, do sentimento do utilizador e do triggering de tópicos. Segundo, tens as sessões autónomas. Estas correm inteiramente em background. São triggered por eventos externos, como a criação de um novo registo numa base de dados ou a chegada de um email, e não por um utilizador a escrever uma mensagem. Não há interface de chat. O analytics faz o tracking para ver se o agente concluiu com sucesso a sua lógica em background ou se bateu num erro. Precisas de ambas as vistas para manter um agente saudável. Considera um cenário onde estás a rever este dashboard híbrido. As tuas métricas conversacionais parecem estar bem, mas notas um pico repentino nas failure rates. Filtrar por tipo de sessão revela que os erros estão todos a acontecer nas sessões autónomas. Um processo triggered por um evento, que supostamente deveria atualizar os status das encomendas, está a falhar em background. O dashboard de Summary diz-te que há uma falha, mas não te diz a linha exata de lógica que a causou. É aqui que passas do dashboard para os raw data. O Copilot Studio guarda logs de execução detalhados no Microsoft Dataverse como transcripts. Fazes o download do transcript específico para a sessão autónoma que falhou. Ler o transcript dá-te o trace passo a passo da execução. Podes ver a variável exata que passou um valor inválido, identificar o node que está a falhar, e corrigir a lógica sem teres de recriar o erro às cegas. O dashboard diz-te onde procurar, mas o transcript diz-te o que corrigir. Se quiseres ajudar a manter estes technical breakdowns a chegar, podes apoiar o programa procurando por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Model Context Protocol

3m 54s

Download

Olá, daqui é o Alex da DEV STORIES DOT EU. Microsoft Copilot Studio, episódio 15 de 15. Passas semanas a criar *plugins* personalizados para permitir que o teu *agent* consulte as tuas bases de dados internas e desencadeie ações. Depois, é lançada uma nova plataforma e dás por ti a reescrever exatamente as mesmas integrações do zero. A solução para este ciclo interminável de trabalho redundante é o Model Context Protocol. O Model Context Protocol, ou MCP, é um *standard* aberto que liga modelos de IA a fontes de dados e *tools* externas. Ao adotares um *standard* aberto, preparas efetivamente os teus *agents* para o futuro. Escreves a lógica de integração exatamente uma vez, alojas num servidor MCP, e qualquer cliente de IA compatível pode usá-la instantaneamente. O Copilot Studio atua como um desses clientes. Considera um cenário em que a tua equipa de engenharia depende de 50 *scripts* de diagnóstico internos diferentes e ficheiros de *log* em tempo real. Não queres criar e mapear manualmente 50 ações separadas dentro do Copilot Studio. Em vez disso, configuras o teu *agent* para se ligar diretamente ao teu servidor MCP interno proprietário. Quando o *agent* inicializa, pergunta ao servidor o que pode fazer. O servidor responde com uma lista de capacidades, concedendo imediatamente ao *agent* acesso a todas as 50 *tools* de engenharia e *resources* de ficheiros em tempo real. Um servidor MCP expõe três componentes principais ao teu *agent*. São eles *Resources*, *Tools* e *Prompts*. Os *Resources* são fontes de dados apenas de leitura. Quando o teu *agent* precisa de verificar um ficheiro de configuração em tempo real ou um registo de uma base de dados, o servidor MCP fornece esses dados como um *resource*, carregando-os diretamente no contexto do modelo. As *Tools* são funções executáveis. Se o *agent* decidir que precisa de reiniciar uma máquina virtual ou atualizar um *ticket* de engenharia, ele chama a *tool* MCP apropriada, e o servidor externo executa a ação. Os *Prompts* são *templates* de instruções predefinidos fornecidos pelo servidor. Eles guiam o *agent* exatamente sobre como formatar *queries* ou interpretar os dados específicos desse sistema externo. Aqui está o ponto-chave. As pessoas muitas vezes assumem que, quando ligas um servidor MCP, o Copilot Studio importa e guarda cópias permanentes dessas *tools* na sua própria interface de utilizador. Não é assim que funciona. As *tools* e os *resources* estão alojados de forma completamente externa. O Copilot Studio lê dinamicamente o que o servidor expõe em *runtime*. Se a tua equipa de engenharia adicionar uma quinquagésima primeira *tool* de diagnóstico, ou modificar os parâmetros de um *script* existente, basta atualizarem o servidor MCP externo. O Copilot Studio reflete automaticamente essas alterações. Nunca tens de fazer *login* na interface do Studio para republicar ou atualizar a ação. Como a lógica vive inteiramente no servidor, manténs uma única fonte de verdade para os dados e ações da tua organização. O *agent* permanece leve, funcionando meramente como o motor de raciocínio que decide quando comunicar com o servidor. Ao separares as tuas *tools* da plataforma específica do *agent*, centralizas as tuas integrações e garantes que a tua IA tem sempre as capacidades mais recentes, independentemente da interface de cliente onde faças o *deploy*. Encorajo-te vivamente a leres a documentação oficial, a experimentares ligar um servidor MCP na prática, ou a visitares devstories dot eu para sugerires tópicos que queiras ver abordados numa série futura. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!