AI Agents
GitHub Agent Finder Brings ARD Discovery to Copilot
Published June 18, 2026 by Dillip Chowdary
GitHub launched Agent Finder for Copilot using the open Agentic Resource Discovery specification. The feature gives developers a governed way to discover tools, skills, agents, and MCP-style resources instead of hard-coding every capability into one assistant.
\nThis is a platform signal. Agent ecosystems are moving from bespoke integrations toward registries, verification, and policy-scoped discovery.
\nKey Technical Facts
- Agent Finder is available across all GitHub Copilot plans. \n
- The feature implements the open ARD specification for publishing, discovering, and verifying agentic resources. \n
- GitHub says discovery is governed by managed settings rather than silent resource installation. \n
- The partner ecosystem includes major developer and AI platform vendors, making ARD a candidate for cross-tool interoperability. \n
Architecture Impact
Discovery changes agent architecture because capabilities no longer need to be bundled into the same prompt, extension, or MCP configuration. A registry can publish capabilities with metadata, ownership, versioning, and verification material, while a client asks for the right resource at task time.
\nThat pattern is useful only if the registry is governed. Enterprises need owners for approved resources, expiration rules for abandoned tools, and audit logs showing which agent discovered which capability for which user.
\nARD also affects prompt design. Instead of stuffing every tool description into context, agents can retrieve smaller, more relevant resource descriptions. That lowers context pressure, but it raises the need for trust checks before a discovered resource can influence code or call an API.
\nTeam Checklist
- Action: Create an approved-resource registry with owners, review dates, and data-classification labels. \n
- Action: Separate discoverable resources from executable resources; discovery should not imply permission to run. \n
- Action: Log registry lookup, selected resource, user identity, repository, and downstream tool call in one trace. \n
- Action: Test malicious metadata, stale endpoints, and spoofed resources before allowing broad discovery. \n
Rollout Metrics
Track adoption with operational metrics, not announcement excitement. Useful signals include enabled teams, active repositories, failed actions, review changes, security exceptions, average response latency, and the number of incidents where logs were sufficient for root-cause analysis.
Teams should review those metrics after two weeks and again after one month. If the feature improves throughput but weakens review quality, auditability, or incident response, keep it in a controlled pilot until the missing controls are fixed.
Operational Risk
The failure mode is resource sprawl. Without lifecycle controls, an agent registry can become a new plugin graveyard with unclear ownership and powerful permissions.
Implementation Notes
The registry should publish more than a friendly name. Each resource needs a maintainer, supported scopes, authentication method, data classes touched, execution side effects, and a deprecation date. That metadata lets a client decide whether the resource is appropriate before it appears inside an agent plan.
Security teams should also test negative cases. A poisoned registry entry, a renamed tool, or a resource that changes behavior after approval can alter agent behavior without changing application code. Signed metadata and periodic revalidation reduce that risk.
What To Watch Next
Over the next release cycle, watch for changes in pricing, policy controls, audit exports, and integration patterns. These announcements are useful only when they are translated into runbooks that developers can follow during normal delivery work.
For production teams, the durable advantage is not early access to one feature. It is the ability to evaluate new agent capabilities quickly, decide where they fit, and retire risky experiments before they become default workflow.