GitHub Will Publish Your Custom Agent to Every Repo. Then Nobody Has to Check It Again.

GitHub now lets orgs publish a custom agent everywhere at once. Its unset defaults enable every tool, with no audit log tracking what changes after.

GitHub's August 28, 2026 Visual Studio changelog lets an organization or enterprise owner write a custom agent once, publish it, and have every repository under that organization see it in the Copilot agent picker automatically, with no per-repo setup required, the kind of thing a lot of internal wikis promised and never delivered. The picker shows the agent's description and its source organization on hover, plus a button that opens the underlying definition file, so a developer picking up someone else's agent can see what it actually is before running it.

Sources: GitHub Copilot in Visual Studio: August update (GitHub Changelog)

The mechanism behind that is a file, not a service. A custom agent is a Markdown file with YAML front matter, saved with a .agent.md extension, and an organization-level one lives in an /agents directory inside a special repository named .github or .github-private that the organization creates from GitHub's own template. Members can use an agent from that repository even without direct access to the repository itself, which is the detail that makes publish-once actually work at scale: distribution does not depend on Git permissions to the source repo.

Sources: Use custom agents in GitHub Copilot: Visual Studio (Microsoft Learn), Prepare to use custom agents in your organization (GitHub Docs)

This argument favors the category we build in, so it is disclosed here directly: we make TLM Forge, a process layer that gates AI-assisted changes behind spec review, independent multi-agent review, and a convergence gate that blocks shipping until critical issues hit zero, and everything below is a test of whether publishing an agent once is the same problem as reviewing it well.

What Actually Gets Published

An agent definition is short: YAML front matter followed by plain Markdown instructions. GitHub's documentation lists four front matter properties: name (optional, falls back to the filename), description (required, shown on hover in the picker), model (optional, pins a specific model, GitHub's own example uses claude-opus-4-6), and tools (optional, an array of tool names the agent may call). The two optional fields carry the actual governance question. Leave model blank and the agent runs on whatever model the person using it has selected in their own picker, so an agent published in March can behave differently in September without anyone touching the file. Leave tools blank and, in GitHub's own words, "all available tools are enabled," meaning the default for an unconfigured agent is not restricted access, it is every tool the platform offers.

Sources: Use custom agents in GitHub Copilot: Visual Studio (Microsoft Learn)

Where the Definition Actually Lives

GitHub recommends the .github-private repository stay private by default, specifically to avoid conflicting with other org features, though it also documents an internal option for teams that want members to view and collaborate on agent files directly, and a public option for open source organizations willing to share their agents outside the org entirely. Whichever visibility an org picks, a protection ruleset can restrict edit access to owners alone while still letting any member with write access open a pull request proposing a change, a real review gate, though the documentation does not describe a required review count, an audit log specific to agent changes, or a mandated re-review cadence once the repository exists. Enterprises get one more option: they can delegate creation and management of these agents to a role GitHub calls an AI manager instead of enterprise owners handling every change themselves.

Sources: Prepare to use custom agents in your organization (GitHub Docs), Prepare to use custom agents in your enterprise (GitHub Docs)

The Same Week: Copilot CLI Got a Rust Runtime and Two New Startup Settings

A second GitHub changelog post, covering the August 24 to 28 week and published the same day, adds two more pieces to the picture. Copilot CLI now runs on a native Rust runtime while its terminal interface stays in TypeScript, which GitHub says delivers noticeably faster performance, and two new configuration keys, defaultMode and defaultPermissionMode, let a session start already set to a chosen execution mode and permission mode instead of picking both after launch.

Sources: GitHub Copilot weekly releases: August 24 (GitHub Changelog)

Neither key invents a new mode; both let someone skip choosing an existing one at every launch. Copilot CLI already runs in three execution modes: interactive by default, plan for producing an implementation plan before any code changes begin, and autopilot for working through steps without pausing between them, switched mid-session with Shift+Tab. Permission behavior already ranges from an ask-by-default posture, where the CLI prompts before a potentially destructive action, through --allow-tool for one specific tool, up to --allow-all-tools for blanket access, with --deny-tool always overriding an allow rule regardless of which one is active. Setting defaultMode and defaultPermissionMode moves the choice of where a session starts on that range from a per-launch decision to a standing default, useful for one developer and just as useful for an organization trying to standardize behavior now that agents are published organization-wide rather than picked per developer.

Sources: Allowing GitHub Copilot CLI to work autonomously (GitHub Docs), Allowing and denying tool use (GitHub Docs)

The same roundup lists a third change with less obvious governance weight: the Copilot app's Customize tab reached general availability, consolidating MCP servers, plugins, skills, and canvases into one tab instead of scattering them across the app. Paired with org-level agents, most of what used to be a personal, per-developer Copilot configuration, which agent runs, which MCP servers it can reach, which skills it can call, now has an org-visible home instead of living only in one person's local settings.

Sources: GitHub Copilot weekly releases: August 24 (GitHub Changelog)

The same weekly roundup makes clear this reached beyond Visual Studio: it lists JetBrains getting "consistent enterprise controls for Copilot in JetBrains, including plugins, MCP servers, telemetry, and agent permission modes," language that describes the identical shift, configuration that used to sit with an individual developer moving to something an enterprise administrator sets once, on the JetBrains side of the product line. Read next to the Visual Studio org-agent feature and the CLI's new default-mode settings, the pattern across the whole August 24 to 28 week is consistent: GitHub spent that week giving administrators a lever over settings developers used to set for themselves, across three different surfaces at once.

Sources: GitHub Copilot weekly releases: August 24 (GitHub Changelog)

One Definition vs. Many Configs

The Real Question Is Not Publishing, It Is Drift

Publishing an agent once and having it appear everywhere solves a real problem: discovery. Before this, a useful custom agent for something like C++ code review or dependency modernization had to be copied file by file into every repository that wanted it, or shared informally over chat and quietly forgotten. What the publishing mechanism does not solve is whether the thing being discovered is still correct months later. GitHub's own example front matter pins a model by name, so a published agent can go stale simply because GitHub deprecates or replaces the model it names, with nothing in the publishing flow itself set up to catch that. The standard an org needs here is whether the agent still does what its description promises, with the tool access and model that decision still deserves, long after whoever wrote it moved to a different team, not merely whether the agent exists and can be found.

Sources: Use custom agents in GitHub Copilot: Visual Studio (Microsoft Learn)

Picture a concrete version of that gap, not a reported incident, just the shape the documentation itself makes possible. An engineering lead writes a documentation-review agent, leaves tools blank because the agent only ever needed to read files, and publishes it org-wide. Six months later a platform team adds new tools to the org's default tool catalog, tools meant for a different, more privileged agent. Because the documentation-review agent never pinned an explicit tools list, it inherits the new tools automatically, the same way it inherited the old ones, and now runs with capability nobody who reviewed the original pull request ever saw or approved. Nothing in the publishing flow forces a second look when the catalog underneath an agent changes, because the agent's file itself never changed.

That gap is not unique to GitHub's design. It is the same failure mode an enforceable AI coding policy exists to name: a rule that lives somewhere, that nobody is actually checking, functions as a suggestion rather than a policy, no matter how official the repository holding it looks. An org-published agent is a policy artifact now, since every repository under that org inherits whatever it says, and a policy artifact deserves the same review discipline as the policy itself, beyond simply having somewhere official to live.

TLM Forge is built around a related premise applied to a wider surface than a single agent file: a spec audit before code gets written, independent multi-agent review of the diff itself, and a convergence gate that will not let a change ship until critical findings hit zero. GitHub's org-level agents solve where a definition lives. They do not solve whether the definition stays correct, which is a review problem, not a distribution problem: a file everyone in an organization can now find is not the same thing as a file anyone is actually checking.

The durability problem underneath all of this, a definition that has to stay correct long after whoever wrote it stops paying attention, is a team problem, not a personal one. MemX, from the same team behind TLM Forge, is built for a different, individual version of durability: a private, persistent memory layer for one person's own photos, documents, voice notes, and messages, not an organization's shared configuration.

GitHub shipped a real fix for a real problem this week: a custom agent no longer has to be copied file by file into every repository that wants it. What it did not ship, at least not documented as such, is a way to know whether the agent everyone is now using still deserves the tools and the model it was given the day someone first published it. Centralizing where something is published is a distribution win. Centralizing whether anyone still checks it is a different, harder problem, and it remains exactly as unsolved as it was before August 28.