3 Layers of GitHub Copilot Agents: Local to Pipeline

GitHub Copilot agents scale through three layers: local agents in GitHub Copilot CLI, shared agents distributed through an org marketplace, and autonomous agents that run unattended in GitHub Actions. Each layer moves work off the individual laptop and toward repeatable, observable, org-wide automation.

What GitHub Copilot agents are and where they run

GitHub Copilot agents are task-specific AI workers that run inside GitHub's platform in two modes: local agents you steer interactively, and autonomous agents that run unattended in a repository or CI pipeline. The path from one to the other has three layers, and each layer solves a different scaling problem.

Jose Palafox, a Field GitHub Copilot Specialist who has worked at GitHub for six and a half years, laid out this path at AI Engineer World's Fair 2026 in San Francisco. His core argument: an agent that lives on one laptop cannot be standardized, observed, or cost-optimized. Moving it into shared infrastructure is what unlocks all three.

How GitHub Copilot works under the hood

Every GitHub Copilot interface funnels into one shared service, regardless of where you enter. You can reach it from the IDE, the GitHub Copilot CLI, or GitHub Copilot SDK](https://docs.github.com/en/copilot), and each door leads to the same harness.

The harness, sometimes called the GitHub Copilot API service, handles the infrastructure work: chunking your input, sending it to model providers, checking open-source content, handling authentication, and writing metrics and audit logs. When the model responds, GitHub filters the output before displaying it. You can also hand a CLI session to github.com to run in the background, or use the remote command to steer a running agent from a mobile device.

The practical consequence: an agent you build once works through every surface, including Slack or Teams integrations built on the SDK for teammates without a GitHub license.

Built-in agents in GitHub Copilot CLI

GitHub Copilot CLI ships with embedded agents you can inspect by typing the agents command. They are useful references because they show how the platform implements agents as structured markdown files, with a model choice and instructions in front matter.

Two examples from the talk:

• The explorer agent uses a small model to investigate a codebase, since deep-code exploration does not need the largest model available.
• The rubber duck agent validates a plan written by one model with a pass from a different provider, on the theory that different training data catches different weaknesses.

Each embedded agent specifies its own model. That is one of the controls you get when building custom agents too: you pick the model and write the instructions.

Building a custom agent with the agent builder

The agent command in the CLI walks you through creating a custom agent in a few steps:

1. Choose the scope: project level, tied to the repository you are in, or user level, available across every project.
2. Describe the task in one line, for example "summarize the latest GitHub changelog."
3. Let GitHub Copilot scaffold the rest: description, front matter, success criteria, and a first attempt at methodology.
4. Edit anything you dislike, such as the order of sources the agent consults.

The scaffolding is the point. You write a rough description and the builder formats a working agent file that runs inside the harness from any interface. The same builder exists in the IDE's agents interface.

Sharing agents across an organization with a marketplace

A marketplace is just a repository with a small JSON declaration that marks it as one. Subscribing gives you light package management for agents: simultaneous updates, versioning, and a channel for security vulnerability notices to downstream users.

Palafox says creating a marketplace is one of the first things he does with companies adopting GitHub Copilot, because most orgs lack a central place where teams contribute agents and skills. GitHub also maintains the awesome-GitHub Copilot repository of example agents that can be registered as a cross-org or even external marketplace.

Inside an org, agents can also be exposed through a specially named repository convention, which pushes agent files to everyone's IDE or CLI. The same agent then appears in the cloud agent picker on github.com, so one compliance bot serves the whole company.

There is a cost argument too: the cheapest usage pattern relies on cache hits between turns on common data. Reusable agents that solve problems the same way every time drive the cache rate up and the bill down.

Running agents across repositories with Orchestrate

Cross-repository work is the local agent's blind spot. An agent starts in the repo where it lives, so it lacks permissions to act elsewhere.

Orchestrate, a command in the GitHub Copilot app, addresses this. You set a series of GitHub issues as goals, and it spins up sub-agents in the repositories where the work actually belongs. A change to a microservice API and the matching downstream change can happen as coordinated cross-repo work, with agents summoned from your org's marketplaces and kept on task.

Moving agents into CI with GitHub Agentic Workflows

Some agents should not run on a person's budget or identity at all. Maintenance work belongs to the repository, so it should run on the repo's budget and under the repo's identity.

GitHub Agentic Workflows enables this with a simple mechanism. GitHub Copilot CLI supports a headless mode: pass a one-shot prompt with the dash-p flag, run it inside a GitHub Actions runner, and you have an agent in the pipeline. Trigger it on repo events: update documentation on a release, refresh context files weekly, or hunt for duplicated code that agents tend to introduce.

The framework builds in human-in-the-loop triggers. A typical flow runs like this: a cron-scheduled agent finds three deduplication opportunities and files issues; a developer reviews them and advances one with a slash command in an issue comment; a planning agent scopes the feature; GitHub Copilot implements it; and a developer signs off at an acceptance phase before money is spent on the next stage.

The maximalist example is the agentic workflows project itself, which the team develops almost entirely through slash commands from mobile devices, with on the order of 200 agents running different parts of its pipeline. GitHub's githubnext org also publishes Agentics, a collection of around 30 off-the-shelf pipeline agents including deduplication finders and various reviewers.

Why the pipeline is where cost optimization happens

Local agent usage is invisible to the organization. You cannot tell whether an agent is too verbose, whether its tool calls succeed, or whether it wastes model reasoning on tasks a bash script would finish. Without visibility there is nothing to optimize.

Agents running in CI are instrumented with OpenTelemetry, so metrics land in your logging platform. From there you can compare a code-duplication agent's cost across repositories, pivot on average token use, or trigger an investigation whenever an agent exceeds its expected P90 cost. Repeated tool-call failures invite A/B tests of different front matter or different models, including a cheaper model once output quality is confirmed.

FAQ

• Do custom GitHub Copilot agents work in every GitHub Copilot interface? Yes. Because every interface, IDE, CLI, SDK, and github.com, enters through the same harness service, an agent built once is callable from any of them.

• What is GitHub Copilot agent marketplace? A regular repository with a small JSON file that declares it as a marketplace. Subscribers get versioning, bulk updates, and security notifications for the agents it distributes.

• How do agents run without a developer present? GitHub Copilot CLI takes a one-shot prompt in headless mode, and GitHub Agentic Workflows wraps that in a GitHub Actions runner. Repo events or cron schedules trigger the run, and slash commands in issue comments keep humans in the loop.

• Why move agents off the laptop at all? Three reasons: reuse across the org raises cache hit rates and lowers cost, repo-scoped runs use the repo's budget and identity instead of yours, and CI instrumentation with OpenTelemetry makes cost and behavior observable and optimizable.

• Where can I find ready-made pipeline agents? The githubnext organization publishes Agentics, a set of roughly 30 sample pipeline agents, and the awesome-GitHub Copilot repository collects example agents that can be registered as a marketplace.

Turn your own agent talk into a written guide

This article follows the same path Palafox described: knowledge that starts in one place, a conference talk, gets packaged so a wider team can use it. If your own explanations, interviews, or engineering lessons are sitting inside YouTube videos, Skala Blog turns them into structured, searchable articles: paste the URL, transcribe the video, and generate a draft you can edit and publish.

Source video