GitHub's agent finder lets Copilot look up its own tools

The afternoon I stopped pre-wiring everything

I sat down last Friday with the kind of agent setup that has become a quiet rite of passage on our team: a stack of MCP servers we keep adding to just in case, a folder of skills nobody fully audits anymore, and a context window that is mostly filled before I have typed a single character. You know the feeling. Every new agent project begins with a checklist of plumbing, not code.

That is the muscle GitHub is trying to retire. On the 17th the GitHub Changelog quietly announced that agent finder for Copilot is available, on all Copilot plans. The pitch is simple to the point of being anticlimactic: instead of deciding in advance which MCP servers, skills, canvases, agents and tools each agent should know about, you describe the task in plain language and Copilot goes shopping for the right capability.

What actually shipped

Agent finder is a discovery layer. You hand it a task description; it searches an index of available AI resources and returns ranked matches that Copilot can pull in on demand from any catalog you point it at. The change is less about new abilities and more about how those abilities get loaded.

Under the hood it implements the open Agentic Resource Discovery specification, which GitHub says it developed with Google, GoDaddy, Hugging Face and Microsoft. The word doing the work there is open. ARD is not a private GitHub format; it is a cross-vendor description of how an agent looks up the capabilities it needs at runtime. If the spec sticks, the same catalog you publish for Copilot will be readable by every other client that speaks ARD.

The entry is careful on a second point too: nothing installs itself. Agent finder surfaces the right tool at the right time and does not silently connect anything. You stay in the loop.

Why this is a CI/CD problem, not only a Copilot one

If you only build chat agents, this looks like a quality-of-life nudge. If you run pipelines, look again. Most CI/CD platforms have spent the last year wiring tools, MCP servers and skills into jobs the same way we used to wire them into IDEs: hand-mapped, per-vendor, redeployed every time a tool changed. That is the same fragility that pushed us, a decade ago, from hand-rolled CI scripts to discoverable plugin marketplaces.

A portable lookup primitive — one a build job can ask, what is the best agent for X right now? — is a different shape. Catalogs become assets that ship through the pipeline. Selection becomes a runtime decision, not a checkout-time one. If your platform speaks ARD, you can promote, sign and version a catalog the same way you handle other artifacts.

Using it without booby-trapping your repo

The Changelog is light on UI specifics, and I am not going to pretend I know which menu it lives under tomorrow. What it does tell you is what to control: agent finder reads from catalogs you point it at, and it never silently connects a tool. That is now your governance surface.

The things I would lock down before letting it loose in a team workflow:

• Which catalogs Copilot is allowed to consult, and whose they are.
• What happens when the top-ranked match belongs to an upstream you have not reviewed yet.
• A record of which capability won which lookup, for the inevitable why did the agent do that review.

None of this is unique to GitHub. It is the same conversation we had when we first let dependency installers run free in CI.

The rough edges I am side-eyeing

A discovery layer is only as good as its data. The Changelog does not enumerate the launch catalogs, how schema drift is handled, or what the fallback looks like when an ARD-compliant directory goes offline mid-job. Until that picture fills in, the feature is more promise than primitive.

The collaborator list — Google, GoDaddy, Hugging Face, Microsoft — reads as encouraging rather than complete. ARD becomes a real CI/CD primitive when the long tail of CI vendors, registries and policy engines speak it too. We are not there yet.

How the rest of the agent ecosystem is chasing the same problem

Other corners of the agent world have been chipping at this from different angles. Package-style registries where you pin a tool by name and version. Framework conventions that turn an agent into a directory of files you can diff and review. Gateway services that route a model's tool calls through a single broker. Each gets you part of the way. Registries are great until you need to choose between three similar tools at runtime. Directory conventions help with review but do not, on their own, tell a running agent what is out there. Gateways centralize policy but tend to be vendor-shaped. ARD-style discovery is the seam that lets these approaches plug into each other instead of competing for the same job.

What I am watching next

Two things. First, whether non-GitHub clients actually ship ARD readers — the moment a second platform consumes the same catalog Copilot does is the moment this stops being a Copilot feature and starts being a primitive. Second, whether GitHub publishes guidance for running an ARD catalog inside a CI/CD job, not just an IDE. If both happen, the pre-wire every tool Friday afternoon is finally something I can tell new engineers about as a war story instead of an onboarding step.