Como criar e lançar um agente de IA no app GitHub Copilot

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: How to build and ship an AI agent in the GitHub Copilot app · Canal: GitHub · 08:52 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Engenharia de software com IA, Ferramentas de desenvolvimento com IA

Resumo

No app GitHub Copilot, o apresentador cria um agente concierge para o site de financiamento coletivo Tailspin Toys, usando dados de um catálogo limitado a 21 jogos. Com o Microsoft Foundry Skill e o Foundry Canvas, ele provisiona recursos, escolhe e testa um modelo, e constrói um agente que deve responder apenas com informações presentes no catálogo. Depois de inspecionar o agente localmente e implantá-lo no Microsoft Foundry, cria uma Azure Function como proxy seguro e conecta um widget de chat ao site. O fluxo inteiro é conduzido por prompts, com o Copilot executando o trabalho e o apresentador tomando as decisões.

Pontos-chave

O catálogo catalog.json contém 21 jogos e define o limite de informações que o agente pode afirmar.
Como o catálogo tem cerca de 11 KB, ele pode ser incluído diretamente no prompt, sem um índice de busca.
O Copilot recomenda modelos com base nos critérios do issue: grounding, seguimento de instruções e uso de ferramentas.
O apresentador escolhe GPT 5.4 Mini, após comparar custo e adequação aos requisitos de grounding.
O Foundry Canvas permite inspecionar recursos do Microsoft Foundry e testar o agente.
O agente é testado localmente quanto a grounding, alucinações e precisão antes do deploy.
Uma Azure Function atua como proxy entre o site pré-renderizado e o agente, sem expor credenciais do Foundry ao navegador.
O agente responde com informações do catálogo mesmo quando os usuários não sabem exatamente o que procuram.

Capítulos

Início	Capítulo	Resumo
00:00	Do catálogo à necessidade de um agente	O vídeo apresenta o cenário da Tailspin Toys e estabelece o catálogo como limite de confiança para as respostas do agente.
01:33	Configuração do Foundry e escolha do modelo	O Copilot provisiona o projeto e compara modelos com base nos critérios do cenário, até o apresentador escolher GPT 5.4 Mini.
03:37	Teste do modelo e criação do agente	No Foundry Canvas, o apresentador verifica o modelo, testa respostas com o catálogo e pede ao Copilot que crie o agente.
05:11	Inspeção local e implantação do agente	O agente é inspecionado localmente quanto a grounding e precisão, depois implantado no Microsoft Foundry e testado.
07:19	Conexão segura do agente ao site	Uma Azure Function protege as credenciais e conecta o agente a um widget de chat no site da Tailspin Toys.

Citações

Se não está no catálogo, o agente precisa dizer isso. — 01:01

Nosso catálogo tem cerca de 11 quilobytes, tamanho pequeno o bastante para ir direto no prompt. — 02:36

Adorei que ele parou para confirmar comigo primeiro, para que eu ficasse mais ciente do que está acontecendo. — 04:40

Quem chega com uma vibe agora tem alguém a quem perguntar, e o agente só responde com base no catálogo. — 08:22

Conceitos e entidades

GitHub Copilot app (ferramenta): App usado para orientar, por meio de prompts, a criação, o teste e a implantação do agente.
Microsoft Foundry Skill (ferramenta): Skill usada para criar e configurar recursos no Microsoft Foundry.
Foundry Canvas (ferramenta): Interface do app que permite visualizar e interagir com recursos do Microsoft Foundry.
Microsoft Foundry (ferramenta): Plataforma usada para provisionar o projeto, implantar o modelo e hospedar o agente.
Tailspin Toys (empresa): Site fictício de financiamento coletivo para jogos com temas de desenvolvimento, usado como exemplo no vídeo.
catalog.json (repo): Arquivo com dados de 21 jogos, usado como fonte de informações para o agente.
GPT-5.4 Mini (modelo): Modelo escolhido e implantado para atender ao cenário do agente.
GPT-5.5 (modelo): Modelo comparado durante a seleção e considerado excessivo para o cenário.
GPT-5.4 nano (modelo): Modelo comparado durante a seleção, mais barato, mas considerado mais sujeito a não cumprir os requisitos estritos de grounding.
Microsoft Agent Framework (ferramenta): Framework usado para implementar o agente concierge.
Azure Developer CLI (ferramenta): Ferramenta usada para executar comandos do agente durante a inspeção local.
Azure Functions (ferramenta): Proxy de servidor que autentica no Foundry, chama o agente e envia apenas a resposta ao navegador.

Tradução completa (pt-BR)

00:00 Os filtros são ótimos quando seus usuários sabem exatamente o que estão procurando. Mas muitos deles não chegam pensando em um filtro. Eles chegam com uma vibe. Veja a Tailspin Toys, um site de financiamento coletivo para jogos com temática de desenvolvimento. Os filtros por categoria e publicadora são úteis, mas limitados. Nenhum menu suspenso do mundo responde à pergunta: quais jogos seriam adequados para alguém que adora trocadilhos com Git? Então, hoje, sem sair do aplicativo GitHub Copilot, vou usar o Microsoft Foundry Skill e

00:30 o Foundry Canvas para criar um concierge para apoiadores, um agent que responde a perguntas como essa e, o mais importante, nunca inventa informações. Vamos começar. Iniciei uma nova sessão de agent e anexei o issue que solicita esse recurso. Isso adiciona ao contexto, logo de início, a descrição do problema, a solução proposta — esse é o nosso agent — e os critérios de aceitação, pelos quais vou cobrar o Copilot. Primeiro, os dados.

01:01 Vou pedir rapidamente ao Copilot para instalar as dependências, preencher o banco de dados com dados iniciais e executar o script de exportação. Um único arquivo, catalog.json, contém 21 jogos, cada um com um id, título, descrição, categoria, publicadora e classificação em estrelas. Igualmente importante são as informações que estão faltando. Não há valores totais arrecadados, contas de apoiadores, preços nem datas de lançamento. Essa lacuna é o limite de confiança. Se não estiver no catálogo, o agent precisa dizer isso.

01:33 Vou abrir rapidamente esse arquivo para confirmar que os dados estão no lugar. Agora o agent precisa de um lugar para existir. Meu prompt orienta o Copilot a usar o Microsoft Foundry Skill, criar um grupo de recursos e um projeto do Foundry chamado TailSpin Toys. O aplicativo carrega o skill, verifica meu login e minhas funções do Azure e provisiona tudo na região North Central US. Meu grupo de recursos e o projeto do Foundry no Azure estão prontos.

02:04 A próxima questão é qual modelo usar. Com milhares de modelos para escolher no Foundry, isso pode dar bastante trabalho e acabar levando a um simples chute. Em vez disso, peço ao Copilot que analise o issue do GitHub e recomende dois ou três modelos de chat que atendam aos critérios de aceitação e, depois, espere eu escolher. Também quero ver as compensações lado a lado antes de fazer o deploy de qualquer coisa. Ele extrai os recursos essenciais de que preciso para meu cenário, que são fundamentação,

02:36 seguimento de instruções e uso de ferramentas. Vou destacar duas coisas. Primeiro, quanto à fundamentação, nosso catálogo tem cerca de 11 kilobytes, o que é pequeno o suficiente para ir diretamente no prompt. Então, o Copilot determina que não é necessário um índice de busca. Segundo, quanto ao uso de ferramentas, ele lista a pesquisa na web como um requisito, mas eu realmente não preciso nem quero isso. Nesta etapa, você só pode enviar prompts de acompanhamento para corrigir qualquer informação imprecisa.

03:07 Ele compara GPT 5.4 Mini, GPT 5.5 e GPT 5.4 nano, e todos estão em disponibilidade geral na minha região. O Nano é o mais barato, mas tem mais chances de não atender aos nossos requisitos rigorosos de fundamentação, enquanto o 5.5 é exagerado. Então, ficamos com o Mini. Vou pedir ao Copilot para fazer o deploy, mas primeiro verificar a cota e me deixar confirmar a capacidade de processamento.

03:37 10.000 tokens por minuto vão funcionar e, segundos depois, meu modelo está em deploy. É aqui que o aplicativo Copilot faz algo diferente. No painel de sessões, abro o Microsoft Foundry Canvas, que me permite ver e interagir diretamente com meus recursos do Foundry. O Copilot criou um projeto do Foundry para mim antes, e posso carregá-lo no canvas. Acabamos de fazer o deploy de um modelo, e posso verificar

04:08 isso aqui também, na seção de modelos. Fiz o deploy desse modelo exclusivamente com base na recomendação do Copilot. Então, antes de criar um agent com ele, quero testar e ver como ele lida com meu cenário. Vou pedir ao Copilot para chamar um modelo diretamente, usando um catálogo como contexto e um exemplo de prompt de usuário. Surge um primeiro obstáculo real. O Copilot descobre que preciso de uma função adicional, como Cognitive Services

04:40 OpenAI user, para chamar o modelo diretamente. Então, ele para e pergunta. Poderia facilmente ter aplicado a correção sem me perguntar, o que teria sido aceitável, mas adoro que tenha parado para confirmar comigo primeiro, assim fico mais ciente do que está acontecendo. Com a função atribuída, o prompt de teste do usuário é enviado ao meu modelo em deploy, e ele retorna esta resposta com dados reais do catálogo. Agora é hora de criar o próprio agent.

05:11 No canvas, expando a seção de prompt inicial do conjunto de criação, escolho hello world e, em seguida, substituo o prompt inicial pelo meu. Quero criar um concierge para apoiadores com o Microsoft Agent Framework, que siga os critérios de aceitação do issue. A opção Create with Copilot envia esse prompt à minha sessão junto com o contexto do meu projeto. Em vez de montar o código do zero, o Copilot encontra e busca na galeria do Foundry um exemplo próximo do que preciso,

05:43 personaliza-o e, alguns minutos depois, informa que o código do agent está pronto. Conforme minhas instruções, o código do agent fica em uma pasta agent, e você verá um arquivo de configuração Azure.yaml que aponta para esse código do agent para fazer o deploy no serviço de agents do Foundry por meio do host azure.ai.project. De volta ao canvas, a seção Build Your Agent já está conectada ao meu agent,

06:14 e, em deploy and test, posso inspecioná-lo localmente antes de fazermos o deploy. A opção Inspect locally executa comandos do agent por meio da Azure Developer CLI para executar o agent e abre o Agent Inspector já conectado a ele. No playground do agent, primeiro testo a fundamentação, e o modelo recupera corretamente jogos do catálogo. Posso ver aqui o resumo do uso de tokens e quaisquer chamadas de ferramentas. Este próximo prompt é uma armadilha para alucinações,

06:47 e vejo que o agent respeita o limite que definimos e só oferece o que sabe. Este terceiro prompt testa a precisão. Estou vendo títulos reais, classificações reais e um comportamento do agent bom o suficiente. Então, estou pronto para fazer o deploy. Vou sair do Agent Inspector e fazer o deploy no Foundry. Mais uma vez, isso envia o prompt junto com as informações do meu projeto ao Copilot e, pouco depois, recebo a confirmação de que meu agent está ativo no meu projeto do Foundry.

07:19 Vamos testar o agent em deploy. O Copilot o invoca diretamente usando a extensão azd ai, e recebemos uma resposta. A última parte é colocar o agent diante dos meus usuários. O site da Tailspin Toys é totalmente pré-renderizado. Não há um servidor por trás dele, então o navegador não pode chamar o agent diretamente, e nunca deve armazenar credenciais do Foundry. Então, vou pedir ao Copilot para criar uma pequena função do Azure como proxy, que será executada localmente, e

07:49 armazená-la em uma pasta API. Ela se autentica no Foundry com meu próprio login do Azure, chama o agent e envia apenas a resposta de volta ao navegador. Também vou testar rapidamente essa chamada de função e inspecionar o que ela retorna. Com esse limite seguro para as credenciais do lado do servidor estabelecido, adiciono então ao site um widget de chat acessível, conectado a essa API,

08:22 e que segue as orientações de design do site. E, assim, meus apoiadores podem interagir diretamente com o agent no site e acessar informações precisas, mesmo quando não sabem exatamente o que estão procurando. Os apoiadores que chegam com uma vibe agora têm alguém a quem perguntar, e o agent só responde com base no catálogo. Testamos a fundamentação do modelo, criamos e inspecionamos

08:52 um agent local, fizemos o deploy dele no Microsoft Foundry e o conectamos ao site. Cada uma dessas etapas começou como um prompt. O Copilot, com os skills do Foundry e o Foundry Canvas, fez a construção. Eu só tomei as decisões. O workshop completo está na descrição, então vá criar o seu. Só lembre-se de excluir os recursos do Azure quando terminar e inscreva-se para ver mais.

Transcrição original

[00:00] Filters are great when your users know exactly what they’re looking for. But plenty of them don’t arrive with a filter in mind. They arrive with a vibe. Take Tailspin Toys, a crowdfunding site for developer themed games. Its filters by category and publisher are useful, but limited. No dropdown on Earth answers the question which games would suit someone who loves git puns So today, without leaving the GitHub Copilot app, I’m using the Microsoft Foundry Skill and

[00:30] Foundry Canvas to build a backer concierge, an agent that answers questions like this, and most importantly, never makes things up. Let’s dive in We’ve a new agent session started, and I attach the issue requesting this feature. This adds the problem statement, the proposed solution, that’s our agent, and the acceptance criteria, which is what I’ll hold copilot to, to the context upfront. First, the data.

[01:01] I’ll have Copilot install dependencies, seed the database, and run the export script. A single file, catalog.json, contains 21 games, each with an id, title, description, category, publisher, and star rating. Equally important is the information that’s missing. No funding totals, backer accounts, prices or release dates. That gap is the trust boundary If it isn’t in the catalog, the agent has to say so.

[01:33] I’ll quickly open that file to confirm that the data is in place. Now the agent needs somewhere to live. My prompt guides Copilot to use the Microsoft Foundry skill, to create a resource group, and a foundry project called TailSpin Toys. The app loads the skill, checks my Azure sign-in and roles, and provisions it in North Central US. My resource group and the foundry project on Azure are ready.

[02:04] The next question is which model to use. With thousands of models to choose from on foundry, this can be a lot of work and could result in simply guessing. Instead, I ask Copilot to review the GitHub issue and recommend two or three chat models that meet its acceptance criteria, and then wait for me to choose. I’d also want to see the trade-offs side by side before I deploy anything. It extracts the critical features that I needed for my scenario, which are grounding,

[02:36] instruction following, and tool use. Two things I’ll call out. One, on grounding, our catalog is about 11 kilobytes, which is small enough to go straight into the prompt. So Copilot determines that no search index is needed. Two, on tool use, it lists web search as a requirement, but I don’t really need or want that. You can only send follow-up prompts to correct any inaccurate information at this stage.

[03:07] It compares GPT 5.4 Mini, GPT 5.5, and GPT 5.4 nano, and all are GA in my region. Nano is cheapest, but more likely to fall short on our strict grounding requirements, while 5.5 is an overkill. So Mini it is. I’ll ask Copilot to deploy it, but check the quota first, and let me confirm the throughput.

[03:37] 10,000 tokens per minute will work, and seconds later, my model is deployed. Here’s where the Copilot app does something different. From the sessions panel, I open the Microsoft Foundry Canvas, which allows me to directly see and interact with my foundry resources. Copilot created a foundry project for me earlier, and I can load it up on the canvas We just deployed a model, and I can verify

[04:08] that right here under models as well. I deployed this model purely based on Copilot’s recommendation. So before I build an agent on top of it, I want to test and see how well it handles my scenario. I’ll have Copilot call a model directly with a catalog as context and a sample user prompt. A first real blocker is encountered. Copilot finds out that I need an additional role like Cognitive Services

[04:40] OpenAI user to call the model directly. So it stops and asks. It could have easily apply the fix without asking me, which would have been fine, but I love that it stopped to check with me first so I’m more aware of what’s going on. With the role assigned, the test user prompt goes through to my deployed model, and it returns this response with real data from the catalog. Now it’s time to build the agent itself.

[05:11] In the canvas, I expand the set you starting prompt section, pick hello world, then swap the starting prompt for mine. I want to back a concierge on Microsoft Agent Framework that held to the acceptance criteria in the issue. Create with Copilot hands that prompt to my session along with my project context. Instead of assembling the code from scratch, Copilot finds and pulls a sample close to what I need from the foundry gallery,

[05:43] customizes it, and a few minutes later, reports that the agent code is ready. As per my instructions, the agent code lives in an agent folder, and you’ll see an Azure.yaml configuration file that points to that agent code for deployment to the foundry agent service through the azure.ai.project host. Back on the canvas, the Build Your Agent section is already connected to my agent,

[06:14] and under deploy and test, I can inspect it locally before we deploy. Inspect locally executes agent commands through the Azure developer CLI to run the agent and opens agent inspector already connected to it. In the agent playground, I first test for groundedness, and the model correctly retrieves games from the catalog. I can see token usage summary and any tool calls over here. This next prompt is a hallucination trap,

[06:47] and I see the agent respects the boundary we set and only offers what it knows, and this third prompt tests for accuracy. I’m seeing real titles, real ratings, good enough agent behavior. So I’m ready to deploy. I’ll exit the agent inspector, and deploy to foundry. Again, this sends the prompt along with my project information to Copilot and shortly after I get confirmation that my agent is live in my foundry project.

[07:19] Let’s test the deployed agent. Copilot invokes it directly using the azd ai extension, and we get a response back. The last piece is to put the agent in front of my users. The Tailspin Toys website is fully pre-rendered. There’s no server behind it, so the browser can’t call the agent directly, and it should never hold foundry credentials. So I’ll have Copilot build a small Azure function proxy that runs locally and

[07:49] store it in an API folder. It authenticates to Foundry with my own Azure sign-in, calls the agent, and sends only the answer back to the browser. I’ll also quickly test that function call and inspect what it returns. With that secure server side credential boundary in place, I then add an accessible chat widget on the website that is wired to that API,

[08:22] and that follows the site’s design guidance. And just like that, my backers can interact with the agent directly on the website, access accurate information even when they don’t know exactly what they’re looking for. Backers who show up with a vibe now have someone to ask, and it only answers from the catalog. We tested out the model for grounding, built and inspected

[08:52] a local agent, deployed it to Microsoft Foundry, and connected it to the website. Every one of those steps started as a prompt. Copilot with the foundry skills and the foundry canvas, did the building. I just made the calls. The full workshop is in the description, so go build your own. Just remember to delete the Azure resources when done, and subscribe for more.