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

Jose Palafox, GitHub | AI Engineer World's Fair 2026 | 19:39

Source: https://www.youtube.com/watch?v=b9UhZkKjX_A
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/from-your-laptop-to-the-pipeline-scaling-custom-agents-with-github-copilot
Published: 2026-10-10
Tags: agents, harness-engineering, observability, workflows

## TL;DR
- GitHub Copilot exposes several interfaces that route through a shared harness, which handles context, model calls, filtering, authentication, metrics, and audit logging.
- Teams can generate custom agents, edit their instructions, publish them through marketplaces, and distribute them across an organization.
- GitHub Agentic Workflows run headless Copilot CLI agents in CI, where teams can trigger work from repository events, review results through issues, and monitor cost across repositories.

## Summary
Jose Palafox explains a progression from local Copilot agents to agents shared across an organization and run autonomously in CI. He first describes how the IDE, GitHub CLI, remote sessions, and SDK connect to the Copilot API service, or harness, which handles context, model requests, filtering, authentication, metrics, and audit logs. The CLI includes agents for tasks such as codebase exploration and plan review, with each agent able to choose its model and instructions. Palafox then demonstrates generating a custom agent, editing its structured file, and sharing it through a marketplace or an organization's repository. Orchestrate can start agents in the repositories where their work belongs. Finally, GitHub Agentic Workflows use headless Copilot CLI runs in GitHub Actions. Issue comments can advance work through discovery, planning, implementation, and acceptance. Palafox argues that CI-based agents are easier to observe, operate across repositories, and analyze for cost and failed tool calls than agents running only on individual laptops.

## Key ideas
### Copilot presents several interfaces over one shared harness
[01:34](https://www.youtube.com/watch?v=b9UhZkKjX_A&t=94s)
Palafox describes the IDE, GitHub CLI, remote sessions, and SDK as different ways to reach the coding agent. A CLI session can be delegated to github.com or streamed to a mobile device with the remote command. The SDK can put agent functions in Slack or Teams for people who do not have a GitHub license. Each interface reaches the Copilot API service, which he calls the harness. It chunks input, sends requests to model providers, filters output, handles authentication, records metrics and audit logs, and then returns the result.

### Built-in agents show how model choice can match the task
[03:37](https://www.youtube.com/watch?v=b9UhZkKjX_A&t=217s)
The CLI includes agents for specific jobs. Palafox uses an explorer agent to investigate a codebase with a smaller Haiku model instead of using the biggest available model. A rubber duck agent can review a plan written with Opus by using GPT or another model with different training data and weighting. Each agent specifies its model and instructions. The same choices are available when teams create their own agents for reviews, compliance checks, regulatory requirements, or custom tools.

### The agent builder creates a usable file from a short description
[05:32](https://www.youtube.com/watch?v=b9UhZkKjX_A&t=332s)
The agent command lets a user choose whether an agent belongs to a project or is available at the user level. Palafox describes generating an agent that reads the GitHub changelog and summarizes recent features. From a one-line request, Copilot writes the description, front matter, success criteria, and a suggested methodology. The user can edit the generated file, such as changing the order of sources so the agent goes directly to the changelog instead of starting with the roadmap. This turns a repeat task into an agent that can be called from the harness.

### A marketplace gives agents versioning and shared distribution
[07:25](https://www.youtube.com/watch?v=b9UhZkKjX_A&t=445s)
Palafox describes a marketplace as a repository with extra JSON that adds lightweight package management. Subscribers can update agents together, version them, and receive notices about security vulnerabilities. He recommends creating a central repository when teams have no shared place to contribute agents or skills. Agents can also be distributed through an organization's GitHub private repository, where the same compliance bot can appear in the cloud interface, IDE, and CLI. Reusable agents can reduce duplicated work and improve cache hits, which Palafox connects to lower overall cost.

### Orchestrate starts work in the repository that owns the task
[10:55](https://www.youtube.com/watch?v=b9UhZkKjX_A&t=655s)
Agents normally start in the repository where they live, which can prevent them from acting in other repositories because permissions are tied to the starting repository. Palafox presents Orchestrate as a way to set GitHub issues as goals and create subagents for those tasks. The subagents run in the repositories where their changes belong. A change to a microservice API can therefore be paired with downstream changes in other repositories. Organization-provided or marketplace agents can be called for each repository while the overall work stays connected to the original goals.

### Agentic Workflows move unattended work into GitHub Actions
[12:41](https://www.youtube.com/watch?v=b9UhZkKjX_A&t=761s)
Palafox explains that the Copilot CLI can run headlessly with a single prompt passed through the -P command. Running that command inside a GitHub Actions runner turns it into a pipeline agent. Repository events can trigger documentation updates, context-file maintenance, or code analysis. One example looks for duplicated or poorly namespaced code and creates issues. A developer reviews those issues and uses a slash command to advance selected work to a planning agent, an implementation step, and a later acceptance review.

### Issue comments keep developers in control of spending and changes
[13:55](https://www.youtube.com/watch?v=b9UhZkKjX_A&t=835s)
In Palafox's example, an agent runs on a schedule, finds several improvement opportunities, and records them. A developer decides which suggestions are worth pursuing by commenting on the issue with a slash command. A planning agent then scopes the feature and creates a plan before Copilot handles implementation. The developer returns at the acceptance stage to inspect the code and decide whether it belongs in the project. This workflow adds human approval between automated stages, including before more agent work consumes budget.

### CI makes large agent fleets observable and easier to tune
[14:56](https://www.youtube.com/watch?v=b9UhZkKjX_A&t=896s)
Palafox contrasts pipeline agents with local sessions that stop when a laptop or network connection fails. He points to the GitHub Agentic Workflows project, which he says contains about 200 agents running different parts of its pipeline, including agents that inspect reports from other agents. GitHub's Agentics project contains around 30 sample pipeline agents, such as code deduplication and review agents. Once work runs in CI, teams can inspect runs across repositories, measure token use and cost, investigate agents that exceed their expected P90 cost, and test different instructions or models when tool calls fail.

## Notable quotes
- "Regardless of which door you go through, you hit the harness." (02:46)
- "You can always control the model that you're using, and then you control the instructions that you're giving it." (04:46)
- "The cheapest way to use them is to get cache hits." (09:48)
- "Not every agent needs to be me taking an action." (12:27)
- "All of this stuff is possible once I get the agents into the pipeline." (18:41)

## Tools & references mentioned
- GitHub Copilot
- GitHub Copilot CLI
- GitHub Copilot SDK
- GitHub Agentic Workflows
- Orchestrate
- GitHub Actions
- Haiku
- Opus
- GPT
- Semmle
- Slack
- Microsoft Teams
- GitHub private repository
- awesome-copilot
- Agentics

## Who should watch
- You have built a useful local custom agent and need a way to share it with coworkers.
- Your agents need to make changes across several repositories while using each repository's permissions.
- You want scheduled or issue-triggered agent work in CI and need to inspect its failures, token use, and cost.

## Editor's note

Jose Palafox says CI lets teams investigate agents when tool calls fail and test different instructions or models. Kitaru records every model call and tool result from a real run, then replays the agent against those same responses after a change. That gives teams a repeatable way to inspect a failed run without touching production systems.

Written by the AIE Talks editors (the Kitaru team), not by the speaker.

## Related talks

- [Collaborating with Agents in Your Software Development Workflow](https://aietalks.com/talks/collaborating-with-agents-in-your-software-development-workflow) (Jon Peck & Christopher Harrison, Microsoft, 1:04:06)
- [The Agent Awakens: Collaborative Development with Copilot](https://aietalks.com/talks/the-agent-awakens-collaborative-development-with-copilot) (Christopher Harrison & Jon Peck, GitHub, 1:04:06)
- [Agents, codebases, and teams](https://aietalks.com/talks/agents-codebases-and-teams) (Aditya Khandelwal, Amazon AGI Lab, 16:57)
- [Piloting agents in GitHub Copilot](https://aietalks.com/talks/piloting-agents-in-github-copilot) (Christopher Harrison, Microsoft, 59:07)
- [Ship Agents that Ship: A Hands-On Workshop](https://aietalks.com/talks/ship-agents-that-ship-a-hands-on-workshop) (Kyle Penfound & Jeremy Adams, Dagger, 1:21:00)