Rubber Duck Thursday (Post-Build Edition)

Heat. Heat. Hello. Hi everyone. Good morning, good afternoon, good evening depending on where you are joining from. Welcome to this week's live stream the rubber duck Thursdays and this is a special edition because we'll be doing some build recap. So last was Microsoft field and in this live we'll sort of just share what we learned from the event last week um regarding all the announcements related to GitHub. So I'm excited for this one. Um it's obviously going to be very insightful. We'll have everyone kind of share what you learned at build last week. So hopefully you all got a chance either attending platform or watch the live streams and so probably in the chat uh you can just let us know if you were able to join Microsoft build last week. If yes, what are your key takeaways? So we can just start that as a quick um icebreaker before we get started. All right, I see a lot of people already contributing on the chat. Welcome Matrix Coder GitHub. Good to have you on the stream. Howdy Don. Welcome. All right. Greetings from Spain. All right. I won't even um attempt to pronounce that, but greetings received and hi back. Welcome and thank you for joining the stream. All right, where's everyone else joining from? As I said, this is going to be an interesting stream. We are going to do some post build recap. So, if you managed to join Microsoft last week, either in person, virtually, or you just caught up with some of the on demand videos, let us know what you learned. um from last week's event of course related to GitHub. That's why we are here on this stream ready to just chat about the awesome announcements that were announced last week. Hello Edwin, welcome to the live stream. You're joining from Lagos, Nigeria, 17year-old DevOps cloud engineer. Wow, fantastic. Um quick one, Edwin. I don't know if you managed to join build last week, but there was quite a lot of interesting announcements around Azure DevOps and GitHub coming together. So hopefully you managed to catch that, but if not, we'll just go through it briefly as part of the recap. So you can just let us know how the space of DevOps engineering is evolving and how the integration probably with GitHub um comes along to support that. So good to have you Edin the live stream. Hey Chris joining from Australia. Welcome. We have a LinkedIn user joining in from India. Welcome to the show. I myself I'm joining from Nairobi. I'm not in my home office right now. I'm in a different setup for a team offsite activity. Hence the different um you know just the difference that you see. Um, so I'm currently hotspotting this live stream. So in case my screen buffers, just let me know on the chat and I'll see what I can readjust just so we can have a seamless experience. All right, good to see everyone joining. So now the question that I will kick us off with is number one, did you manage to join Microsoft Build last week? If yes, what was your key takeaway? Something that you learned and you were like, hm, this is actually really cool. I might try it. So, what did you learn last week at Microsoft build related to GitHub? So, just share something that you either picked up on. And at the same time, if you have any questions around the recent announcements you've been seeing from GitHub, this is the space for us to have this conversation. So again, I'm just buying time just to accommodate any questions that you have them on the chat and we will go through them. Welcome from Nigeria. Another user from Brazil. Welcome, welcome, welcome. As you share where you're joining from, please let us know. Last week's event that was big. We had so many announcements. What was your key takeaway? and share. One, three, two. Do we have any questions or comments or again, what did everyone learn and build? We have Jenny from Germany. Welcome to the show. Okay, so in the interest of time, I'll probably kick us off. So, I'll just share some of the key um key takeaways that I had from Bill from last trip, but please keep them coming on the chat. I'll be pausing and and then just just read through the chat and see your key points that you share. So, I'm going to go ahead and uh pop up my screen. Um again I'm navigating just one one screen so bear with me it will be a bit painful but we'll get through the stream and I managed to watch some sessions again just around GitHub copilot we had so many really cool announcements at build last week and the first tool that I will share because I haven't seen anyone share something that they learned last week if you are not aware of this, there is a a build CLI. So there's a tool, there's a skill that can allow you to connect GitHub build session catalog and this is where you can get it. I'm just going to pop this link on the chat for everyone. Just going to drop this in for you. So this is a really really cool skill because what happens is you have just two steps. Install it in GitHub copilot restart your copilot and then you can query right there on your copilot CLI sessions that happened at build sessions related to GitHub GitHub copilot. You can ask it to summarize some of the technologies and the stacks that you are interested in. You can even take it a step further, right? Can step you can take it one step further where you can ask co-pilots to scaffold a project from a session. So assume you attended a session maybe it's one that talks about what's new in Azure DevOps and it's a copilot and then you liked that session you can ask copilot through this skill to perform a new project that will allow you to implement what you learned from that session. So that's a really really good way for you to make it practical. If you picked up something quite interesting from the conference, don't just sit on that knowledge, spin up a project, put it into practice, and keep building. So, this is one of the use cases that you can use. Again, it's just installing it as a plugin on the CLI. I'm actually just going to switch to my terminal. And uh just let me know in case you lose my audio or my video feed. um let me know if that happens. But what I'm going to do is for my terminal I am in this I'm going to type to open copilot right here on the terminal and then that's it. If I do slash plugin list, you should see that I have the Microsoft event plugin installed. Right? So you can get this from the repository that I just on the chat. So, what this will allow me to do is I can go in with a prompt like um pull all sessions up at Microsoft. Give me give me session links a summary summary for each and takeaways. uh format this in K. Let's test that. So here we should see the copilot agent use the um the Microsoft build skill. So you'll see it has activated the Microsoft skill and then it's going to query the um build session catalog and it's going to filter for sessions that contain the title of GitHub. So I'm just going to approve this request. I will approve for all future um requests in this directory. And so I expect the agent here through this skill to find a way to navigate the catalog. just narrow down, get a list of GitHub related sessions and then just bring you that bring me back that summary. Okay. Um, so I'm just going to allow it. I'm just going to give it permission to do this. Hopefully it doesn't take a lot of time. Okay, so it's just working with the skill. It's able to connect to the event page. It's able to query the sessions. And I should hopefully in just a few seconds um get a nice list of GitHub related sessions. So it looks to be it looks to be writing some Python code. Achieve this. Let me just switch back see if we have anything new on the chat. All right. Again, I'm sharing this in the interim as I allow everyone to share what they learned at build last week. Again, if you even missed the whole thing, use this um skill with your co-pilot. um right here in the terminal and it should allow you to basically just query all the events that happened last week. You can filter down uh by technologies, programming, language, products and get detailed summaries etc. Okay, so I'm going to try this again. Let me just open a separate window. Um this model I'm using Gemini 3.5 flash. It's a smaller model, so it appears to be struggling um more than it should with this task. So, let me switch to a different model. I'm going to switch to let's use it. Um let's use it in medium and default context window. And then I'll bring the same prompt and send disabled. All right, let's see if our model was able to return something. Okay, there we go. So after working very very hard, our model here was able to retrieve some sessions. So, it's given me a summary, a session link, and the code. So, let's just see this. I'll click on that, and hopefully it's going to direct me to session code dem 350. And there we actually have a session here, GitHub agentic workflows automation that actually hits the room. So, yeah. So, this is how you can just quickly catch up with what happened at Google. Again, filter down with your technology of choice. You can use a product of choice. As I said earlier, you can even just run copilot inside your project and then ask it to determine based on your dependencies, right? What should you watch because most of the sessions are available to watch on demand based on what you're working on. So in your project in your working directory which is the session that copilot would recommend that you actually go back and watch. So there are very many use cases for you to use the Microsoft build um skill and plugin. So definitely give it a try. All right, I'll go back to the chat. Okay, I see a lot of people joining. No one is yet to share what they learned at build. So I'm a little bit worried there. Did we not actually make it to build last week? But if not, no worries. I will just do a brief summary of some of the sessions that I managed to watch. The first one being um this session here. It was a breakout um led by Patrick Nicollet from the co-pilot the SDK team as well as Steve Sanderson. Now I will just do a very quick um walk through of what this session was about my top three um learnings and then I'll allow everyone to just share their comments and questions in the process. So the session here was highlighting the GitHub copilot SDK and I'll just grab the link to this exact session. Here you go. So you can just um bookmark this or from the recap that we do right now if it's something you find interesting then you can go ahead and watch it. It's it's a really really good session. So the first key takeaway that I had is that last week copilot SDK is finally now generally available. So you are free to use the SDK even in your production environment. Um, if you're like me who tried out the SDK as soon as it was announced in technical preview, that was in January and that was ages ago, then you've probably seen the improvements that have gone into the copilot SDK itself. One from the number of supported programming languages. We now have Java and um, Rust supported as well as the other four popular languages. So you can easily just bring this whole power of copilot agents into your own applications. So that was the first key announcement that I picked from this session last week that the SDK is now generally available. Now, for those of us on the stream who might not really know what the SDK is or what it does, um just a quick summary here is every time you run the copilot CLI, you spin up an agent on your terminal. So, the SDK allows you to programmatically bring that agent into your own applications. So, think of it this way. If today you were asked to build a proof of concept to build and integrate some agent functionality in your application instead of worrying so much about how to um manage your own agent sessions, how to manage your own um tool infrastructure, tool calling, session management, context management, instead of worrying how you can write that from scratch, you can simply use the copilot SDK to connect to the copilot CLA that runs on your computer and then just use that in server mode to power your agentic functionality. And so to put this into perspective, I'm just going to show you one of the applications that I'm building that leverages this capability. So this is study sync. Um it's a simple platform that allows me to manage my coursework academic documents. So, think about a student who's looking for a way to interact with their school documents. And so, you can use this AI chat feature that will spin up the cost assistant agent and it will of course do the usual. You can talk about your coursework. In this case, I'm asking it, hey, at some point, I know we talked about parallelism. Which lecture was that? It's then to pull this from a document. You covered that in lecture two as well as in lecture eight. So you can see this is just basic AI agent functionality on an application. But what is powering this behind the scenes is if I open copilot in the terminal um you see that I can resume my sessions and one of the session that you will see here is that conversation that I just had with agent on my application. So the SDK allows me to do exactly this. I can um interface with my AI agents on the application using the copilot CLI as the AI back end. So you can come back and review that conversation, see the custom pro tool calls that agent made and basically just use it to quickly spin up working prototypes for AI solutions. So that's the SDK we're talking about. That's the SDK we just said went through a last build. And I'm going to pause there again. Switch over to the chats. Okay, welcome. I see we have a few more people joining. So for those joining, we're just doing a quick recap of last week's um event, Microsoft Build, looking at some of the GitHub related announcements. Again, if you have any questions, feel free to drop them on chat. Okay. So the other key takeaway I had from this session is that um you know this copilot SDK now opens up an opportunity for us to have um a streamlined agentic experience across the different copilot interfaces. What do I mean by this? The same harness that powers the cloud agent that sits on github.com is the same harness that is powering copilot CLI and then is the exact same harness that is now powering our copilot SDK. So this presents an opportunity for you across these different surfaces to have that um streamlined way of interacting with your agents. I think that's really really valuable. So across surfaces, across platforms, you're able to have this one streamlined um agentic experience, an agentic harness that has all of these um features built in. So if you're building a system that fully have an AI agent, you're not having to worry about how do you manage the tools, how do you handle permissions, how do you handle session management, how do you handle customization, streaming. You get that out of the box by using the copilot SDK. So I think that's extremely powerful and very valuable for developers who really want to get hands on and extend the power of Copilot across your entire application stack. So that was uh something that I picked from this session. The other thing I'll highlight is that um Steve here did a bunch of amazing demos. I mean the demos were were just incredible. And one of the scenario that we had here is assume that you work for a real estate company and your role revolves around um receiving inquiries, charging them. But before you engage the sales agent, you want to quickly validate these inquiries that come in so that you automatically reject those that are not related to real estate or to your company. And then after you validate them for those that are valid inquiries, you then do a quick search across your portfolio, your properties, and then if you don't find anything that can satisfy the needs of this customer, then you just um put that aside. But then if you find something that this customer would actually like, then you generate a report and then pass that to the sales agent. So by the time you are engaging a sales agent, you are sure that that's a valid request. are sure that it's um it's it's a valid or um a case that can lead to sales and then that's when you engage sales agent. So this is the scenario that Steve demoed and again I'm just going to highlight and summarize what he captured but from the link on the chart if this is interesting to you en sure that you watch that session I'm sure you'll find it insightful. So what Steve did here was he just used the copilot SDK to build an agent orchestrator system that manages multiple agents that work to achieve this goal. So you will receive a bunch of inquiries and then you'll in real time as you're watching that section you will see these different agents just working to validate the inquiries to look through your internal um portfolio documentation and also generating the report. So that was a really good demonstration of a very common business use case in which you can see the copilot SDK in action. Again allow me to just back to the chat. Right. So Maverick is asking is it possible to watch the sessions later? So if you're referring to the build sessions, yes, if you scroll up in the chat, I have just dropped a link to this session that I'm just sort of summarizing right now that talked about the copilot SDK. But for most of these sessions, yes, they are available on the um on the Microsoft build website and you can also find them on YouTube. So if you go on YouTube and look for the Microsoft developer channel, you will likely find all the recordings from the keynote and all the demo sessions and breakouts that were recorded. So yes, you can rewatch these sessions and this live stream is also going to be available in case you want to recap anything that you missed. So Maverick, I hope that answers your question. So that's the copilot SDK. Again, it's still a 45inut session, but there was so much to take home, including these different isolation models, right? As you're building your agents, you want to be very careful in terms of how your AI systems interact with, let's say, your host operating system, how you manage permission to your tools, the tool coping. And so Steve here talked about three distinct isolation models that are made available as working with the copilot SDK. So the one that I just showed earlier where you simply just have the agent running in your host operating system that's the direct execution. So for you as the developer you are responsible to limit access to tools. So you define which tools you want this agent to have access to and then you can also have some mitigation um um policies where you can have human in the loop as a required step to probably accomplish a certain task. So that is the direct execution. That's probably what most of us are already using. But then on top of that, there's a second isolation model that is offered which is the container per session model. And so as the name implies here is that this model allows you to spin up a container per session. So if you're looking at total isolation between the different sessions that you have then this might be an isolation model that is worth looking into. Um so the idea here is that um the agent loop will run on the host OS but then all the tool calls all the network calls will be redirected to a separate um container. So that's the whole idea behind this second um isolation model and again on this session we does a fantastic job at trying to explain what that means and how it looks like and then the third isolation model was the OS managed sandbox. So again as the name sort of um leads to is that you can have your agents running on your local um on your host operating system but then you're having some OS level policies that are being enforced. So you're having a sandbox that has your own sandbox policies. We get to define if this agent is let's assume is able to run all the tools including the tools that it shouldn't run then we'll have an additional layer of some policies that will prevent it from performing any detrimental actions and to illustrate this um yeah and and what powers this functionality is the MX free library it's a new sandbox technology that allows you to spin up a sandbox environment defined your policies and then in this case you'll have your operating system level of control. So the operating system itself will restrict what the agent can and can't do. So what this means and hopefully with this example it will make more sense is assume that your agent is actually um one the prompts are not very rigid. they're not um very concrete in terms of restricting what the agent should do. So assume a scenario where a bad actor manages to prompt inject your agent. So that means they will get these agents to perform an action that it shouldn't be performing in the first place. So assume that step is successful. So in this case the prompt won't protect you and your systems. So in that case what you'll see here is the agent number one has received and will follow the instruction to um to probably let's say access your file system alify alter and modify some some some some documents in your directory and then number two this agent has access to the tools that will allow it to perform all these actions. Again, that's a very bad design practice because the recommendation is just have the agent access tools it needs. Don't give it um permission to access tools that probably shouldn't have access to. So now assume that scenario where your agent one has been prompt injected and two has a powerful set of tools. So it can do really really um crazy things. So what Steve demonstrated here is that at the moment this sandbox feature is still in preview. So you can see that the configuration is in this JSON document. So you can see you just come in here in this JSON document and then enable the sandbox policy configuration and then I'll specify what do you want this agent to have access to. What do you want it to be able to read? What do you want it to be able to write in terms of the network configuration? what should be the allowed outbound, the allowed local network. So you can have full control over what the operating system should allow or reject when it comes to the agent. So for the example that he shared here was um he tried to just send a malicious prompt to this agent and of course he modified the prompt that the agent tried or attempted to run some partial commands the root in the in the root of the users's operating system. But then you see here that the sandbox policy was actually able to kick in and block this agent from performing that task. So you can think of it as an additional layer of restriction in that if your agent configuration fails at some point then you do have a fallback you have a backup where the sandbox the operating system itself is going to restrict the actions that the agent can take. So that again was another really really cool um um key takeaway from this session. Let me go back again to the chat. Maverick, you're welcome. Anything else questions, comments? What did you all learn at build last week? That is still my question for everyone. All right, so the last thing again I said this was just um it was actually less than 40 minutes um but there was just so much that was shared which I think is just worth recapping. Um so one of the isolation models we talked about here is the container per session model and as you're already thinking about it yes you get the full advantage of having total isolation but then there's a disadvantage in that this is going to be very resource intensive and then number two it's going to be costly. So you can already imagine if you're spinning up a container for each session then that of course is going to be expensive. So um a proposed workaround or a solution that um was presented is this new extensibility which allows you instead of spinning up a full container per session, you basically create a virtual file system for each session. So you're not you're not like creating a full container per session. you're just creating a virtual file system um that is tied to one session. So this this means that session one will not be able to see what session two is doing and that also applies to sessions having visibility to your host operating system file system. So that I think was also a really really good um demonstration of measures that the CLI and HDK team are actually taking to ensure that as you're using these technologies you are your security posture is taking care of because if you think of this approach you're getting the same benefit of spinning up isolated containers but without the cost since you're just running a virtual file system. And so for you to actually practice this, there's a sample that was shared and I'm just going to pull that for you. There's a sample that's on GitHub. It's github.com/github/copilot SDK server sample. So this is the sample that was used in this session. It will allow you to run an application and you'll see that it will number one not have access to your host file system and then number two if you spin up multiple sessions it will these different sessions won't have visibility to what each other session is doing. So it's a really good sample just to give you that idea that understanding of what does it mean to run these sessions in isolation. And again, I'm just going to drop this on the chat for everyone. I'll put it there for you. And so what I did, I actually tried this out because I was very curious to understand how all of this was meant to work. So again, I'll just jump ahead of myself here and just talk about the copilot app, which was the other very big announcement last week from the keynote itself. We saw Cassidy doing a demo on the copilot app, which again went to a last week. So if you've not seen it, this is the copilot app, right? So it's just an application that sits on top of the copilot CLI. You're able to start different sessions. You have a centralized management control plane for all your agent sessions. If you're like me, you probably have different agents working on different parts of your project. So, you have an agent running in VS Code, you have one running in the terminal, and sometimes you even forget what these agents are doing or an agent that you started a few minutes ago just slips through the cracks. Now, with this application, you're able to have all your agent sessions centrally managed for each of your projects. And you can simply just have this one manage view. You can start a new session in any project at any given time. You can select your mode. You can work through your models, set your reasoning effort level, and you can of course just leverage most of the features that are available through the CLI. So if you've not yet tried tried it out, I highly recommend if you want to get a feel of you know how this future of developers having an agent uh you know like this agent first um developer tooling then this is definitely um an application that you want to check out. So feel free to look it up. So what I did was I actually just started a new session and let me just expand it here to have more room. So I started a new session and I pointed it to that repository. This is again the sample to show how you can run different copilot civilizations in isolation by creating these virtual file systems for each. So I just pointed it to the repo and I told it hey can you start this application to demonstrate session isolation. So it did that in a few minutes it was able to just read through the application know what it was about see if I had the necessary permissions for it to run it and then it just started the application for me. So you can see I have it running here. So um what I can do just to demonstrate this very briefly is I can type a command like um ls. So this will allow me to see the contents of this file server. So what I can do is just a minute. Yeah. So what I can do just to demonstrate this concept of having agent sessions run in complete isolation without the overhead of spinning up a separate container for each is I can probably create a file. So let me create a file here we have hello let's save it in test. I'll hit enter. And now if I look into my directory I have this test.txt txt file that's fine but now if I start a new session the expectation is that this file should not be visible from another a session so if I click on start a new session and I do the same thing then you see that the file you just created previously is not being referenced in this agent session so it's running in that virtual isolated environment as I was talking about it now I went a step further because I realized that as I was explaining this concept to you on this live stream today, I might not really be able to demonstrate the impact of this feature, the value of this feature. So there's this new um feature in the copilot app which allows you to create a canvas. Now again, this is another very interesting concept. I highly recommend that you revisit some of these sessions at build last week that talk about the the the canvas feature. So this allows you to create sort of a UI that you can use to interact with the agent and the agent to interact with your applications. So in this case I told copilot to um I used the /create canvas command and I told it that hey I want to see this example side by side. So I want to see two chat interfaces. One I want you to have the virtual file system mode turned on and then on the other side I want it to be turned off just to have that direct comparison. And so I did that and the agent worked here for some time. And what I got after that was copilot now creates canvas. And what you'll see is if I open these additional tabs, you'll see that I have an installed extension. So these canvases are presented as extensions. So if I open this extension, it's exactly what I asked for. So I'm not having to worry about writing code to demonstrate a certain feature or have different ways to interact with my application. I can simply just have the agent do that for me and it loads it as a canvas as an extension. So right here on the copilot app you can see that from that simple prompt it was able to create this canvas. It's exactly what I asked for. So on the left side I have this um virtual file system isolation on and on the left side it's off. So I can simply just do exactly what I showed before. um on both sides. Again, if I create where I where I have the battle file system isolation mode turned off. If I create a new file, so let's create a new file here. Echo VFS is off. And then save that in uh Yeah, let's save that in our file test.txt. Now, if we do that, right, so you can see we have our test.txt file. But if I start a new session and I view the files in this directory, then the file is still accessible. But as you would guess, if I were to do the exact same thing on the left with my virtual file system isolation not turned on, then the agent will not have visibility on what I did in the previous session. So again, this was one of the cool things I saw last really really cool way that enables you to explore different modes of isolation as you're working with your different agents. Okay, I will pause there and see if everyone on the chat has shared something that they learned at build. Okay, scroll through the chats. Okay, we have a question. Let me just scroll through through and see if I missed anything. Okay, so for those who joined us um as we had started, we're just doing a quick recap of announcements last week at Microsoft Build that are related to GitHub. So if you learned something and you want to share with the community, please go ahead and share on the chat. What was your key takeaway at build last week? Um, so there's a question that I've seen here from you're asking, "What about rug pipes?" Um, good question. Um, I probably may a little bit more in terms of context. Um, just let me know what exactly you are referring to when you're asking about rag pipelines. Is it in the context of this session or this recap the copilot SDK or is it just a generic question regarding um retrieval augmented generation? So just give me some a bit more context to understand um exactly what you are referring to then I'll come back to the chat. Okay. So I'm waiting to see additional charts. What did what did what did you guys learn to build last week? Let me know. Let me know on the chat. I only have one screen so that's why we have this pleasant moment where I'm switching through my different tabs. Kindly bear with me. Uh so probably the other session that I can quickly highlight was one on GitHub agentic workflows. Now this is also fairly new but it's also fairly new and uh again this was a demo session. It was a short one but the whole idea is again just demonstrating how the field of automation is actually evolving to what is being called continuous AI. So instead of the traditional workflows that we know where you have to master YAML and you have to write your automations in YAML, you're now um being able to define your automations in natural language. So instead of saving a YAML file for your automation for your automations or for your automation pipelines, you're defining a markdown file and then you basically have an agent that spins up in its own ephemeral environment. It executes the task you have listed for it and then it's able to run this in that automated pipeline. So that's the whole idea behind this section. again. Let me just grab the link for you. It's accessible via the Microsoft build um website. I hope I saved it. Okay. Um yeah, I might not have saved it, but it is available via the Microsoft build agent. And this is the title for the session, GitHub agentic workflows. and they actually provided a practical exercise. So this is an exercise that you can even load right now or after this live stream. Um this is the link you can scan this QR code. It will direct you to GitHub. So it should take you to GitHub and allow you to have such a repository. Uh so it should allow you to have such a repository. Again, for me, I already completed the exercise, so for you to have a step-by-step guide in terms of what you need to do. But what I want to show you really quick here is that the demo itself is a website, a mono website. And I think I have some time to just show this. Um, so let's see if I can get it to start the application just so I can give you the right context for you to understand what's happening here should you choose to run the exercise on your own. So I'll just ask you to restart this stuff. Okay, but some bit of context is this is a single um this is a single repository. There's a website here, the Mona website. And this Mona website just has um information, just the latest announcements and news from GitHub. And so what this exercise allows you to create is if you go over to the GitHub folder. Um I have this workflows directory and then under workflows, you of course recognize the traditional YAML files that we are used to working with. But then you also see an MD file, right? So what's an MD file doing? Um what's an MD file doing in our workflows folder? So yeah, this is the the website and the agent has just opened it up in its own browser. So you can see it's it's just a site that pulls the latest information from the GitHub blog blog and just like splashes it all over on this on this page, right? So how we are achieving this is we have this markdown file which I'm just going to quickly talk through and you'll see it's a markdown file but then at the beginning we have this front matter. Allow me to peep through the charts. All right pretty allow me to come back to that question afterwards. So we have this markdown file at the top we have this section matter where we define the name for our workflow give it a description we are defining what this work should do and then in terms of the schedule this should this should run um uh every I believe it's every day at 9:17 a.m. And then in terms of the safe output, so this allows you to restrict what you want the agent to output. So the agent remember will run this workflow on its own without your intervention. It will just run this workflow on a on a schedule. But then you also want to have control over if I'm not directly watching the agent as it works in a way that I can in the right direction if it goes off then can I have a limit in terms of what this agent should be able to um submit as work done the definition of done. So in this case we're telling it that the safe outputs you should only be able to create a pull request in draft mode. So this means if this workflow runs whether I'm there or not, the agent won't go off and try and magic merging things into my repo or you know just doing some absurd stuff. It's going to adhere to what you have as the safe outputs. And then we're defining the list of pools that the agent should have access to as well as the allowed destinations for the network calls. So this gives you the um the the ability to define exactly the environment that you want this agent to work in the tools we want you to have access to and then right below that don't matter segment you then have in natural language then have your instructions for the agent. So this here again don't forget is an automation workflow where we're now telling the agent that hey you've now you now want to run this automation. It's part of a pipeline. So I want you to read uh these notes before you make any changes. These are the sources that I want you to refer to. And then my task for you is that I need you to update this other markdown um document with concise practical updates for readers and include source context when context comes from GitHub blog, GitHub change log or the awesome copilot workflows. And then once you do that, so in this case just pull the most recent context. I want you to open a pull request monitoring view. And then these are my instructions for the pull request. and do not write directly on main and you save that commit that on GitHub and then this agentic workflow will spin up every single day you'll have an agent the coding agent here um running in isolation completing this task for you so I did this yesterday just to test it out and you see that I have one pull request over here so I have a pull request over here and if you look at what has changed from the title the title of the pull request. You can see that the agent followed my instructions. It changed one file. So, it was able to upload that document which is used to feed the website with the most upto-date information. So, you can see this is very recent information June 10th that's just this week. So you can think of this a very practical scenario is you probably maintain um some learning some teaching material let's say for a course but the content there updates very frequently. So you can have an agent workflow that goes off, looks at the product documentation. If anything changes, it can be triggered to run. The agent is going to pull what's new, compare that with the current state of your of your course, and then it's going to just submit a PR with the updated content. So this makes um maintenance for documentation for courses, for any um learning material really really um easy. So that again was another key highlight for me at Build. Again, this is the session. If interested, go rewatch it. They had some really, really cool demos. Okay, so looks like uh we're just out of time. A few more people have joined. Again, we are doing a quick recap of Asterisk's Microsoft build announcements that are Git related. So that's just what we're kind of going through. So if you attended build last week on the chat before we sort of leave, let us know what did you learn from build last week? What was exciting? What was new that you like, hm, this is really really interesting. I'm going to try it out. So PR has a question. How do you handle semantic ambiguity when multiple chunks have similar embeddings? Okay. multiple chunks having similar embeddings. Let me just that question for a minute. And again, this is a community live stream. So in case you have more experience in this area and you'd like to respond to pretty just uh go ahead and do that. So how do you handle semantic ambiguity? when multiple chunks of similar embedding. Yeah, that's a it's a good question. I might not have the very best answer for you here. I apologize because I'm just trying to think of it practically um when when you're referring to multiple chunks having similar embedding. So my understanding here is that the embeddings need to be unique. There should be some sense of uniqueness when it comes to the embeddings of the different chunks. So at that point just trying to break down your question here. I'm trying to understand um you know how do we arrive at a scenario where we have multiple chunks. Let's say it's the same document. We have multiple chunks but they have similar embeddings. Okay. So, bear with me. I'm just trying to think out loud here. Yeah, because that's that's a good question. Um, pretty if you don't mind. Um, this is a very odd ask for live stream. Do you mind if we just take this offline because I don't think I have the perfect answer for you right now this minute. But I'm I'm happy to just dig deeper into it with you and probably just see if we can arrive at at a solution cuz I'm just trying to parse the question right now and um yeah I might not be able to give you the best answer uh for for this. So please feel free to shoot me a message on on LinkedIn and I'm happy to just have this discussion if need uh some uh subject matter experts of the same but it's a it's a good question. Thanks for bringing it up. All right. Um, our time is up actually, but I can probably just sneak in one recap. Um, so the last thing that I can probably share here is this last session um, GitHub copilot anywhere from remote controls to cloud sandboxes. Now again in just two minutes I will recap what this session was about. The whole idea is the reality is that you don't get your best ideas when you're sitting at your desk in front of your computer. You might get a really good idea um while you're out walking the dog or just out just away from your office or you've finally figured out how to fix a certain bug and you're away from your computer. So this allows you to remotely connect to your copilot CLI sessions. So if you are um working on a session in the copilot CLI, you can easily turn slash remote, right? So you can turn / remote on and what this will do remote controls. Okay, so it's it's disabled for my organization. Um, no need to worry there. But what that should do, if it's enabled for you, it's it should be enabled by default. If it's enabled for you, then you will be presented with this QR code. It's a QR code that you can scan on your mobile phone. If you have the GitHub app, you can continue with that session on transit away from your computer, connect to the agent, issue commands. If the agent has some questions back for you, you should be able to type in the responses. So, it's a really, really powerful feature that allows you to not just be restricted to sitting behind a computer to get your work done. You can direct and command your different agents from wherever it is you are. So, that was another good session. They had a really good demo around the FIFA World Cup application. So, again, in the spirit of this year's World Cup, you might want to check it. Check it out. And just like a sister of feature to that is the sandbox right so just as we've seen the slash remote you also have a slash sandbox right and again this is um the same idea where you can have an agent running locally complete some task but then you want to send this over to an agent a cloud agent for instance so you can enable sandbox It's going to create a cloud environment. It's you can think of it as giving the agent its own machine to work from and then you can connect to this machine from different devices, different services. And so the question that I had was what's then the difference between these two, right? What's the difference between sandbox remote? When should I use which? And so there was this really cool slide that just made it clear for me if I want to have some dependence on my local machine, my host computer. So that means I am running a session um that depends on my laptop being on and active then I can use the slash remote feature. So that means I can only connect to this session remotely as long as my host computer is running. But if I want to simulate an example where let's say I lose my computer, it it um gets destroyed or I'm completely offline, I still want to be able to access this session, then you should use a cloud sandbox instead. So that again was a key moment for me. I had that question before the session, but it was made very clear from that particular session. So again, it's a demo 305 from the build website. uh you should be able to rewatch the session and see the dems. All right, so I think that's it. I'm going to stop there for today's live stream. I was hoping this would have been more interactive with more of you sharing what you learned to build last year, but it's fine. No worries there. So, I hope this was useful. It was just my recap of the sessions I managed to join. But again, there are so many GitHub announcements that were announced last week. And of course, in the course of the coming weeks, we'll be seeing more demos being published. We have advocates just trying to make as many um resources as possible for you to kind of digest and break down all the different announcements we had from last week. So, with that, I will um yeah, we'll call it a day. I hope this was useful. I hope this was helpful. The comments are still on, so if you have any questions, feel free to come back on the comments. Um, and let me know if you have any questions, any comments, and uh, yeah, thanks for tuning in. Um, I hope to see you all next week. We run this every Thursday, so I hope to see you all. All right, thanks for your time. Bye-bye.