Skip to content

How to build and ship an AI agent in the GitHub Copilot app

Read the Portuguese translation →

Author: GitHub · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: How to build and ship an AI agent in the GitHub Copilot app · Channel: GitHub · 08:52 · Watch on YouTube

Topics: AI agents, Cybersecurity and software security, Software engineering with AI, AI developer tools

The video demonstrates building and shipping a backer concierge agent for Tailspin Toys using the GitHub Copilot app, Microsoft Foundry Skill, and Foundry Canvas. The agent uses a 21-game catalog as its grounding source and is instructed to acknowledge information that the catalog does not contain. Copilot helps select and deploy a model, generate the agent, test it locally, and deploy it to Foundry. The walkthrough then adds an Azure Function proxy and a website chat widget so users can securely interact with the agent.

  • The Tailspin Toys catalog contains 21 games and does not include funding totals, backer accounts, prices, or release dates.
  • The catalog’s missing information defines a trust boundary: the agent should not claim knowledge beyond the catalog.
  • Copilot provisions a Microsoft Foundry project and recommends models based on grounding, instruction following, and tool use.
  • The catalog is small enough to include directly in the prompt, so the demo does not require a search index.
  • After choosing GPT 5.4 Mini, the presenter checks quota and confirms the throughput before deployment.
  • The presenter tests the model and agent in Foundry Canvas and the agent inspector, including prompts that check grounding and hallucination resistance.
  • Copilot builds and deploys the agent to the Foundry agent service, then invokes the deployed agent for a test.
  • An Azure Function proxy authenticates to Foundry server-side and returns only the answer to the browser, keeping Foundry credentials out of the website.
  • A chat widget connects the website to the proxy, allowing backers to ask questions conversationally.
Start Chapter Summary
00:00 Defining the concierge and its data boundary The presenter introduces the Tailspin Toys use case, attaches the feature issue, prepares the game catalog, and establishes that the agent must not invent information missing from it.
02:04 Choosing and testing a model Copilot compares chat models against the scenario’s requirements, deploys the selected model, and helps test it with the catalog as context.
04:08 Building and inspecting the agent After resolving a role requirement, the presenter creates the agent in Foundry Canvas and tests its grounding, accuracy, and handling of unsupported questions.
06:47 Deploying the agent and connecting the website The presenter deploys and tests the agent, adds a server-side Azure Function proxy, and connects it to an accessible website chat widget.

If it isn’t in the catalog, the agent has to say so. — 01:01

So Copilot determines that no search index is needed. — 02:36

I love that it stopped to check with me first so I’m more aware of what’s going on. — 04:40

Backers who show up with a vibe now have someone to ask, and it only answers from the catalog. — 08:22

GitHub Copilot app, Microsoft Foundry Skill, Foundry Canvas, Microsoft Foundry, Tailspin Toys, catalog.json, GPT-5.4 Mini, GPT-5.5, GPT-5.4 nano, Microsoft Agent Framework, Azure Developer CLI, Azure Functions

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.