Copilot is no longer just “autocomplete.” In many organizations it’s becoming an agent runtime that runs tasks, hits internal APIs, and executes workflows on runners that look a lot like CI infrastructure. And that shift turns previously “nice-to-know” release notes into urgent platform work.
Two updates from the GitHub Changelog (both posted March 2, 2026) illustrate why: model deprecations across Copilot experiences, and network configuration changes for Copilot coding agent that affect self-hosted runners and private networking environments.
1) Model deprecations: treat AI models like runtime dependencies
GitHub announced upcoming deprecations for several models used across Copilot Chat, inline edits, agent modes, and completions. The message is straightforward: specific models will stop being available on certain dates, and organizations should adopt suggested replacements.
In practice, that means enterprises need to manage AI models the way they manage language runtimes and container base images:
- Inventory: where is each model used (IDE, web, CLI, agent workflows)?
- Policy: which models are approved for which repos/teams?
- Testing: does the replacement change code quality, style, latency, or hallucination patterns?
- Change windows: align model switches with release cycles, not random Tuesdays.
One subtle point: when a model deprecation hits an agent workflow, failure modes can be noisier than chat. Agents might fail mid-task, produce partial changes, or retry aggressively. The earlier you migrate, the calmer the transition.
2) Network endpoint changes: your allowlists must match your Copilot plan
GitHub also noted that previously announced network configuration changes for Copilot coding agent are now in effect. The big operational detail: Copilot agent network routing is now subscription-based, connecting to different hosts depending on the Copilot plan of the user who initiated the agent task.
GitHub lists the plan-to-host mapping as:
- Copilot Business:
api.business.githubcopilot.com - Copilot Enterprise:
api.enterprise.githubcopilot.com - Copilot Pro/Pro+:
api.individual.githubcopilot.com
If your self-hosted runners were allowlisted only for api.githubcopilot.com, you now need to update firewall rules, proxies, and egress policies to permit the correct host(s). And conversely, GitHub notes you may be able to remove the old host from allowlists once migrated.
Why this matters: the agent is now part of your supply chain
Once you’re running agent tasks on runners with access to code, secrets, and internal endpoints, Copilot becomes a supply chain component. That implies:
- Network governance: treat egress destinations as part of your security model.
- Identity governance: the initiating user’s plan can influence routing; ensure your audit logs capture who initiated what.
- Model governance: the model is a dependency that changes behavior; approvals should exist.
- Incident response: model outages or routing misconfigurations become production-impacting events.
This is especially true for regulated environments where “which external service did this runner talk to?” is not a theoretical question.
A platform-team checklist (do this before the deprecation dates)
- Confirm your Copilot plan mix across orgs and users (Business vs Enterprise vs Pro/Pro+).
- Update allowlists for runner egress and private networking to include the correct hostnames.
- Review model policies (which models are enabled, and where).
- Run a “dry task” on a test repo using the coding agent to validate network routing.
- Communicate timelines to engineering: model switches can affect output and latency.
The bigger trend: agent ops is becoming a first-class DevOps discipline
Traditional CI/CD already had to manage runners, caches, credentials, and egress. Agentic CI adds a new axis: model lifecycles and AI service endpoints. If your organization is serious about AI-assisted development, this is the moment to build an “agent ops” playbook with the same rigor you apply to pipelines.