Talk by Jose Palafox, Field Copilot Specialist at GitHub, on moving a custom AI agent from a single local setup to organization-wide sharing and unattended use in CI pipelines. Covers how GitHub Copilot works, the built-in agents in the Copilot CLI, building and editing custom agents, sharing agents through a marketplace, running agents across repositories with Orchestrate, and GitHub Agentic Workflows, which run headless Copilot CLI in GitHub Actions and can be triggered from issues. The description also mentions a repository with about 200 agents and agents that monitor their own cost overruns. Recorded at the AI Engineer World's Fair 2026. # Video Identity Observations: "From Your Laptop to the Pipeline: Scaling Custom Agents with GitHub Copilot" ## Speaker & Role Context (Explicit Self-Description) - **Speaker identity**: Jose Palafox, GitHub employee — *"My name's Jose Palafox. I've been at GitHub for 6 and 1/2 years."* - **Role claim**: Field-facing customer enablement — *"my role is to work in the field working with customers on how do they adopt our technology, how to think about scaling our technology inside of their organization."* - **Background**: Security business focus for ~5–6 years, shifted to AI in the last year. ## Intended Audience - **Enterprise/organizational adopters rather than hobbyists**, evidenced by repeated organizational framing: - *"how to scale Copilot adoption inside their organization"* - *"This will push to everyone's IDE environment or push to their CLI environment"* - Cost-optimization framed at the org level: *"If cost is a concern... drive down your overall bill, drive up your cash rate."* - **Developer-facing practitioners**: hands-on CLI, `/agents`, front matter, CI workflows, and observability ("otel", "SIM", "P90") content assumes technical viewers. - **In-person conference audience plus follow-up accessibility**: *"This talk is going to be fairly high-level. So, if you have additional questions afterwards... feel free to grab me"* and *"you can add me on LinkedIn and ping me."* ## Claimed Scope - **Explicit scope statement**: *"an introduction to agents on the platform"* with two modes — *"autonomous agents that I have off running in the pipeline and... local agents."* - **Deliberately introductory framing**: *"This talk is going to be fairly high-level."* - **Three-part arc stated at the end**: *"building an agent locally, sharing agents through the platform, and then eventually moving those agents into the pipeline."* ## Observable Presentation Patterns - **Product-tour demonstration style**: live walkthroughs of CLI commands (`/agents`, `/remote`, `-p` flag), agent scaffolding via the built-in builder, and the `.github-private` repository distribution convention. - **Enterprise pain-point orientation**: centralization (*"A lot of times there's not a central repository for teams to even contribute agents"*), governance (*"compliance or regulatory requirement"*), observability (*"I can't see how they're actually working with the tool... if I can't see it, I can't do any of that optimization"*). - **Vendor credibility signaling via dogfooding**: *"the GitHub AW project itself... is built entirely by agents"* with a team that *"only [does] their development on their mobile devices."* - **Resource pointing**: references to `awesome-copilot` and the "Agentics" project (~30 pipeline agents) as off-the-shelf starting points. ## Claims vs. Demonstrated - **Creator claims**: his role in scaling adoption, the cost/cache-rate economics argument, and the maximalist agent-led development example. - **Demonstrated by the material itself**: the scaffolding workflow, marketplace/package-management mechanics, `orchestrate` cross-repo behavior, and human-in-the-loop pipeline triggers (subject to transcript fidelity, e.g., likely "Semmle" and "cache hits" transcription variants). # Delivery Observations: "From Your Laptop to the Pipeline: Scaling Custom Agents with GitHub Copilot" > **Evidence basis:** These observations come only from the transcript. Pitch, pacing, and vocal emphasis cannot be assessed, so tone is described through word choice and sentence construction. --- ## 1. Register and Tone (Lexical) - **Conversational and informal.** The speaker addresses the audience directly and uses contractions and casual phrasing throughout. > "Hey everybody, thanks for coming." - **Plain-spoken framing of technical material.** Complex concepts are described in everyday terms. > "it all just ends up being marked down at the end of the day." - **Light humor.** Humor appears in asides rather than in set pieces. > "So, you get to be uh you know, somewhat lazy with it, right?" > "you want one that's funny and just makes jokes" --- ## 2. Recurring Verbal Patterns ### 2.1 Tag questions ("right?") The most recognizable pattern is the tag **"right?"**, which appears in many sentences, often at clause ends. It functions as a check-in with the listener. - > "You can see I have a handful of them, right?" - > "Like, it kind of knows how to write these files." - > "So, if you don't have a central location, you should generate one, right?" ### 2.2 Hedging and filler Filler words such as **"um," "uh," "like," "kind of," "sort of,"** and **"you know"** appear frequently, especially in longer explanatory stretches. - > "So, I just type {slash} agents, and all this does is drop up the um the default agents" - > "kind of like to-dos of the infrastructure of the platform" Repeated words also appear, such as "you you you" and "no no big deal." > "You you you just write a general description of what you want to get done." > "There's no no big deal." ### 2.3 Sentence-opening discourse markers Sentences frequently begin with **"So,"**, **"And,"**, or **"Okay,"** to mark transitions. - > "So, today what we're going to talk about is really just like an introduction to agents on the platform" - > "And then of course, once you send a message in, we take that and we pass it to the model providers." - > "Okay, great. The developer reads that and then makes a decision" --- ## 3. Recurring Phrases | Phrase | Observed function | Example | |---|---|---| | "feel free to" | Inviting follow-up | "feel free to grab me" | | "high-level" | Setting scope | "This talk is going to be fairly high-level." | | "quick and dirty" | Framing a summary | "this was a quick and dirty kind of tour of agents in the platform" | | "the next thing" | Sequencing | "the next thing is how do I share this agent" | | "that's really like [N] layers" | Summarizing structure | "And that's really like three layers of how do I use agents locally" | | "cost" / "cash hits" | Returning to a theme | "the cheapest way to use them is to get cash hits, right?" | --- ## 4. Teaching and Explanation Habits ### 4.1 Establishing a baseline first The speaker states a plan to build context before explaining the main content. > "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 under the hood" ### 4.2 Explicit signposting and scope-setting The speaker tells the audience what the talk will and will not cover. > "there's sort of two different modes that I like to think of agents in." > "This talk is going to be fairly high-level." ### 4.3 Live demonstration with narration Demonstrations are narrated as they happen, with the speaker describing actions and reasoning. > "So, I just type {slash} agents, and all this does is drop up..." > "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?" ### 4.4 Analogies and reframing Concepts are often compared to familiar things or restated in simpler terms. > "Rubber duck is like a embedded agent that will validate a plan" > "it all just ends up being marked down at the end of the day." ### 4.5 Reasoning through problems and tradeoffs The speaker frequently frames a problem and then explains the reason behind a recommendation. > "The biggest challenge with these uh compliance agents, for example, is that they're always starting in the repo where the agent lives." > "If I can't see it, I can't do any of that optimization." ### 4.6 Recap and closing The talk ends with a summary and an open invitation. > "We talked through building an agent locally, sharing agents through the platform, and then eventually moving those agents into the pipeline." > "Thanks so much for your time today." --- ## 5. Stable Patterns vs. Isolated Moments **Stable-looking patterns (repeated across the transcript):** - Tag "right?" and filler words - Signposting at the start of sections ("So, today…", "And that's really like…") - Inviting questions ("feel free to…") - Return to cost as a theme **Isolated moments (appear once or twice):** - Self-deprecating or hedged remarks: "I'm a little bit picking at random here" - Humor about agent laziness and comedic sample agents - Specific quantities such as "I don't know, 200 agents in here" --- ## 6. Hedging and Uncertainty - **Scope hedging** is explicit: the talk is described as "fairly high-level," and the speaker says they are giving "a quick and dirty" tour. - **Numerical hedging** appears in "I don't know, 200 agents," signaling an approximate figure. - **Speaker uncertainty about the audience** is implied by offers to continue conversation afterward, though no direct statement about audience knowledge is made. --- ## 7. Limitations - Only the transcript is available, so **vocal delivery (pitch, pace, volume, emphasis)** cannot be assessed. - Filler and tag frequencies are **qualitative**. Exact counts are not provided, and the transcript formatting may affect how some repetitions appear. - Patterns are described from a single talk. Repetition across other talks would be needed to confirm stability. # From Your Laptop to the Pipeline: Scaling Custom Agents with GitHub Copilot **Speaker:** Jose Palafox (GitHub, field role focused on customer adoption; ~6.5 years at GitHub, background in growing GitHub's security business, last year focused on AI) **Scope:** Introduction-level tour of agents on the GitHub Copilot platform — local agents, agent sharing/distribution, and pipeline (autonomous) agents. Speaker explicitly notes the talk is "fairly high-level" and offers deeper discussion afterward. --- ## 1. Copilot Platform Architecture (as described) Palafox presents an under-the-hood data flow for how Copilot works: - **Multiple interfaces** to reach the coding agent: - **IDE** - **GitHub CLI** — lightweight desktop interface; sessions can be delegated to github.com to run in the background, or streamed via a `/remote` command allowing the agent to be steered from a mobile device - **SDK** — for embedding agents in Slack or Teams, or exposing functionality to users without a GitHub license - All interfaces route into what he calls **"Cappy" / the Copilot API service / "the harness"**, which handles: - Chunking input and sending it to models - Avoiding repetition of open-source content - Authentication, metrics logging, audit logging - The harness forwards input to **model providers**, filters the output, and displays it back to the user. --- ## 2. Local Agents in the CLI ### Embedded agents as reference implementations - Typing `/agents` lists default agents bundled with the CLI harness. He argues it's useful to study them because "it all just ends up being markdown at the end of the day," despite debates about agents vs. skills. - **Explorer agent:** a specialized research agent that uses a small model (**Haiku**) to investigate a codebase, avoiding the biggest model for exploration tasks. - **Rubber duck:** an embedded agent that validates a plan written by one model (e.g., **Opus**) using a different model provider (e.g., **GPT**), reasoning that different providers have different training data and model weightings. ### Building custom agents - Key design options when writing an agent: **specify the model** and **specify the instructions**. - Custom agents suit cases like specific tasks, reviews, or **compliance/regulatory requirements** requiring custom tools or checks. - The `/agent` command walks through a workflow: choose **project-level** vs. **user-level** scope; Copilot performs scaffolding. - The **agent builder** scaffolds from a one-line prompt: writes the description, formats front matter, structures success criteria and methodology. The user can edit anything (e.g., changing source order so it goes straight to the changelog rather than the roadmap). He characterizes this as letting users "be somewhat lazy." --- ## 3. Sharing and Distributing Agents ### Marketplaces - A **marketplace** is "just a repository with a little bit of extra JSON" enabling light package management. - Benefits claimed: subscribe and update all agents simultaneously, version them, notify downstream users of security vulnerabilities. - He states that creating a marketplace is often one of the **first things he works on with companies** when advising on scaling Copilot adoption, because many lack a central repository for teams to contribute agents or skills. ### `.github/private` org repository - A repo named **"github private"** (described as a naming convention) exposes agent files at the org level. - Agents published there (e.g., a compliance bot shown in the demo) appear in the cloud agent drop-down — the same bot across surfaces — pushing to everyone's IDE or CLI environment. - He frames this as enabling **standardization** and **reuse**. ### Cost argument for reuse - The cheapest usage pattern is **cache hits** (exact matches between turns on common data). - Reusable components drive up cache rate; solving problems the same way "rather than reinventing the wheel" drives down overall cost. - Cross-org or even external marketplaces are possible (e.g., the **awesome-copilot** repository as a registerable marketplace); the org-pushed approach is purely internal and admin-driven. ### Cross-repo orchestration - **Problem:** agents typically start in the repo where they live and may lack permissions to act in other repositories. - **Solution:** the **`orchestrate`** command in the Copilot app — sets a series of GitHub issues as goals and spins up **sub-agents in the repos where the work belongs**, enabling simultaneous cross-repo changes (e.g., an API change in a microservice plus downstream changes). --- ## 4. Pipeline (Autonomous) Agents ### Motivation - Some agents should run **on the repo's budget and identity**, not the individual user's (e.g., maintenance tasks done on behalf of the project). - Local agents are fragile: tied to a single session/device; network loss interrupts the workflow. ### The agentic workflows framework - Copilot CLI has a **headless mode** (`-p` flag passing a one-shot prompt); run inside **GitHub Actions or any CI system**, this becomes a pipeline agent triggered on repo events (e.g., on release, update documentation; weekly context-file updates). - **Example use case he highlights:** agentic development is producing "spaghetti code," "duplicate code," and agents that are "lazy about... namespacing" — so an agent can scan the codebase for deduplication opportunities and create issues. - **Human-in-the-loop triggers** are built in: a developer reviews agent output and advances via a **slash-command issue comment** (e.g., advancing to a planning phase with a "PRD-generating product manager agent," then handoff to Copilot for implementation, then developer acceptance review). This also gates when money is spent on the next phase. ### Maximalist example - The **GitHub agentic workflows project itself** is claimed to be "built entirely by agents," with roughly **200 agents** running pipeline parts. He notes the team has an **internal goal** to develop only from mobile devices, interacting entirely through slash commands — presented as a view of "fully agent-led development." (Example shown: a daily-scheduled meta-agent checking reports on other agents.) ### Pre-built agents - The **github next org's "Agentics"** project offers ~30 off-the-shelf pipeline agents (deduplication, QA reviewer, joke-making reviewer, etc.). --- ## 5. Cost and Observability Argument His central claim: **moving workloads off laptops into CI is key for cost optimization and optimization generally**. - If everyone uses AI locally, the organization "can't see how they're actually working with the tool" — no visibility into verbosity, task success, tool-call success/failure, or whether agents use reasoning vs. bash scripts for search. - Pipeline agents are **instrumented with "hotel"** (as transcribed; presumably OpenTelemetry/OTel), viewable in a SIEM or logging platform: - Compare how an agent runs across repositories; check cost - Pivot on **average token use** - Trigger investigations when an agent **exceeds its P90 expected cost**, asking it to return debugging information - **A/B test** front matter or models on repeated tool-call failures, potentially selecting a **cheaper model** once output quality is confirmed --- ## Traceability & Qualification Notes - All claims above are the speaker's stated descriptions of GitHub products and workflows; this record does not independently verify product behavior. - Tentative/hedged phrasings preserved where present: the 200-agent count is given as "I don't know, 200 agents"; agent selection in the demo was "picking at random"; the mobile-device-only development is described as an **internal goal**, not verified practice. - "Cappy," "the harness," and "hotel" are terms as transcribed from the talk. - The speaker frames himself as a field adoption advisor, not necessarily an engineer on these products; product-capability claims should be treated as his presentation of the platform. # Video Attribution & Provenance Record ## Video Identification - **Title:** From Your Laptop to the Pipeline: Scaling Custom Agents with GitHub Copilot - **Video ID:** `01a15ca6-afd0-71a4-a996-67d4f369bd29` - **Source:** Transcript only; no curated metadata supplied beyond title. ## Speaker Inventory | Speaker | Role | Basis | |---|---|---| | **Jose Palafox** | Creator/presenter; GitHub employee in a **field role** (customer-facing, ~6.5 years at GitHub, joined shortly after Microsoft acquisition; previously focused on GitHub's security business, last ~year focused on AI adoption) | Self-identification in transcript opening | No additional speakers, guests, narrators, or unnamed voices appear in the transcript. All content is first-person presentation by Palafox. ## Speaker Self-Stated Background (claims, not independently verified) - At GitHub 6.5 years; joined after the **Microsoft acquisition of GitHub**. - GitHub's acquisition of a security company (referred to phonetically as "Semmel" in transcript — name unverified, likely transcription artifact). - Role: field work helping customers adopt and scale GitHub technology. - Offers follow-up contact: in person after the talk, via **LinkedIn**, or through the attendee's **GitHub AE (Account Executive)**. ## Referenced Sources, Products & Third Parties Named in Transcript - **GitHub Copilot platform architecture:** "Cappy" / Copilot API service (also called the "harness"); interfaces: IDE, GitHub CLI, SDK, mobile streaming via `/remote`. - **Embedded CLI agents:** explorer agent (uses Haiku), "rubber duck" agent (plan validation across model providers, e.g., Opus plan audited by GPT). - **Model providers referenced:** Haiku, Opus, GPT (named as examples, no formal source cited). - **Distribution mechanisms:** agent marketplaces (repo + JSON convention), `.github-private` repository convention (transcript renders as "GitHub private" — naming convention claim per speaker). - **External/community resource:** **`awesome-copilot`** repository, cited as containing example agents registrable as a marketplace. - **GitHub projects cited as live examples:** - The **GitHub "AW" (agentic workflows) project** — claimed to be built entirely by agents (~200 agents), with a team goal of mobile-only development. - **`githubnext` organization → "Agentics"** project — claimed to contain ~30 off-the-shelf pipeline agents. - **Tooling claims:** `orchestrate` command (cross-repo agent scaling), Copilot CLI headless `-p` mode, GitHub Actions/CI execution, OpenTelemetry-style instrumentation (transcript renders as "hotel" — likely transcription artifact for "OTel"), SIEM/logging integration, cache-hit cost model claims. ## Provenance Notes & Uncertainty Flags - All product capabilities, project names, and statistics (e.g., "200 agents," "30 or so pipeline agents," 6.5 years tenure) are **speaker assertions only**; no cited documents, URLs, or third-party verification in transcript. - Transcript contains probable transcription artifacts: **"Semmel"** (company name), **"cash hits"/"cash rate"** (likely "cache hits"/"cache rate"), **"hotel"** (likely "OTel"), **"GetHub"** (GitHub), **"Cappy"** (phonetic). - No timestamps, on-screen citation lists, or external source attributions available. ## Promotional / Commercial Segments - **Flagged: product promotion.** The entire talk functions as a product walkthrough and adoption pitch for GitHub Copilot agents, delivered by a GitHub field employee. - **Flagged: solicitation segment (closing).** Palafox invites attendees to connect via LinkedIn and to loop in their GitHub Account Executive for conversations — a commercial follow-up channel. ## Comment / Follow-up Availability - No information about video comments, downloadable materials, or recording availability is present in the transcript. - Stated follow-up channel: in-person Q&A after the talk ("back of the room"), LinkedIn, or via GitHub AE. ## Evidence Channels Unavailable - Slides/visuals, curated metadata, speaker bio, external links, and comment section status were **not supplied** and could not be verified. \>\> 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 um regulatory 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 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 out of that 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 agents 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 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 want it 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, 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 for 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. 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, you should generate one, right? And there is a capability basically to sync those with the the local client device and then pushing and 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 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. 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 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 drop-down is the same compliance bot that's in the repository, right? So, this is a way of 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, 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 cash hits, right? You want exact matches between turns on common data. And having reusable components 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 going to call another pipeline agent, right? Which is the PRD generating product manager 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 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 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 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 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 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 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, 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 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 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 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 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 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 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, 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 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 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 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 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 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 and it's instrumented with hotel. So, I can go to a SIM or some kind of logging platform and look, does my code 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 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 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 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 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 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 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 have a quick conversation as well. Thanks so much for your time today.