GitHub Copilot Automations now run in the cloud and belong to the repo - what it changes for who owns your agents

GitHub shipped a batch of changes to Copilot Automations on 28 October. Three of them matter if your business runs software: automations now run in the cloud with your laptop closed, a shared automation belongs to the repository instead of to whoever built it, and an automation can be started from any outside system through GitHub's REST API. According to GitHub's changelog, all of it is available on Copilot Pro, Pro+, Max, Business and Enterprise plans. Shared automations are still rolling out.

What actually changed

An automation is a trigger, a prompt and a list of allowed tools. Copilot runs it on its own when the trigger fires. Until now that mostly meant local, personal jobs tied to one developer's machine and one developer's account.

The 28 October release adds:

• **Cloud runs.** Scheduled work keeps going when VS Code is closed or the computer is off. You need VS Code 1.144 and a setting switched on.
• **Shared automations.** They are owned by the repository, billed to the organisation that owns it, and keep running after their creator leaves. Actions are attributed to Copilot, not to a person. There is a change history for the prompt, tools and triggers.
• **24 new GitHub triggers** covering issues, pull requests, discussions and security alerts, plus a REST API trigger. GitHub's own examples are triaging Jira tickets, fixing new Sentry issues and investigating PagerDuty incidents.
• **Chaining.** An automation can fire when another one succeeds or fails.
• **MCP tools.** Automations can call tools from your own MCP servers, so they can reach systems outside GitHub. You pick exactly which tools each automation may use.
• **AI credit limits** per run, per day, per week or per month.
• **Self-improvement.** A companion automation watches outcomes, such as whether developers accept its review comments, and proposes changes to the prompt. A person has to approve each change before it applies.

What is genuinely new

Scheduled agents are not new. You could already wire a model to a cron job, a webhook and a few API keys. What is new is that this now lives inside a tool most software teams already pay for, with the plumbing done: triggers, tool permissions, billing, history and an owner that is not a person.

That last point is the one I would pay attention to. The most common way small automation setups die is that they run under one person's account. That person leaves, their token is revoked, and a job nobody remembered existed stops working. Repository ownership fixes that specific failure. It is a real improvement, and it is the same thing we argue for in every handover: the business should own the automation, not an individual.

What it means for a business owner

If you have a development team or an agency working in your GitHub, a set of chores just became cheap to automate properly. Labelling and routing incoming bug reports. Reproducing a bug when an issue opens. Pulling context together when your monitoring tool raises an incident. Chasing stale pull requests. These are high-volume, low-judgement jobs that people forget to do, which is exactly where automation pays.

The REST trigger and MCP tools push this past GitHub. A support ticket or an alert in another system can start a run that reads your code and your internal tools. For a team that already lives in GitHub, that may be enough of a platform that a separate orchestration tool is not needed for engineering workflows.

GitHub has not published a price per run or per credit in these posts. Budget by setting a limit and watching a month of real usage, not by guessing.

The honest caveats

**Limits are off by default.** GitHub's wording is that automations without limits "continue to run as they do today." A chained automation that triggers itself, or a noisy alert source hitting the API trigger, will spend credits until someone notices. Set a monthly cap on every automation the day you create it.

**Write access means edit access.** Anyone who can push to the repository can change a shared automation's prompt and tools. That includes contractors. If an automation can merge pull requests or call an MCP tool that touches customer data, its prompt is now part of your security surface.

**"Done by Copilot" is a weaker audit trail.** Attributing actions to Copilot solves the leaver problem but hides which human set the automation up. The change history helps. Check it is enough for whoever audits you.

**Self-improvement is a proposal queue, not autopilot.** The signals are thin: an accepted comment is not proof the comment was right. Someone still has to read each proposed prompt change. If nobody will, leave the feature off.

**It is a developer tool.** None of this helps with invoices, onboarding or sales follow-up unless your team builds that bridge with MCP. Businesses without an engineering team should wait.

What to do about it

If you are on a Copilot business plan, pick one repetitive engineering chore, such as triaging new issues, and build it as a shared automation with a tight tool list and a monthly credit cap. Run it for two weeks and compare its labels with what a person would have done. Then list every automation that still runs under a named person's account, in GitHub or anywhere else. Those are the ones that will break when someone leaves.