GitHub Copilot CLI turns Markdown into repeatable custom agents

What Changed

GitHub is turning Copilot CLI into a place where teams can encode repeatable work, not just ask for command-line help. In its source tweet, GitHub wrote: “Custom agents in GitHub Copilot CLI” and “Define roles, tools, and guardrails in Markdown.” The important shift is that a terminal assistant can now be shaped by repository-owned instructions instead of a fresh prompt every time a developer needs a task done.

The linked GitHub Blog post says each custom agent is defined by an agent profile: a Markdown file stored in .github/agents, ending in .agent.md, with YAML frontmatter for role, scope, capabilities, and guardrails. Because that profile lives in the repository, a team can review it, version it, and update it like code. That matters for organizations where the difference between a useful automation and an unsafe one is often the exact checklist, output format, and tool boundary.

Why It Matters

GitHub’s examples are practical rather than abstract: security audit agents, infrastructure-as-code compliance agents, release documentation agents, and incident response agents. These are workflows that often begin in the terminal but end as artifacts others must trust: pull request checklists, changelog entries, risk summaries, or incident reports. Putting those instructions in Markdown makes the behavior inspectable, and running them from Copilot CLI keeps the work close to scripts, logs, APIs, and repositories.

The blog also points to partner agents from companies including JFrog, Dynatrace, Octopus Deploy, and Arm, which suggests GitHub wants this pattern to extend beyond generic coding help into tool-specific operations. The next thing to watch is governance. If agent profiles become common repository files, teams will need review norms for changing them, just as they already review CI workflows and deployment scripts. The second test is continuity: whether an agent started in the CLI can carry enough context into the IDE and GitHub pull requests to make the workflow feel consistent across the developer toolchain.