From Your Laptop to the Pipeline: Scaling Custom Agents with GitHub Copilot

0:01 [music] >> Hey everybody, thanks for coming. My name's Jose Palafox. I've been at GitHub for 6 and 1/2 years. So, I joined the team right after the Microsoft

0:21 acquisition of GitHub and then shortly after GitHub acquired a tool called Semmel. We made an acquisition of a security company. And so, my role at GitHub really has been growing our

0:30 security business for the last five or six years. In the last year, I really kind of focused on AI, but my role is to work in the field working with customers on how do they adopt our technology, how

0:42 to think about scaling our technology inside of their organization. So, today what we're going to talk about is really just like an introduction to agents on the platform and there's sort of two

0:52 different modes that I like to think of agents in. There's like autonomous agents that I have off running in the pipeline and then I have local agents that I'm using to do various bits of

1:01 work. So, I'm going to kind of walk you through sort of how to build those, how to think about them, how to think about scaling them, and think about different workflows that are possible using

1:10 agents. This talk is going to be fairly high-level. So, if you have additional questions afterwards, you want to chat, feel free to grab me. I'll kind of hang out right after the talk in the back of

1:19 the room. You can feel free to come by and chat with me afterwards. We can talk a little bit deeper about your use cases. This is a quick preview of just kind of things that are available on the

1:27 platform. Just getting us started, I always like to baseline with sort of the overall data flow of how Copilot works on the platform because a lot of people aren't familiar with how Copilot works

1:39 under the hood and and maybe aren't familiar with all of our different interfaces. So, just to give you a quick preview of what the product has, you've got a handful of different

1:47 interfaces that you can use to interact with the coding agent. You've got the IDE, you've got the GitHub CLI, which is sort of a lightweight interface that sits on your desktop. You can take any

1:57 session from the CLI and you can stream it. So, if you want to you know, close your laptop or walk away from your laptop for a period of time, you can either delegate the agent to

2:07 github.com and have it go run in the background or you can stream it using a command {slash} remote and it'll let you log in through your mobile device and actually steer the agent from your

2:17 mobile device. You've also got the SDK. So, if you want to create agents that live inside of Slack or inside of Teams, I'm exposed some individual functionality to a set of team members

2:28 that maybe don't have a GitHub license, you can do that pretty easily through the through the SDK. So, you can build applications using the CLI or the SDK. Regardless of what door you go through

2:39 on the top, you're going to hit this blue box here and this is what we call Cappy or the Copilot API service and this is also referred to as like the harness, right? This is the thing that

2:50 does all the difficult engineering tasks taking your input and chunking them and sending them to the models making sure that you're not repeating any content from open source

2:58 providers, dealing with authentication for you, dealing with metrics logging, dealing with audit logging, all of the kind of like to-dos of the infrastructure of the platform. And then

3:08 of course, once you send a message in, we take that and we pass it to the model providers. So, regardless of which door you go into, you hit the harness and then we take your output and we send it

3:18 to the model providers. Once we get the output back, we filter it and then display that back to you. So, that's sort of under the hood how the product works just so you kind of have like a

3:28 high-level understanding of the different doors you can go through and and where you can touch it. Now, if you're starting in the CLI for example, you have a handful of embedded

3:37 agents and I think it's useful to kind of look at the embedded agents just to understand what agents do because there's like a lot of different you know, potential ways that you could

3:47 implement whether it's an agent or a skill or you know, it all just ends up being marked down at the end of the day. So, it's useful to kind of see how um we're implementing agents in the

3:55 platform in a way that uh you can utilize. So, I just type {slash} agents, and all this does is drop up the um the default agents that are part of the CLI harness here. You can see I have a

4:06 handful of them, right? So, if I want to explore a code base, for example, I don't necessarily want to use the biggest model possible uh in order to do that. So, we have a specialized

4:16 research agent, which is our explorer agent, um that you can call or invoke uh through a keyword or actually invoking like the {slash} command um in in in the CLI, and it'll spin up, you know, a

4:27 small model using Haiku, um and go and investigate a code base, right? If you um you know, have a plan that you've done, right? And you've written out a planning document, and you want a

4:37 different model provider to come and audit the plan because it has different training data and different model weighting, uh then fine, you can do that. Rubber duck is like a embedded

4:46 agent that will validate a plan that we know was written by Opus with, you know, a pass from GPT or something like that. Um you can see in all of these models they specify or in all of these agents

4:56 they specify the model, and that's one of the options that you have when you're building custom agents. You can always control the model that you're using, and then you control the instructions that

5:04 you're giving it. So, if these model or these um agents aren't doing, you know, something that you need done, right? If you have a specific task or a review or you have a compliance or um regulatory

5:15 requirement that you have to meet, and maybe you have a tool that you want to run or um a series of checks that you want to have that are custom to you. May maybe you want to write an agent. And

5:24 you know, if you uh want, you can you can just use the agent command here, and it will um set you through like a a work uh a workflow to add an agent into your your

5:34 CLI environment. So, here I'm getting to pick, you know, do I want this on the project level like in the Git project that I'm working on, or do I want this as like a um

5:44 an agent that's available regardless of which project I'm working on at the user level, right? Um so, maybe I'll say I'm out of that at the at the org level or at my my my individual user level.

5:54 And then I go ahead and create this with Copilot. Copilot will do all the scaffolding for me. So, um if I uh want, I can generate an agent that maybe uh you know, looks at the GitHub

6:04 change log and it um you know, will summarize all of the latest features or something that that Copilot did. So, I did that earlier today and just generated a sample agent, you know,

6:14 using this uh agent builder that's built into the platform, right? And this is available in all of the interfaces. Um you know, if you have the IDE, you have an agents

6:22 interface there as well that will do the same kind of build build process with you. But, what's nice is it scaffolds everything out. So, from like a basic one-line prompt that just says, "Hey, I

6:30 want to go to the change log and summarize all the changes." It'll write the description for me. It'll format all the front matter. It will um structure success criteria. It'll take an attempt

6:39 at structuring methodology. Like, it kind of knows how to write these files. So, you get to be uh you know, somewhat lazy with it, right? You you you just write a general

6:47 description of what you want to get done. We'll fill in all the specifics for you. You can of course come in here and edit all of this, right? So, if you don't like uh the order that it's um

6:56 picking, you know, sources in this case, um we could change that, right? Like, this one wants to start with, you know, use the GitHub roadmap, but maybe you want it just to jump straight to the

7:05 change log, so you're not getting roadmap items. You know, you can just edit it here, right? There's no no big deal. But, this does all the scaffolding work for you.

7:12 What's nice now is you've created like an agent that works in the harness. So, if you have repeat tasks that you have to do, you can call this agent to do those tasks for you, right? Um that

7:21 that's kind of step one. Uh but, once you do that, you're kind of like, "What's the next thing that I got to go do?" And I think um you know, the next thing is how do I share this agent,

7:30 right? How do other people uh take advantage of it? And the easiest way to do that inside of Copilot is to do that um by making a marketplace. So, a marketplace is just a repository with a

7:42 little bit of extra uh JSON in one of the directories that says, "Hey, this is a marketplace." And what it does is it gives you some light package management capabilities inside the repo. So, if I

7:52 subscribe to a marketplace, then I can update all the agents simultaneously. I can version them, things like that. I can notify people of security vulnerabilities. You know, there's

8:01 features built in that allow me to communicate with the users that are downstream for me. So, creating a marketplace is oftentimes one of the first things that I work with companies

8:09 on when I go in and try to talk with them about how to scale Copilot adoption inside their organization. A lot of times there's not a central repository for teams to even contribute agents or

8:18 skills to. So, if you don't have a central location, you should generate one, right? And there is a capability basically to sync those with the the local client device and then pushing and

8:29 out different agents. You can also use a specific directory inside of your organization or specific repo. So, if you're inside of GitHub, I'm at the org level here, and then I

8:41 went into a repository, and it has to be named GitHub private, right? This is a naming convention that we've used, but if you have a GitHub private repository, you'll be able to expose agent files.

8:52 So, in this case, I have three agents here, and you can see from the cloud agent, I'm actually able to call that specific agent on the platform. So, I showed you earlier in the diagram, you

9:03 know, you can you can interact with all of these from different surface areas. This is the cloud interaction, right? If I want to delegate to a cloud agent that's hosted on the platform, I can do

9:11 that here. But what's nice is this compliance bot that I'm showing you here in the the drop-down is the same compliance bot that's in the repository, right? So, this is a way of distributing

9:21 agents out to the team, right? So, if I write a handy agent that checks the change log for me, then I can publish it here, and I can share that with everybody else, right? So, this will

9:31 push to everyone's IDE environment or push to their CLI environment for them, and then they can just call the same agent that I'm working on. So, now I have some reuse, right? Like I can

9:40 publish them in a marketplace, I can publish them directly as um assets inside of my business that anybody can call, right? And this is what's allowing me to do standardization, right? If you

9:50 look at the cost model for all of these products, the cheapest way to use them is to get cash hits, right? You want exact matches between turns on common data. And having reusable components

10:01 will drive up your cash rate, right? So, if cost is a concern, um building reusable agents and making sure that people are solving problems in the same way, uh rather than reinventing the

10:11 wheel every time, is a good way to drive down your your overall bill, drive up your cash rate. So, again, this um dot GitHub private directory, this is how you would share

10:20 an agent internally to everyone inside the org, right? So, you can make a marketplace that will work across organizations, that could even work, you know, externally, right? So, we have a

10:29 repository called awesome co-pilot that has a bunch of um you know, example agents and things. You could register that as a marketplace. This is purely internal, right? And this is like an

10:38 admin can push this out. The last thing that I want to do sometimes um when I'm working uh with an agent is I want to be able to use um agents across repositories. And the

10:50 biggest challenge with these uh compliance agents, for example, is that they're always starting in the repo where the agent lives. So, if I have agents living in this repository, um

11:02 they maybe can't take action in other repositories, right? I need to start the agent in the other repo so that it has permissions in that repository. Um inside of the co-pilot app, there's a

11:13 command called orchestrate. Um and orchestrate is our horizontal scaling for across repo. Uh so, this will allow you to set a series of GitHub issues as uh goals for the agent, and then spin up

11:25 sub agents to address all of those tasks. But, what's nice is that it will spin up agents in the repository that it's supposed to be working in. So, if you want to take a task inside of a

11:35 microservice where you're like modifying an API and then you have to make a change somewhere downstream because of that, Orchestrate will allow you to set up several agents that are going to make

11:44 cross-repo changes simultaneously. So, I can use the the pre-canned agents, right? If they're available to me in those other marketplaces or being pushed to me by my org admin, I can kind of

11:55 summon them here to go do work in individual repositories and keep them sort of on task using this this Orchestrate tool. And that's really like three layers of how do I use agents

12:05 locally, right? Like in in using agents locally has a lot of utility, right? But sometimes I don't want to run an agent locally. I actually want the agent to be run as a part of the repository and

12:18 certain agents maybe are going to be performing like maintenance tasks in the repo. And so, I want to run them in the repo on that repo's budget, not on my budget, right? Or I want to run it using

12:29 the repo identity, not my identity, right? Not every agent needs to be me taking an action. You know, it's it's maybe a maintenance task that has to be done on behalf of of the project. When

12:40 we're working in that model, we have a framework that you can use called agentic workflows. And agentic workflows is a pretty simple concept like the Copilot CLI can be used

12:51 in a headless mode. So, I can call the Copilot CLI, I can use the dash P command and basically pass it a single prompt one-shot prompt for it to go do. And then if I take that and I run that

13:02 inside of a GitHub Actions runner or in some CI system, then I have an agent that's running in a pipeline for me, right? So, I can trigger it on events that are happening in the repo. Like on

13:11 a release, I want to update I want to update documentation. Or every week, I want to update my context files. Or, you know, in maybe a model like this, I have various maintenance tasks

13:21 that I want to go do. Like one of the biggest problems today that's happening in repositories where a lot of agentic development is happening is there's lots of spaghetti code getting added, lots of

13:30 duplicate code. Like the agents are lazy about implementing, you know, functions and they're really lazy about namespacing. So, they'll just like create constant duplication inside the

13:40 code base. So, maybe you want an agent that looks inside the code base, identifies opportunities for deduplication of code, and then creates a series of issues for

13:51 you. And if you use this framework, this agentic workflows framework, what's nice is we'll we'll build in human in the loop triggers for you so that you can review and decide when you're actually

14:02 going to spend money on side of the next phase of the flow. So, in this flow here, you see I have the first agent maybe running on a cron schedule. It's looking in the repo. It identifies, you

14:11 know, three items where there's opportunity for me to make improvement in the code base. Okay, great. The developer reads that and then makes a decision about whether or not those

14:20 things are worth fixing. And they express that through a slash command that they can make as an issue comment, right? So, they they go to the issue and they say, "Okay, advance this issue to

14:29 the next phase of the process, right?" For us, that's maybe a planning phase, right? So, maybe I'm going to call another pipeline agent, right? Which is the PRD generating product manager

14:39 agent, right? That's going to scope the feature for me. It generates a plan. It hands it off to co-pilot in the platform for implementation. And then the developer comes back in the loop maybe

14:48 at an acceptance phase, right? Let's look at the code and evaluate whether or not we actually want to take it in the project. Now I've got pipeline agents. And what's really cool about the

14:57 pipeline agents is how they scale. You know, the the the the challenge with working locally is you're on like a single session or you're on your device. If your device goes down or you lose

15:08 network activity, you know, your your workflow is interrupted. These are running in the platform, so they're running autonomously from you. If you want to see like a maximalist

15:17 approach to how this works, the GitHub AW project itself, like the thing that is the framework for building all these agents, it is built entirely by agents. And this team has sort of an internal

15:28 goal that they're only going to do their development on their mobile devices because they interact entirely with this application through those slash commands, right? So just to give you a

15:37 feel of like what a fully, you know, agent-led development project looks like, this is this is our our our framework, right? And it has I don't know,

15:47 200 agents in here that are all running different parts of the pipeline, right? And all of these follow a similar workflow that we just showed on that on that slide, right? That architecture is

15:59 reusable. So let me see if I can just pick one of these. I'm a little bit picking at random here, but let's see what this one does, right? So

16:07 this is checking daily reports on other agents, right? So this is a meta agent that's looking on things. It's running on a daily schedule and it has, you know, its

16:17 agent.md file that's working away here, right? So every time this thing runs, it's generating some markdown report or some action or input for another agent, and then we're just continuing to

16:27 trigger it. You can feel free to take a look through here. There's hundreds of these that are creating this project. GetHub also has a bunch of them that we've bundled up. So

16:37 inside of our GetHub next organization, there's this project called Agentics. Agentics has 30 or so different pipeline agents that you may be interested in just pulling off the shelf and running

16:46 in your project. Some of these will do the code deduplication that we talked about. Some of them are different types of reviewers, so if you need a QA reviewer or,

16:56 you know, you want one that's funny and just makes jokes, like there's all kinds of different sample agents here that you can pull and drop into the pipeline. But what's nice about this is it gets the

17:05 workload off of your machine. And I think when we shift back to thinking about cost, getting the workload off of your machine is key for optimizing cost, right? If I'm having everyone in my

17:15 organization work with AI and I'm telling them to go use it, but I can't see how they're actually working with the tool. I don't have any opportunity to optimize, right? I can't actually see

17:26 whether or not the agents that they're using are too verbose or are even achieving the task. I can't tell when tool calls are happening if they're successful or unsuccessful. I I I can't

17:37 tell if they're using agent reasoning for all types of things or if they're you know correctly building little bash scripts to actually go and do uh different search functions and things

17:46 like that. Like there's lots of optimization opportunities for me, but if I can't see it, I can't do any of that optimization. So, by getting the workload off of the laptop and moving it

17:55 into CI, I get to see what's happening, right? I have every single agent running and it's instrumented with hotel. So, I can go to a SIM or some kind of logging platform and look, does my code

18:07 duplication agent agent, how does it run across repositories? How much does it cost me, right? I can pivot on average token use. I can also do things like say, "Hey, every time that an agent

18:18 exceeds its P90 for what I expect it to cost me to run, go investigate why it exceeded its its threshold, right? I want it to tell me what debugging information I can I can take to

18:30 evaluate it further or to improve it, right? Or if I see that a tool call's failing over and over, maybe I want to AB test different front matter or maybe I want to AB test different models and

18:39 see if they produce like the the right output for me so I can pick a cheaper model at some point, right? All of this stuff is possible once I get the agents into the pipeline.

18:50 Anyhow, so this was a quick and dirty kind of tour of agents in the platform, right? We talked through building an agent locally, sharing agents through the platform, and then eventually moving

19:00 those agents into the pipeline. If you want to talk more about any part of that, I'll be in the back. Feel free to come up and grab me or you can add me on LinkedIn and ping me. I'm happy to

19:09 continue the conversation. Um, I work at GitHub in a field capacity, so if you know your GitHub AE and you want to chat with me, uh, feel free to reach out with them. Uh, we we can get in touch and and

19:18 have a quick conversation as well. Thanks so much for your time today.