GitHub Copilot CLI agents: build one with /agent, share it through a plugin marketplace, then run it headless in CI

Step 1: build an agent in the CLI

1. Run /agent in interactive mode and choose to create a new agent. Pick where it lives: the project (.github/agents/) or your user profile (~/.copilot/agents/). If a personal and a project agent share an ID, the personal one wins. Restart the CLI to load a new agent.
2. Describe the job in a sentence. Copilot drafts the profile for you: description, front matter, success criteria and method. His demo: "go to the change log and summarise all the changes". Then edit it, for example to change the order of sources.
3. The file is Markdown with an .agent.md extension; GitHub's documentation shows the front matter fields name, description, tools and include-custom-instructions. He says an agent can also pin its model (his example: a small model for an "explorer" agent that investigates a codebase, and a second-opinion "rubber duck" agent that checks a plan from a different model); the documentation page we checked doesn't mention a model field, so confirm it in your version.
4. Invoke it by selecting it from /agent, by naming it in the prompt, by letting Copilot infer it from the description, or from a script:

copilot --agent security-auditor --prompt "Check /src/app/validator.go"
copilot -p "one-shot prompt"      # programmatic mode, no interactive session

Step 2: share it

• A plugin marketplace is a repository with a marketplace.json (documented location: .github/plugin) listing plugins. Register and manage them with copilot plugin marketplace add <spec>, list, browse <name> and remove <name>. He says a marketplace gives light package management: versions, updating every agent at once and notifying people of security issues, and that creating one is usually the first thing he does when a company is scaling adoption.
• Org-wide distribution (speaker's account): agent files placed in a repository named .github-private at the organisation level appear in the cloud agent drop-down and in teammates' IDE and CLI. GitHub's documentation page for CLI custom agents does not mention that location, so check the current docs before relying on it.
• Why standardise: his cost argument is that the cheapest usage is cache hits, so common reusable agents that solve a problem the same way raise cache rates and lower bills.
• Across repositories: he describes an orchestrate command in the Copilot app that takes GitHub issues as goals and starts sub-agents in the repositories where each change belongs. We couldn't find it in the documentation pages we checked.

Step 3: move it off your laptop

• Steer a session from your phone. GitHub documents /remote on in a running session, or starting with copilot --remote; you then steer it from GitHub Mobile or github.com. The computer running the session has to stay online.
• Run headless in CI. His pattern: call the CLI with -p inside a GitHub Actions runner on a trigger such as a release or a weekly schedule, to update docs, refresh context files or look for duplicated code.
• Agentic Workflows (gh-aw) packages this: write instructions in Markdown with YAML front matter, run gh aw compile to generate the Actions lock file. Install with gh extension install github/gh-aw. Workflows run read-only by default, with writes only through sanitised safe outputs, and the project's README calls it a research demonstrator in early development.
• Human-in-the-loop checkpoints. His example: a scheduled agent finds three deduplication opportunities and opens issues; a developer comments a slash command to advance one to a planning agent, then to implementation, then reviews the pull request.
• Why in CI: he argues you can only optimise what you can see. With runs instrumented through OpenTelemetry, you can track cost and tokens per agent across repositories, alert when an agent exceeds its 90th-percentile cost, and A/B test models or front matter. He points to GitHub's agentics project (about 30 ready-made pipeline agents) as a source of examples.

Gotchas & Caveats

• This is a vendor talk. The workflow is sound, but "scales" and cost claims are the speaker's, not measurements.
• Agents that run in a pipeline act with the repository's identity and budget, not yours. Scope their permissions and review what they open before merging.
• Agentic Workflows is labelled early and experimental by its own README. Keep deterministic jobs in plain Actions.
• Remote steering needs the session's machine awake and online.

Key Takeaways

• /agent creates an agent file you can edit; --agent and -p run it from scripts.
• Share through a plugin marketplace, then pull recurring jobs into Actions where you can measure them.
• Put a human approval step between agent stages that spend money or change code.