Boas-vindas a todos ao podcast M65FM. Hoje vamos além de uma das conversas mais comuns sobre engenharia de prompts do Microsoft 305 Copilot. Por quê? Quando as organizações começam a usar o Copilot seriamente, a pergunta muda rapidamente de como escrevemos prompts melhores. Para como conectamos o Copilot às aplicações, dados, apps, processos de negócio e o conhecimento que realmente operam em nossa empresa. E é aí que a extensibilidade do Copilot se torna interessante, testando. Meu convidado hoje é Evas Harvest, Microsoft MVP, consultor de aplicações de negócio e A, no grupo Word na Suíça. Evas trabalha com Microsoft 306.5, Azure, Dynamics 306.5 e Power Platform, com foco especial na extensão do Microsoft 306 Copilot por meio de agentes e desenvolvimento personalizado. Vamos explorar a extensibilidade do Microsoft 305 Copilot e Copilot Studio. Microsoft Azure AI Foundry, não sei. Eles mudam o nome Microsoft Graph, desenvolvimento personalizado, MSPSE e assim por diante.

MIG. Então Eva, seja bem-vindo ao podcast M65. Olá a todos, obrigado por me receberem. É realmente uma oportunidade para mim estar aqui. Muito obrigado pelo convite. Eu que agradeço. Antes de entrarmos nos aspectos técnicos, você poderia nos contar um pouco sobre sua jornada e como entrou no ecossistema Microsoft? Claro, porque, para ser sincero, eu não comecei minha carreira no mundo Microsoft. Comecei minha carreira no mundo Apple. Eu era engenheiro de software na plataforma Mac e depois migrei para iOS, esse tipo de coisa. E foi há muito tempo, talvez uns 15 ou 20 anos atrás, que me mudei para o mundo Microsoft. Para ser sincero, comecei minha carreira em SharePoint, depois migrei para a Nuvem, Azure e M365.

Eu trabalhava com SharePoint on-premises, comecei assim e depois fui para todos os serviços em Nuvem, Power Platform e mais recentemente tudo relacionado à IA. Para ser sincero, porque isso é uma grande parte do M365 agora, já que temos uma transição para agentes e basicamente essa é, em resumo, minha jornada. Mas eu comecei minha carreira no mundo da engenharia de software, que é hoje talvez uma palavra que muitas pessoas estão esquecendo, porque você tem todas as coisas de IA agora e basicamente esse tipo de atividades ou trabalhos mudaram para IA. Então é bem diferente de 20 anos atrás para agora. Sim, você diz que trabalha com SharePoint e eu vejo também que você trabalha com Graph, Speak, Dynamics, Power Platform. Como esse histórico te preparou para a geração atual de desenvolvimento de IA?

Basicamente, basicamente meu perfil é realmente, realmente transversal, porque na minha carreira eu costumava trabalhar com muitos, muitos produtos. poderiam ser produtos Microsoft e não Microsoft. Então basicamente eu tenho um grande escopo de habilidades, em muitas tecnologias e ferramentas diferentes. Então todos os meus trabalhos me deram uma boa base, porque agora com a IA é um tópico amplo, porque você tem diferentes tipos de abordagens, diferentes tipos de tecnologias para fazer IA agora. Pode ser agente, pode ser mais fluxo de trabalho, esse tipo de coisa. Então basicamente todos os meus empregos anteriores me deram muitas habilidades para estar pronto para essa transição, para IA agora, para ser honesto. Então eu mudei para Low Code, para ferramentas Pro Code. Então sim, todas essas, oh sim, todas essas oportunidades e atividades nos meus trabalhos me deram boas habilidades para tirar vantagem no mundo da IA, para ser honesto.

E agora você é um líder de testes de IA, e o que faz um líder de testes de IA? Essa é uma pergunta muito boa, porque muitas pessoas me fazem essa pergunta. Então meu trabalho é apenas combinar especificações funcionais com a pilha técnica. Então eu assumo a liderança quando a análise de negócios já foi feita. Nós definimos o caso de uso para as coisas de IA, nós definimos cenários, caso de uso, nós definimos, nós fizemos a análise de negócios completa. E meu trabalho é, ok, eu pego essas necessidades e combino essas necessidades com a pilha técnica por trás. E depois eu lhe dero toda a implementação das ferramentas e da solução quando estamos prontos para começar a desenvolver.

Sim, interessante.

Na verdade, muitas empresas compram treinamentos para seus funcionários, especialmente para engenharia de prompt. E por que você diria que isso não é suficiente?

Apenas engenharia de prompt, você quer dizer, hoje em dia? Por que, por que, por que eles, por que é só, sabe, por que para as empresas não é suficiente apenas ensinar as pessoas a engenharia de prompt? Assim, entendo. Ok, sim, sim, basicamente para ser honesto, hoje em dia você tem, como eu disse antes, muitas ferramentas e tecnologias diferentes. Então, e basicamente, em certo ponto a IA pode entender o que fazer e talvez te guiar um pouco. Mas, para mim, o papel de, por exemplo, arquiteto ou designer de software, você precisa ter um humano por trás das cenas porque você precisa entender o cliente. Basicamente, basicamente, a IA às vezes não consegue entender o contexto do cliente. O cliente, você vê a rede completa, mas por trás das cenas, ter apenas um foco em engenharia de prompt pode ser bom em certo ponto. Mas, você precisa ter mais porque precisa ter por trás das cenas algumas pessoas que sejam arquitetos, engenheiros de software e basicamente muitas pessoas que tenham habilidades em tecnologias.

Tecnologias, tecnologias da informação como o SharePoint, como o OneDrive ou o Salesforce, esse tipo de coisa. Você precisa ter especialistas nessas tecnologias porque a IA pode entender muitas coisas. Ela pode te guiar, ela pode gerar ótimos documentos técnicos ou funcionais, mas você precisa ter humanos por trás das cenas que cuidem de, ok, isso está bom? Isso está o atendendo a necessidade do cliente, esse tipo de coisa, sabe, para validar tudo e focar apenas na engenharia de prompt. Para mim, agora, sim, poderia ser uma opção se você não tem tempo para treinar ou para investir em adquirir algumas habilidades. Mas, para mim, você precisa ter boas habilidades nas tecnologias fundamentais onde você quer construir suas soluções para ser honesto.

E você é um especialista em extensibilidade do Copilot. Onde um Copilot padrão, o Microsoft 365 Copilot, para e onde a extensibilidade do Copilot começa? Sim, é uma boa pergunta porque, para ser honesto, dois anos atrás, quando o Copilot foi lançado, talvez a primeira versão, basicamente o chat era, para ser honesto, muito, muito minimalista. Basicamente, você pode, ok, era como um chat GPT, mas a Microsoft evoluiu muito. O Microsoft 365 Copilot, basicamente, agora você tem diferentes tipos de recursos, então a extensibilidade é menor do que antes, porque no passado você desenvolvia alguns plugins, esse tipo de coisa. Mas, hoje em dia, para ser sincero, neste momento, a extensibilidade é quando você quer construir algo e quer personalizar, basicamente, o orquestrador ou quer personalizar um pouco mais, por exemplo, a interface do usuário. Se você quiser integrar seu agente, não apenas no chat do Microsoft Trezenco, mas, por exemplo, no seu site, esse tipo de...

Então, a extensibilidade começa quando você quer, basicamente, personalizar mais os bastidores, você quer personalizar um pouco mais.

Pode ser o orquestrador, se você quiser personalizar o orquestrador, se quiser personalizar a sua interface, se você quiser personalizar diferentes aspectos, onde, basicamente, o chat do Copilot não pode fazer, não pode responder.

E acho que muita gente fala sobre agentes... Um som...

Por que pensamos tanto agora em agentes do Copilot e por que não construímos, sei lá, um grande Copilot para tudo? Sim, é muito interessante, porque, para ser sincero, o Microsoft, como eu disse antes, evoluiu muito, evoluiu muito. E, talvez, se estivéssemos seis meses atrás, ok, um agente era um tópico,

agora, o Microsoft introduziu o Copilot para trabalho e, para ser sincero, hoje em dia, o Copilot para trabalho pode substituir muitos agentes. E, quando pensamos sobre agentes, é apenas para separar as coisas, porque, agora, estamos mais em um modelo multi-agente, onde cada agente tem seu escopo e suas responsabilidades. E não fazemos um grande Copilot, basicamente, por causa do desempenho. Primeiro, porque, quando você tem um grande conjunto de instruções e ferramentas em termos de desempenho, vira uma bagunça.

E a arquitetura, agora, é mais multi-agente, pode ser no Copilot Studio, pode ser em um agente desenvolvido sob medida em termos de código ou desenvolvimento personalizado. Mas, hoje em dia, é melhor ter uma abordagem multi-agente, onde cada agente tem seu escopo e sua responsabilidade apenas em termos de desempenho e para ter uma arquitetura clara de agentes.

Chopembe! E, quando olhamos para isso, ok, eu penso em uma arquitetura básica de agente de IA, então, nós temos, eu diria, algumas palavras-chave. Nossas palavras-chave. Mas, nós temos que pensar sobre raciocínio, ferramentas, conhecimento e instruções. Como isso se encaixa em uma arquitetura de agente IA? A primeira coisa é pensar, uma das primeiras perguntas que você precisa responder é que é objetivo.

O primeiro objetivo deste agente, basicamente, depois da arquitetura de agente, isso realmente depende de se você está em uma abordagem low-code ou se está em uma abordagem de desenvolvimento personalizado, porque a abordagem é totalmente diferente, já que em uma abordagem de desenvolvimento personalizado você gerencia tudo. Então, você gerencia a segurança, gerencia a hospedagem, gerencia muitas coisas diferentes. Na abordagem low-code é muito diferente porque você pensa, ok, você dá a instrução, você seleciona algumas ferramentas. Então, basicamente, a arquitetura em uma abordagem low-code não é tão simples quanto eu disse agora, mas pode ser muito rápida porque você pode definir, ok, você tem a instrução, pode selecionar suas ferramentas, pode selecionar um outro agente diferente se quiser se conectar. Mas é muito simples, quando você está lidando com desenvolvimento personalizado ou quando desenvolve seu próprio agente, poderia ser, por exemplo, semantic kernel, agent framework, esse tipo de coisa.

A arquitetura pode ser muito mais complexa porque você precisa lidar com conceitos realmente avançados, como eu disse, segurança. Em termos de autenticação, se você tem, por exemplo, múltiplas ferramentas e quer integrar algum NCP, se quer se conectar a ferramentas internas protegidas por proxys, reversos, esse tipo de coisa. Então, basicamente, você precisa refletir, mas em termos de arquitetura, quando está lidando com agentes personalizados, por exemplo, no Copilot Studio, em termos de arquitetura, é muito rápido definir arquitetura em uma abordagem de desenvolvimento. Personalizado, você tem que lidar com conceitos avançados e, para muitas pessoas, pode ser difícil porque são aspectos realmente fundamentais. E no meu trabalho, para ser honesto, eu lido com muitas necessidades diferentes, sabe? Pode ser desenvolvimento personalizado, pode ser o Copilot Studio, ou um agente simples no Agent Builder com uma necessidade bem básica.

Então, basicamente, definir uma arquitetura depende muito de qual abordagem você quer adotar. Basicamente, você tem uma arquitetura geral que pode criar, mas depois depende realmente da abordagem que você quer, low-code ou full-code, entende?

Mas podemos... Pode, pode... Você pode descrever a anatomia de um agente diacorporativo típico... Ah, sim, eu posso... Basicamente, se você quer falar da forma mais simples possível, quando você tem uma necessidade, por exemplo, pode ser um agente de suporte de TI, basicamente, pode ser que você tenha um conjunto, basicamente, mas depois, hoje em dia, como eu disse, você tem essa abordagem multi-agente e, basicamente, eu coloco o primeiro agente como a frente, como uma interface. Então, este é um agente de frente e esse agente de frente vai rotear todas as solicitações, por exemplo, entre diferentes agentes. Então, por exemplo, se o usuário estiver perguntando, sei lá, uma dúvida sobre Salesforce, ele roteará toda a solicitação para o agente de suporte de TI, do Salesforce, entende? Então, basicamente, para alguns clientes nós criamos esse tipo de arquitetura, porque cada agente cuida do seu escopo.

Pode ser para produtos como o Salesforce, pode ser para o M3 e M5, esse tipo de coisa. E por trás das cenas, cada agente tem um conjunto de instruções e um conjunto de ferramentas. E, hoje em dia, é melhor usar servidores MCP, porque o servidor MCP agora é um plug universal para integrar vários serviços com o IA. Então, eu tenho um conjunto de servidores MCP e também algumas fontes de conhecimento internas, pode ser como o Gira, pode ser base de conhecimento do ServiceNow, esse tipo de coisa. Então, você tem um conjunto de instruções por agente e essas instruções definem o escopo do agente e qual é o papel de cada um. E, depois, você tem um conjunto de servidores MCP e, talvez, fontes de conhecimento que possam ser arquivos PDF. Então, pode ser vários, vários tipos de fontes de dados.

E, depois, desculpe, quando um usuário solicita, por exemplo, ao agente principal, ele definirá, ok, preciso delegar esta tarefa ao agente respectivo.

Vamos analisar um pouco as possibilidades onde o Copilot Studio se encaixa na arquitetura geral. O Copilot Studio, para ser sincero, é uma ferramenta low-code da Microsoft. Então, primeiro, em termos de arquitetura, o Copilot Studio é realmente projetado para criadores, basicamente para pessoas que não são desenvolvedores a princípio. E, em termos de arquitetura, basicamente, se pegarmos o exemplo que usei antes, o suporte de TI, o Copilot Studio, se encaixa bem. Porque, arquiteturalmente, ele dá conta do recado, pois você pode definir servidores, integrar facilmente fontes de conhecimento externas ou internas, se desejar. Depois, como eu disse antes, se você tiver um caso de uso onde deseja personalizar um pouco o orquestrador, nos bastidores do Copilot Studio, você não consegue personalizar o orquestrador. Você apenas ativa o orquestrador de IA, e é isso, e é isso. Você não pode, por exemplo, personalizar a prioridade das tarefas que deseja realizar, porque o Copilot Studio definirá o plano nos bastidores e, em seguida, o executará.

Mas, se você quiser ter um pouco mais de personalização, nesse caso, precisará usar desenvolvimento customizado, como, por exemplo, Semantic Kernel Langchain, ou um framework mais recente lançado pela Microsoft, onde você pode facilmente personalizar a orquestração, definir fluxos de trabalho e personalizar o que quiser.

Essa é a arquitetura do Copilot Studio, realmente definida para construtores e criadores, porque é muito simples colocar um agente para funcionar.

O único problema com o Copilot Studio, e você precisa se atentar a isso, é que, ao escolher seu caminho e definir sua arquitetura, você precisa considerar o licenciamento, pois ele é uma parte importante de toda solução agora.

E, hoje em dia, o Copilot Studio evoluiu um pouco para o modelo de pagamento, conforme o uso, e você precisa ter cuidado com a estimativa de custos, porque, dependendo do que deseja alcançar, às vezes é melhor fazer um desenvolvimento personalizado, já que depois você hospeda onde quiser, controla todos os custos, e consegue estimar com mais facilidade. Porque, com a abordagem de créditos do Copilot, às vezes é difícil prever quanto vai custar por um mês, dois meses, e esse tipo de coisa. E quais são as limitações do Copilot Studio?

Studio, quando devo escolher, então, penso, Microsoft Foundry, Azure Foundry, não sei qual é o nome real, e quando tenho que dizer, ok, devo fazer um desenvolvimento totalmente personalizado?

A primeira pergunta a responder é, ok, preciso personalizar a orquestração? Essa é a primeira pergunta para mim, porque ela lhe dirá, ok, se você não quer personalizar a orquestração, se aprofundar em como toda a orquestração é feita, ou como o plano é gerado, você pode usar uma abordagem low-code com o Copilot Studio. Por exemplo, um construtor, além disso, às vezes, quando você tem um caso de uso simples, pode usar esse tipo de ferramenta. Mas se você quiser personalizar a orquestração, ok, precisa partir para um desenvolvimento específico, e nesse caso, precisa usar o Foundry para o modelo, ou se você tiver sua própria plataforma, porque a vantagem do desenvolvimento personalizado,

você pode integrar modelos que não estão hospedados no Foundry da Microsoft, se quiser, pode usar modelos do Foundry, mas também, se você tiver uma AWS ou Google, plataforma Google, desculpe, e tiver o Gemini, por exemplo, ou tiver implantado um modelo externamente, você tem a capacidade de integrar esses modelos diretamente no seu agente quando usa uma abordagem personalizada.

Essa também é uma vantagem. E depois você pode personalizar a orquestração, como o plano é gerado, todas as coisas que entrarão no agente do Foundry. O problema do Foundry hoje em dia é que, no início, o Foundry era apenas uma plataforma de hospedagem de modelos. Quando você olha alguns anos atrás, era, sim, apenas um catálogo simples de modelos, e você o implantava. E você o implantava. Hoje em dia, a Microsoft evoluiu este produto para permitir que você crie agentes com uma interface de usuário, tipo Copilot Studio, basicamente, sem nenhum código. Você pode gerenciar governança, você pode gerenciar muitas coisas. Ele se tornou uma plataforma realmente agentica, como Copilot Studio para low-code e coisas do tipo. E hoje em dia, é muito difícil posicionar o Foundry no ecossistema, porque o Foundry está evoluindo rápido.

Basicamente, a Microsoft introduziu alguns recursos que são... Eu não sei, não diria diferentes. Mas há semelhanças com o Copilot Studio em termos de integração com o MCP e coisas assim. Mas, no final, a principal limitação do Copilot Studio são os modelos. Então, você tem a capacidade de integrar código ou visualizar esse tipo de coisa. Mas, se você quiser integrar, por exemplo, o seu próprio modelo, porque você tem uma versão específica, você não consegue. E, basicamente, precisa usar um desenvolvimento customizado para integrar a sua própria plataforma de LLM, se tiver. Tem o cliente que possui a sua própria plataforma AWS. Nesse caso, você pode integrar esse modelo com o preço gerenciado externamente. E eu acho que quando construímos um agente, um tópico também, é... Tudo é guerra.

Schopenhauer.

A maioria das pessoas fala sobre o MCP, o Model Context Protocol. Por quê? Ele se tornou um dos maiores tópicos no desenvolvimento de agentes e, para alguém que ainda não trabalhou com isso, o que é o Model Context Protocol? Protocol.

Sim, é uma palavra grande. Basicamente, muitas pessoas estão falando sobre isso porque resolve um problema importante. É sobre como unificar a integração de ferramentas, habilidades. Talvez ferramentas externas aí há. E isso resolve o problema, porque, antigamente, sem o MCP, era uma bagunça, pois muitos serviços conversavam de formas diferentes. Você tem diferentes protocolos tecnológicos, diferentes abordagens de arquitetura e, basicamente, o MCP unifica a forma como você integra serviços ao seu agente de IA ou solução de IA, sendo mais genérico. Mas o MCP, agora, é realmente a maneira de integrar ferramentas externas ou internas, podendo ser ambas. mas o MCP, agora, é uma grande parte da arquitetura de IA, porque você tem essa unidade em termos de tecnologia e, hoje em dia, é um ponto muito importante porque, no passado, era integração via API e, agora, é MCP.

Esta é... Esta não é a evolução, mas, antigamente, você integrava seu agente com a API. Você precisava gerenciar, certo? Como autentical, gerenciar isso, chamar a ferramenta. Agora, a IA pode... Ok, tem essa ferramenta disponível. Posso selecionar o que preciso para alcançar o objetivo.

E o que realmente mudou do MCP para a conexão API?

Basicamente, no passado, em termos de... Basicamente, APIs não são inteligentes, se é que posso dizer isso. APIs são apenas... Ok, você chama uma ferramenta e ela te dá dados. A diferença com o MCP é... O MCP é mais inteligente em termos de arquitetura porque, nos bastidores, você não tem apenas ferramentas que te dão dados ou informações, mas você também tem habilidades em instruções e diferentes tipos de coisas que tornam o MCP realmente inteligente. e, basicamente, o MCP pode dizer a IA Ok, você quer alcançar isso? Eu posso te dar as ferramentas exatas que correspondem à sua solicitação. É... E você pode chamar não apenas uma ferramenta, mas precisa chamar essas ferramentas para alcançar o que deseja. Este é o papel do MCP. Ele diz a IA. Ok, eu tenho essas ferramentas. E, depois, hum... Você pode chamar esta ou aquela ou múltiplas ferramentas para alcançar seus objetivos. Ele te dá...

Ele dá a IA ao contexto real de... Hum... De tudo. E a API é apenas ok. Você tem ferramentas, tem descrição e é basicamente isso.

Então... Então, é o protocolo de contexto de modelo. Eu acho semelhante a metadados ou como isso funciona?

Hum... O MCP nos bastidores. Hum... É apenas... Hum... É um protocolo. B, basicamente, é um protocolo tecnológico. E nos bastidores você tem... Você tem metadados, você tem descrição, hum... Você tem habilidades de IA que descrevem, mas... Hum... É realmente focado em IA. Basicamente, você tem habilidades, você tem instruções e, basicamente, a IA pode entender melhor. Ok. Essas ferramentas hum... Fazem isso. Esta ferramenta faz aquilo. Ok. Posso chamar essas habilidades, posso solicitar essa informação ao servidor MCP para alcançar a minha tarefa.

Mas você tem, sim, você tem uma parte de metadados porque você precisa definir, ok, o nome da ferramenta, o que ela está fazendo nos bastidores.

Olha, podemos dizer que o futuro é o MCP. Então, temos que começar a pensar, não sei, empresas que têm sem APIs hash dentro da organização, elas deveriam começar a construir servidores MCP ao redor delas? Sim, sim, basicamente, o servidor MCP, nós trabalhamos com APIs nos bastidores. Isso não é uma substituição, basicamente. Se eu resumir isso, porque o servidor MCP é apenas ok,

ele fornece o contexto e, nos bastidores, o MCP pode chamar APIs nos bastidores, mas o servidor MCP é um front-end, a ferramenta de frente que você precisa chamar, porque nos bastidores você vai despachar a sua solicitação baseada em ok. Nos bastidores pode ser uma API, pode ser um banco de dados, podem ser várias ferramentas, mas você precisa, se você quer ter seu próprio servidor MCP, por exemplo, se você tem internamente na sua empresa, você tem o API e tem diferentes tipos de serviços, pode ser, não sei, serviço financeiro, pode ser serviço de RH, se você quer construir seu próprio MCP, você precisa lidar nos bastidores com todas essas APIs e o servidor MCP precisará por todas essas APIs, quais são os os serviços, quais são as ferramentas disponíveis, quais são as habilidades, esse tipo de coisa.

Depois você precisa lidar com a autenticação nos bastidores, porque as APIs não funcionam da mesma forma, já que você pode ter você pode ter autenticação por chave, por entrada, esse tipo de coisa, então você precisa lidar com isso. Mas o MCP vai expor as ferramentas disponíveis e nos bastidores todas as ferramentas podem chamar múltiplas APIs. Uma API pode ser, você tem diferentes tipos de arquitetura nos bastidores.

E? Hum... Como o MCP escolhe a ferramenta certa quando eu tenho, não sei, 100, 500 agentes de IA?

Será baseado em primeiras coisas. basicamente, quando você tem uma solicitação em um agente, você vai descobrir todas as ferramentas disponíveis. Servidor MCP. Você vai verificar, ok, eu tenho todas essas ferramentas disponíveis e basicamente o orquestrador do agente entenderá, ok, eu tenho isso, tenho um LLM disponível, depois você criará o plano. Se eu resumir um pouco, você criará um plano com algumas ações a serem feitas e depois, nessa ação, na ação que deseja executar, você pode chamar uma, duas, três ou mais ferramentas para realizar a tarefa que o usuário solicitou. Portanto, basicamente, o orquestrador do agente entenderá as ferramentas MCP e selecionará a melhor para a solicitação. Entende? E esse é realmente o papel do orquestrador de selecionar ferramentas e coisas do tipo com a ajuda do LLM, claro, porque o LLM é parte do cérebro e o orquestrador irá, ok, se comunicar com o LLM e também com as ferramentas para fazer a melhor escolha e o melhor plano para concluir a tarefa.

Sim, eu acho que por um tempo muitas empresas começaram com o PowerShell e agora elas usam a IP do Microsoft Graph.

O Graph e o MCP chegaram ou como é que, sim, eu acho que na verdade a API do Graph para ser sincero não existe um MCP para o Graph.

Se você pensar bem, sabe, você tem agora no mundo do Microsoft da MC5, a Microsoft introduziu muitos servidores MCP e esses servidores MCP são baseados nos bastidores no Microsoft Graph. Então, por exemplo, se você quiser usar o servidor MCP do Teams nos bastidores, você tem a API do Graph sendo chamada quando você usa o servidor MCP. Portanto, a API do Graph no mundo do Microsoft 3.300 é central porque nos bastidores o MCP se comunicará com o Graph para fazer a solicitação funcionar bem. mas sim, hoje em dia o Graph é central também no Copilot em geral porque o índice semântico do Copilot é baseado em dados brutos, mas na verdade você consome o Graph por meio de servidores MCP. Hoje em dia é assim.

Microsoft 3D65 contém um valor incrível com textos organizacionais, documentos, reuniões, e-mails, pessoas, equipes, conversas e eu diria conteúdo compartilhado.

Como expomos esse contexto sem é sim criar um pesadelo de segurança?

Dizem termos de governança e coisas desse tipo.

Sim, é sempre um problema porque muitas pessoas estão criando agentes sem uma governança adequada por trás. Então eu quero criar um agente, ok, vamos lá, nós construímos e implantamos e depois, ah, mas ok, esse agente lidará com muitos dados, como gerenciar isso? A primeira pergunta é, ok, como coloco em prática a governança do agente? Antes poderia ser como você disse, uma bagunça porque muitas pessoas querem, ok, quero construir agente, ou quero construir algo, quero construir uma solução de IA, mas por trás da cena, se você está em um contexto de Microsoft 365, por exemplo, uma das primeiras coisas a fazer é, ok, entender seus dados, porque sem entender seus dados você está perdido, você precisa entender seus dados, porque é importante entender, ok, estou lidando com dados confidenciais ou não, estou lidando com dados altamente confidenciais, você precisa entender seus dados, pois, se você estiver no Microsoft 365, precisa implementar, por exemplo, recursos de DLP, rotulagem de sensibilidade, desse tipo de coisa, porque sem isso pode ser um problema.

E depois, você também precisa limpar um pouco seus dados, porque IA, com dados ruins, fará com que seu agente não funcione como você quer, pois se você tiver uma bagunça no seu SharePoint, Teams, canal de equipe, esse tipo de coisa, se for uma bagunça, basicamente, será difícil funcionar corretamente em uma abordagem de agentes. Mas sim, você precisa entender seus dados, você precisa implementar alguma segurança básica como autenticação, como eu disse, recursos do Purview, e o Purview se tornou uma solução central para implementar toda essa parte de segurança e governança. E depois, quando você tiver limpado seus dados, quando você tiver colocado em prática alguma segurança básica, você também precisa entender o licenciamento, porque antes de começar a criar agentes, você precisa entender ok, quais são os desenvolvedores, eles estão treinados para isso. Nós temos o licenciamento correto para começar a desenvolver, precisamos de assinaturas, esse tipo de coisa depois.

Um dos grandes problemas é o ferramental como eu integro adequadamente todas as ferramentas no meu desenvolvimento, no meu agente. Preciso restringir alguma coisa para ser sincero, é uma grande questão. Você tem diferentes atividades a considerar, mas para mim, o mais importante é entender seus dados e se uma empresa não entende os dados. será um problema logo no início, para ser sincero.

E quando nós perguntamos isso,

o tópico de segurança,

eu acho que existem dois tipos de pessoas, uma diz, ok, eles precisam de permissões de usuário, e a outra diz que eles precisam de permissões de aplicação, como a gente deve geralmente operar.

Geralmente, e minha melhor recomendação é basicamente quando você precisa lidar com soluções de agentes, sempre faça desculpe, com permissões de usuário, permissões delegadas, porque em termos de segurança. Para ser sincero, é melhor, pois o usuário lidará apenas com os dados e ferramentas aos quais ele tem acesso. esse é o princípio principal. Depois, se você precisar de permissão de aplicação para um contexto específico, não sei, uma API específica, você pode, mas não use permissão de aplicação diretamente, faça isso em um contexto de um wrapper.

Então, você não sei, poderia ser um servidor MCP, por exemplo, e você integra esse MCP com permissão de aplicação nos bastidores. Então, o MCP chamará, por exemplo, não sei, sua API nos bastidores com permissão de aplicação e depois ele te dá a informação ou o dado que você precisa, mas o usuário não lida diretamente com a permissão de aplicação. Nós chamamos o servidor MCP, por exemplo, com permissão de usuário, o servidor MCP chamará nos bastidores aplicações ou serviços com permissão de aplicação dedicada. Você consegue ver a diferença?

Ok. O interessante, eu acho que quando pensamos em arquitetura, nós também precisamos olhar um pouco mais a fundo. Eu acho que existem três grandes tópicos em arquitetura. Temos a geração aumentada por recuperação, temos o tópico de conhecimento e temos o que eu chamo de busca empresarial, de porta dos fundos.

Por onde vamos começar com o RAG? Onde o RAG se encaixa na arquitetura?

Para ser sincero, o RAG é, na verdade, o mais, para ser sincero, em termos de desempenho, porque a IA precisa entender diferentes tipos de dados e, basicamente, o RAG está aqui para responder a uma pergunta. Porque, no passado, quando você não tinha RAG, basicamente, você precisava lidar com abordagens diferentes. Não era exatamente antigo, mas era complicado. Mas, o RAG é central, porque ele entenderá diferentes tipos de dados se você recuperará basicamente a informação de que a IA precisa documentos, pode ser múltiplos tipos de dados.

Então, sim, o RAG é central, hoje em dia, na arquitetura de IA.

Mas, é verdade que, para muitos usuários, quando você fala sobre RAG, nos bastidores, eles não sabem o que é, porque a Microsoft, hoje em dia, ou muitas empresas de software diferentes, não falam sobre isso. Por quê? Nos bastidores, você tem o RAG. Mas, por exemplo, no Copilot Studio, o usuário não entende que por trás das cenas é RAG. Entende?

E hoje em dia, quando você quer se aprofundar, ok, você tem esse tipo de conceito, mas para muitos usuários, o RAG é algo que eles desconhecem totalmente, porque eles apenas usam a ferramenta e nos bastidores você tem esses conceitos. Então, temos o próximo tópico, que é o conhecimento. Como nós obtemos isso? De onde os sistemas de A tiram seu conhecimento? É uma coleta manual ou como isso funciona? Na verdade, você tem, para ser sincero, o conhecimento pode estar hospedado em muitos sistemas diferentes.

Pode ser um arquivo de texto simples, um arquivo markdown, uma base de conhecimento, pode ser qualquer coisa. mas, na verdade, se você tiver um servidor MCP, você pode acessar esse conhecimento ou se você tiver, por exemplo, conectores para o SharePoint, conectores para muitos serviços hoje em dia, então acessar o conhecimento está mais fácil do que antes. Vamos ser sinceros, porque antigamente você precisava criar seu próprio plugin, fazer tudo manualmente e hoje em dia você tem conectores diretos para qualquer sistema, pode integrar seu conhecimento sem lidar com grandes equipes de desenvolvimento. eu acho que muitas vezes nós temos, não sei, eu coleto para o meu, eu digo para o meu, não sei, algum pessoal,

e como a IA entende o que são documentos que não estão prontos ou desatualizados ou, não sei, duplicados,

como o sistema de IA entende isso? O que devemos usar e o que? basicamente você está usando RAG, porque por trás das câmeras você precisa entender, ok, quais são os seus dados. Mas, para ser sincero, se eu resumir um pouco, você começa pelo prompt, ok, o usuário quer, ok, você quer, por exemplo, pesquisar em, não sei, uma base de conhecimento e, por exemplo, no OneDrive. por trás das câmeras quando o orquestrador com a ajuda de um LLM entende o prompt e a intenção do usuário. Nos bastidores você tem o índice, basicamente, porque, por exemplo, no Copilot você tem o índice semântico e esse índice semântico lhe dá basicamente, ok, eu tenho todo esse conhecimento e você pode ir com uma consulta ao índice semântico a IA pode consultar diretamente o índice semântico para realizar RAG, por exemplo, e você pode diretamente, ok, selecionar os documentos certos com base nas necessidades. Mas no Copilot você tem esse índice semântico e a IA pode consultar diretamente esse índice com linguagem natural por trás das câmeras.

Então, eu vou perguntar, ok, eu quero entender o, não sei, como configurar a VPN da minha empresa e por trás das câmeras ele realizará o RAG no índice semântico e basicamente recuperará o documento que contém, por exemplo, toda a configuração da VPN da empresa. Por exemplo, no chat do Microsoft 365 Copilot, o por trás das câmeras é a Graph API, porque como eu disse antes, você tem o índice semântico construído sobre a Graph API. É um recurso do Graph por trás das câmeras, mas quando você tem um desenvolvimento personalizado, você tem, por exemplo, o Azure AI Search por trás das câmeras, era um serviço do Azure com um nome diferente, mas agora você pode ter seu próprio sistema de RAG se quiser. E basicamente, quando você tem um agente personalizado, você pode perguntar diretamente para essa instância do Foundry é que eu usar, quero obter a configuração da minha empresa de VPN e a IA pode recuperar o que você precisa em termos de documento.

Podem ser PDFs, Word, Excel, esse tipo de coisa.

É assim que a busca funciona. Certo?

Nos bastidores, você quer dizer? Ah, nos bastidores você tem a busca, mas, basicamente, hoje em dia, nos bastidores do chat do Copilot, você tem três capacidades. Você tem a busca padrão, que é basicamente uma busca onde você coloca algumas palavras-chave. E ele pesquisa em seus documentos e coisas do tipo. Essa é uma busca simples. Todos nós conhecemos a busca por palavra-chave, como o Google. Depois, você tem duas capacidades diferentes. você tem primeiro o RAG nos bastidores. Você tem a capacidade de RAG no Graph e você também tem a busca pelo índice semântico do Copilot, que é um pouco diferente, porque o RAG é realmente mais avançado do que a busca pelo índice semântico do Copilot. mas você tem essas três capacidades nos bastidores para que a IA possa acioná-las e recuperar dados do OneDrive, Teams e M3S, QENS, em geral.

O índice semântico do Copilot também inclui os conectores do Copilot. Então, por exemplo, se você conectou o Salesforce com o conector do Copilot, ele também pode pesquisar em todos os seus dados. no Salesforce, no ServiceNow e em várias outras ferramentas. E como tudo está integrado através do conector do Copilot no índice semântico do Graph, você pode consultar diretamente seus sistemas externos.

E eu acho que quando criamos agentes, temos a parte de governança e uma das partes para mim é o gerenciamento do ciclo de vida do agente. Como isso funciona na prática? Como é na prática? Para ser sincero, no ecossistema da Microsoft é bem simples. Se é que posso dizer assim, assim. Porque quando você trabalha com low-code, por exemplo, o Copilot Studio, você está lidando com a Power Platform, conceito, e nada mudou. Então, você tem soluções, tem LM implementado e tem pipelines. Então, ao lidar com o Copilot Studio, para ser sincero, é como antes, porque você tem tudo o que investiu em termos de governança da Power Platform, ciclo de vida e ALM. E ALM é exatamente a mesma coisa. Isso é bom, porque muitas pessoas me perguntam, ah, Copilot Studio, como eu gerencio? É diferente? Não, é realmente simples como o gerenciamento de ciclo de vida de aplicativos para Power Apps ou Power Automate. Então, neste caso, é o gerenciamento de ciclo de vida de agentes, mas nos bastidores.

É o mesmo conceito da plataforma principal. E quando você lida, por exemplo, com o desenvolvimento customizado, basicamente, é como quando você constrói aplicações do Ontenet, esse tipo de coisa, porque você gerencia tudo como código. Portanto, você tem frameworks, aspectos de segurança, esse tipo de coisa, esse tipo de coisa. Então, para ser honesto, em termos de gerenciamento de ciclo de vida de agentes e aplicações, é realmente o mesmo conceito de antes. E esse é um bom ponto para mim, porque você não precisa investir muito em termos de processos de ciclo de vida e coisas do tipo. Mas há algumas mudanças. E uma das grandes mudanças é ok, você precisa se preocupar com LLM, esse tipo de coisa, implantação, etc. Mas nos bastidores parece a abordagem de DevOps do passado, com pipelines e coisas do tipo. Então, na minha opinião, nada mudou que nós gerenciamos agentes,

pode ser desenvolvimento customizado, copilot, você usa a mesma abordagem de antes para ser honesto hoje em dia.

Isso significa que quando uma empresa não usava IA antes, mas tem a configuração perfeita para Purview, Defender e todas as outras Ferramender e todas as outras ferramentas, algo a mudar. ou isso significa que eles estão prontos para IA?

Essa é uma grande questão, porque prontidão para IA, para a Microsoft está tudo bem. Se você ajustar permissões e gerenciar essas coisas, ok, mas prontidão para IA. Para mim, não é apenas uma abordagem técnica, porque tecnicamente nós sabemos o que fazer. Ok, precisamos gerenciar permissões em vários serviços, sabe? para mim, a prontidão também deve incluir os dados, entender os dados, entende? Porque quando você não entende seus dados, como eu disse antes, você não pode gerenciar a parte técnica, porque quando você não sabe o que é confidencial ou não, por exemplo, é difícil implementar alguma segurança, algumas medidas de segurança. mas se nós seguirmos a Microsoft, a prontidão para IA está tudo bem, você precisa gerenciar permissões, quer colocar rótulos de sensibilidade, você precisa fazer governança, esse tipo de coisa, esse tipo de coisa. Mas você também tem um aspecto mais de alto nível e para mim a prontidão para IA não é apenas técnica, você também tem um aspecto funcional ou de alto nível a considerar, para ser sincero, hoje em dia.

Sim, isso é muito interessante. Eu acho que muitas empresas começaram com a IA, mas agora com os agentes, muitas empresas dizem, ela apagou todos os meus e-mails ou está fazendo algo maligno, algo maligno.

O que você acha que as empresas dirão, elas têm medo da IA? é uma boa pergunta porque eu moro na Suíça e basicamente temos muitos bancos privados e temos muitos, para ser sincero, clientes realmente sensíveis e basicamente a parte mais crítica é, ok, onde os dados são processados para basicamente e é também, ok, a IA está pesquisando nos meus e-mails, esse tipo de coisa, então, nos bastidores eles sempre perguntam isso, mas sabe, a parte mais crítica para eles é, ok, eu preciso entender, ok, onde os dados são processados e também, ok, eu sou o dono da IA, então, eu dou a instrução para a IA e a IA nos bastidores fará o trabalho e eles têm medo por exemplo do aspecto autônomo porque hoje em dia ok, você pode ok, fazer isso e nos bastidores a IA buscará algo, fará uma consulta algo nos bastidores e eles têm medo de ok, quando eu peço para a IA fazer algo, o que ela executa nos bastidores e sim, há muitas perguntas como essa, ok, como eu assumo o controle de todo o processo por trás da coisa, seja um agente de IA ou de um serviço de IA, sim, existem algumas perguntas como essa, mas é realmente uma questão de adoção também de treinamento para implementar algum treinamento sobre, ok, como entender a IA, como entender o que é feito exatamente nos bastidores e a transparência também é um ponto importante porque a transparência precisa ser implementada em todas as soluções de IA porque a transparência é para mim um grande tópico já que você precisa implementar tudo porque sua solução de IA precisa ser transparente você precisa entender o que é feito nos bastidores quais dados são consultados você precisa rastrear precisa registrar tudo então tudo precisa ser transparente quando você tem uma solução hoje em dia porque você precisa entender exatamente o que é feito por trás quais dados são processados e qual é o raciocínio por trás de tudo como você gerou esse plano com base em quais fatos e esse tipo de coisa incrível vejo que estamos ficando um pouco sem tempo desculpa sabe isso foi realmente incrível mas eu tenho em todo o podcast uma rodada de perguntas rápidas então eu digo uma frase curta e você dá uma resposta curta então você está pronto copilot studio ou código personalizado copilot studio microsoft foundry ou copilot studio copilot studio typescript ou cshark github ou azure devops github rag ou ajuste fino tudo bem qual é a api do microsoft 300 i5 mais subestimada api de rag uma tecnologia que todo desenvolvedor microsoft deve aprender em 2026 github copilot quando satia nadela chegar até você e disser que você tem todo o dinheiro e recursos que quiser para tornar nossa plataforma de iá melhor você pode desenvolver um recurso qual seria toda a parte de governança que precisamos e quem devo convidar para o próximo podcast e que pergunta devo fazer boa pergunta tenho muitos amigos mas sim talvez você possa perguntar para a minha copalestrante em muitas conferências você pode perguntar por exemplo para a Chloe Moro ela era consultora funcional antes de lidar com o lado técnico agora e ela tem uma história muito boa sobre coisas funcionais e menos técnicas no mundo dynamics então talvez você possa convidá-la e perguntar ok me diga hoje em dia como lidar entre o trabalho funcional e o técnico porque você tem alguns grandes desafios aí e minha pergunta de encerramento é o que as pessoas devem quando puderem levar um aprendizado desta sessão o que devem levar desta sessão basicamente a IA está evoluindo rápido e se você quiser estar atualizado hoje em dia você precisa acompanhar tudo porque hoje em dia a IA está realmente presente em toda a pilha da Microsoft para ser sincero e hoje em dia uma das coisas que você você precisa entender é que evolução é rápida você precisa estar atualizado o realmente o o tempo todo porque você vai perder algo em algum momento se você se você não ou se você não aprender se você não entender evolução nesse sentido sim então sim obrigado por por se juntar a mim acho que a lição é importante desta conversa é que a extensibilidade do Microsoft 305 e Copilot não se resume simplesmente a escrever prompts cada vez mais sofisticados acho que estamos caminhando para uma arquitetura onde Copilot e a gente podem conectar o conhecimento da organização o Microsoft Graph EPIs de aplicativos de negócios e assim por diante sim acho que o Copilot Studio Microsoft Foundry o desenvolvimento personalizado e tecnologias como o MCP dão aos desenvolvedores uma caixa de ferramentas incrível e poderosa e sim mas quanto mais sim capazes os agentes se tornam mais importantes os fundamentos também se tornam identidade permissão segurança governança testes observabilidade gerenciamento do ciclo de vida de aplicativos e assim por diante então sim acho que você deu uma visão geral realmente muito boa de todos esses tópicos tão obrigado por se juntar a mim e pros ouvintes todas as informações sobre o você encontra nas notas do episódio na página do podcast MTZ5FM e o sim onde você pode se conectar ver o trabalho de Jesse e sim obrigado por estar aqui obrigado por me receber foi um tempo muito bom com você tchau