GitHub Copilot exposes several interfaces that route through a shared harness, which handles context, model calls, filtering, authentication, metrics, and audit logging.
2
Teams can generate custom agents, edit their instructions, publish them through marketplaces, and distribute them across an organization.
3
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.
Copilot presents several interfaces over one shared harness
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
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
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
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
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
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
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
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.
