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

Hey, everybody. Thanks for coming. Uh, my name's Jose Palafox. I've been at GitHub for six and a half years. So I joined the team, uh, right after the Microsoft acquisition of GitHub, and then, uh, shortly after, GitHub acquired a tool called Semmle. We, we made an acquisition of a security company. And so my role at GitHub really has been growing our security business for the last, uh, five or six years. Um, in the last year, I've really kind of focused on AI, but my role is to work in the field, um, working with customers on how do they adopt our technology, how to think

about, um, scaling our technology inside of their organization. So, um, today, what we're gonna talk about is really just like an introduction to agents on the platform, and there's sort of, uh, two 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, uh, to do various bits of work. Um, so I'm gonna kinda walk you through sort of how to build those, how to think about them, how to think about scaling them, um, think about different workflows that are possible using agents. Um, this talk is gonna be

fairly high level, so if you have additional questions afterwards, you wanna chat, feel free to grab me. I'll kinda hang out, uh, right after the talk in the back of the room. You can feel free to come by and, uh, 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 platform. Just getting us started, um, I always like to baseline with sort of the overall data flow of how Copilot works on the platform because, um, a lot of people aren't familiar with how, uh, Copilot works under the hood and, and maybe aren't familiar with all of our different interfaces.

So, um, just to give you a quick preview of what the product has, um, you've got a handful of different interfaces that you can use to interact with the coding agent. Um, you've got the IDE. You've got the GitHub CLI, which is sort of a lightweight interface that sits on your desktop. Um, you can take any session from the CLI, and you can stream it. So if you want to, um, you know, close your laptop or walk away from your laptop for a period of time, you can either delegate the agent to github.com and have it go run in the background, or you can stream it using a command,

/remote, and it'll let you log in through your mobile device and actually steer the agent, uh, from your mobile device. Um, you've also got, uh, the SDK. So if you wanna create agents that live inside of Slack or inside of Teams, um, expose some individual functionality to a set of team members 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, uh, or the SDK. Um, regardless of what door you go through on the top, you're gonna hit this blue

box here, and this is what we call CAPIR, the Copilot API service. And, um, this is also referred to as like the harness, right? This is the thing that does all the, uh, difficult engineering tasks, taking your input and chunking them and sending them to the models, making sure that you're not, um, repeating any content from open source providers, uh, dealing with authentication for you, dealing with metrics logging, dealing with audit logging, all of the kinda like to-dos of the infrastructure of the platform. And then, of course, once you send a message in, we take that, and we pass it

to the model provider. So, um, regardless of which door you go into, you hit the harness, and then we take, uh, your output, and we send it to the model providers. Um, 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 kinda have like a high-level, um, understanding of the different doors you can go through and, and where you can touch it. Um, now if you're starting in the CLI, for example, you have a handful of embedded agents, and I think it's useful to kinda look at the embedded agents, um, just to

understand what agents do because there's like a lot of different, uh, you know, potential ways that you can implement, whether it's an agent or a skill or, you know, it all just ends up being Markdown at the end of the day. So it's useful to kinda see how, um, we're implementing agents in the platform in a way that, uh, you can utilize. So I just type /agents, and all this does is drop up the, um, the default agents that are a part of the CLI harness here. You can see I have a handful of them, right? So if I wanna explore a code base, for example, I don't necessarily

wanna use the biggest model possible, uh, in order to do that. So we have a specialized research agent, which is our Explore 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 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 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 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 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 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, uh, regulatory requirement that you have to meet and maybe you have a tool that you wanna run or, um, a series of checks that you wanna have that are custom to you, may- maybe you wanna write an agent. And, 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 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, 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 at it at, at the, at the org level or at my, my, my individual user level. 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 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, 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 agent's 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 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 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 just write a general 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, 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 wanted just to jump straight to the 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. 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, 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, 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 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, um, if I 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 features built in that allow me to communicate with the users that are downstream from me. So creating a marketplace is oftentimes one of the first things that I work with companies on when I go in and try to

talk with them about how to scale Copilot adoption inside their organization. Um, a lot of times there's not a central repository for teams to even contribute agents or skills to. So if you don't have a central location, uh, you, you should generate one, right? And there is a capability basically to, um, sync those with the, uh, the local client device and then push in and out different agents. Um, you can also use a specific directory inside of, um, your organization or a specific repo. So i- if you're inside of GitHub, I'm at the

org level here, and then I went into a repository, and it has to be named .githubprivate, right? This is a naming convention that we've used. But if you have a .githubprivate repository, um, you'll be able to expose agent files. So in this case, I have three agents here. And you can see from the cloud agent, um, I'm actually able to call that specific agent on the platform. So I showed you earlier in the diagram, uh, you 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 that here. But what's nice is this compliance bot that I'm showing you here in the, the dropdown is the same compliance bot that's in the repository, right? So this is a way of, uh, distributing 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, um, this will 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

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 look at the cost model for all of these products, the cheapest way to use them is to get cache hits, right? You want exact matches between turns on common data. And having reusable components will drive up your cache 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 wheel every time, it's a good way to drive down your, your overall bill, drive up your cache rate. So again, this, um, .githubprivate directory, this is how you would share 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 repository called Awesome Copilot 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 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, I want to be able to use, um, agents across repositories. And the 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, they maybe can't take action in other repositories, right? I need to actually start the agent in the other repo so that it has permissions in that repository. Um, inside of

the Copilot app, there's a command called Orchestrate. Um, and Orchestrate is our horizontal scaling for cross-repo. Uh, so this will allow you to set a series of GitHub issues as, uh, goals for the agent and then spin up 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 a 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 gonna make, uh, cross-repo changes simultaneously. So I can use the, um, the pre-canned agents, right, if they're available to me in those other, uh, marketplaces or being pushed to me by my org admin. I can kind of 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 locally, right? Like, and, and using agents locally has a lot of utility, right? Um, but,

uh, sometimes I don't wanna run an agent locally. I actually want the agent to be run as a part of the repository, and certain agents maybe are gonna be performing, like, maintenance tasks in the repo. And so I wanna run them, um, in the repo, uh, on that repo's budget, not on my budget, right? Or I wanna run it using the repo identity, not my identity, right? Not every agent needs to be me taking an action. Um, you know, it's, it's maybe a maintenance task that has to be done on behalf of, of the project. Um, when 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 in a headless mode. So I can call the Copilot CLI, I can use the -p command and basically pass it a single, uh, prompt, a one-shot prompt for it to go do. And then if I take that and I run that 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 a release, I wanna update, um, I wanna update documentation, or every week I wanna update my context files, or, you know. In maybe a model like this, I have various maintenance tasks that I wanna 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 duplicate code. Like, the agents are lazy about, um, implementing, you know, uh, functions, and they're really lazy about namespacing, so they'll just, like, create constant duplication inside the code base.

So maybe you want an agent that, uh, looks inside the code base, um, identifies opportunities for, uh, deduplication of code, and then creates a series of issues for 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, um, decide when you're actually gonna spend money on sort 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 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 things are worth fixing, and they express that through a slash command that they can, um, make as an issue comment, right? So they, they go to the issue and they say, "Okay, advance this issue to the next phase of the process," right? For us, that's maybe a planning phase, right? So maybe I'm gonna call another pipeline agent, right, which is the PRD-generating product manager agent, right, that's gonna scope the

feature for me. It generates a plan. It hands it off to Copilot in the platform for implementation, and then the developer comes back in the loop maybe at an acceptance phase, right? Let's look at the code and evaluate whether or not we actually wanna take it in the project. Um, now I've got pipeline agents, and what's really cool about the pipeline agents is how they scale. Um, 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, uh, or you lose network activity, you know, your, your workflow is

interrupted. These are running in the platform, so, uh, they're running autonomously from you. If you wanna see, like, a maximalist approach to how this works, the GitHub AW project itself, like the thing that, um, is the framework for building all these agents, it is built entirely by agents, and this team has sort of an internal goal that they're only gonna do their development on their mobile devices because they interact entirely with this application, uh, through those slash commands, right? Um, so just to give you a feel of, like, what a fully, you know, agent-led development

project looks like, this is, this is our, uh, our, our framework, right? And it has, I don't know, 200 agents in here that are all running different parts of the pipeline, right? Um, and all of these follow, uh, a similar, uh, workflow that we just showed on that, um, on that slide, right? That architecture is reusable. So, um, let me see if I can just pick one of these. I, I'm a little bit picking at random here, but, um, let's see what this one does, right? So this is, uh, 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 agentmd file that's working away here, right? So every time, uh, this thing runs, it's generating some markdown report or some action or input for another agent, and then we're just continuing to trigger it. Um, you can feel free to take a look through here. There's hundreds of these that are creating this project. GitHub also has, um, a bunch of them that we've bundled up. So inside of our GitHub 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 in your project. Um, some of these will do the code deduplication that we talked about. Um, some of them are different types of reviewers. So if you need a QA reviewer or, um, you know, you want one that's funny and just makes jokes, like, there's all kinds of, uh, different sample agents here that you can pull and drop into the pipeline. But what's nice about this is it gets the workload off of your machine, and I think when we shift back to thinking about cost, um,

getting the workload off of your machine is key for optimizing cost, right? If I'm, uh, having everyone in my organization, uh, 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, um, 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. Um, I, I, I can't tell if they're using agent reasoning for all types of

things or if they're, um, you know, cor- correctly, uh, building little bash scripts to actually go and do, uh, different search functions and things 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 into CI, I get to see what's happening, right? I have every single agent running, uh, and it's instrumented with OTel, so I can go to a SIM or some kind of logging platform and look. Does my code deduplication agen- 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 exceeds its P90 for what I expect it to cost me to run, uh, go investigate why it exceeded its, i- its threshold," right? I want it to tell me, uh, what debugging information I can, I can take to, um, to evaluate it further and improve it, right? Or if I see that a tool call's failing over and over, maybe I wanna A/B test different front matter, or maybe I wanna A/B test different models and

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. Anyhow, so this was a quick and dirty kinda tour of agents in the platform, right? We talked through, um, building an agent locally, sharing agents through the platform, and then eventually moving those agents into the pipeline. Um, if you wanna talk more about any part of that, I'll be in the back. Feel free to come up and grab me, or, um, you can add me on LinkedIn and, and ping me. I'm happy

to continue the conversation. Um, I work at GitHub in a field capacity, so if you know your GitHub AE and you wanna chat with me, uh, feel free to reach out with them. Uh, we, we can get in touch and, and have a quick conversation as well. Thanks so much for your time today.