# Copilot Automations: Shared, Capped Background Agents > GitHub Copilot Automations now run as shared team workflows with spending caps and 24 new triggers. What changed on 28 October and what to check first. Canonical: https://bridge-terminal.com/atlas/blog/copilot-automations-shared-cost-limits-explained/ Last updated: 2026-11-03 Published 3 November 2026 · Plain English · What's new · 6 min read ## The short version - On 28 October 2026 GitHub made Copilot Automations shareable: a workflow owned by the repository that Copilot runs in the cloud when something happens, such as an issue being assigned. - You can now cap what each automation spends per run, per day, per week or per month. Automations with no cap keep running as before. - Automations can start from 24 new GitHub events or from outside tools such as Jira, Sentry or PagerDuty, so text written outside your team can now start agent work. - Agent Merge watches an open pull request and tries to fix failing checks or merge conflicts, and you choose which of the two it may handle. - Self-improving automations only propose changes to their own prompt, tools or triggers, and a person accepts or rejects each one before it applies. GitHub Copilot Automations are now shared team workflows that run in the cloud, can start from many more events, and can be given a spending cap. GitHub announced the changes on 28 October 2026. If your team uses Copilot, the practical questions are who may create these automations, what starts them and how much they may spend. ## What are Copilot Automations? An automation is a standing instruction for Copilot. You combine three things: a prompt (what to do), a trigger (when to do it) and a set of tools (what Copilot is allowed to touch). A trigger is simply the event that starts the work. Think of an automation as a colleague who has been told: "whenever this happens, do that, and only use these tools." A pull request is a proposed change to the code that a person reviews before it is merged. Automations respond to things like pull requests being opened, issues being assigned or alerts arriving. This is a kind of background agent: AI work that happens without anyone sitting at a keyboard. ## What changed on 28 October 2026? GitHub published several related entries on the same day. Five matter for a team. ### Automations can now be shared Personal automations used the identity and the AI credits of the person who made them. Shared automations change that: - Everyone with read access to the repository can see a shared automation. Anyone with write access can edit it. - AI credits are charged to the organization or user that owns the repository, not to the person who created the automation. - Actions on GitHub are attributed to Copilot, not to an individual. - The automation belongs to the repository, so it keeps running if its creator leaves the team. A change history shows how its prompt, tools and triggers changed over time. - You choose "Shared" under "Type" when you create it, and the type cannot be changed afterwards. To run shared automations in a repository owned by an organization, an administrator must turn on the policy "Allow use of Copilot cloud agent billed to the organization". GitHub says shared automations are rolling out to Copilot Pro, Pro+, Max, Business and Enterprise, and availability may vary while the rollout continues. ### More triggers, including outside tools GitHub added 24 new GitHub events as triggers. They cover issues (assigned, labeled, closed, reopened and more), pull requests (ready for review, merge conflict, review submitted and more), discussions, and security alerts from code scanning, secret scanning and Dependabot. Automations can also be started from outside GitHub through its REST API, which is a way for other software to send instructions to GitHub. GitHub's examples are triaging Jira tickets, fixing new Sentry issues and investigating PagerDuty incidents. You set up a webhook handler, which is a small piece of code that receives an alert from another tool, and it calls GitHub's "Trigger an automation" API with the context. Automations can also be chained. New "Automation run succeeded" and "Automation run failed" triggers let one automation start after another finishes. By default a trigger fires only for events caused by users. You can change the "Can be triggered by" setting to "Users and Copilot" so that events caused by other automations also fire it. ### Spending caps per automation You can now cap AI credit use for each automation. All limits are optional and can be combined: - Per run: the run stops when it reaches the limit. - Daily, weekly or monthly: once the limit is hit, new runs do not start until the period resets. Automations without limits keep running as they do today. GitHub also added 20 new GitHub tools, such as merging pull requests, retrying workflow runs and hiding comments, and support for tools from your own MCP servers (connectors that give an agent access to other systems). You pick exactly which tools each automation may use. ### Automations that propose changes to themselves GitHub says automations leave signals on GitHub that show how well they perform: whether people change the labels a triage automation applied, whether developers accept a review automation's comments, whether maintainers merge a performance fix. A self-improving automation uses those signals to propose changes to the original automation's prompt, tools or triggers. GitHub notifies you, and you accept or reject each change before it takes effect. ### Agent Merge on pull requests Agent Merge was already in the GitHub Copilot app and Visual Studio Code. It is now also built into pull requests on GitHub. You choose "Watch and fix" in the merge box, then pick whether Copilot should handle failing GitHub Actions workflows (automated checks), merge conflicts, or both. When a chosen blocker appears, Copilot starts a cloud development environment and works on the fix. It can be combined with auto-merge, so GitHub merges the pull request once all requirements are met. It is available on paid Copilot plans, subject to organization and enterprise policies. GitHub's pages do not say whether these features are in preview or generally available, so do not assume either. ## What does this mean for a team? ### Decide who may create automations A shared automation belongs to the repository and spends the organization's credits. Anyone with write access can edit it, so changing what it does is easy. Treat the prompt like code: decide who may edit it and who reviews changes. The change history helps, but only if somebody reads it. ### Set a cap before you switch one on Consider a per-run limit and a monthly limit on every new automation. An automation that triggers on a busy event, such as every label change, can run far more often than you expected, and a cap puts a ceiling on that. Look at the numbers after the first week and adjust. ### Remember that outside text can start the work Triggers from Jira, Sentry or PagerDuty mean text written outside your team can reach an agent that has tools. A ticket or error message can contain instructions that the agent mistakes for yours. This risk is known as prompt injection. The tool picker is your main control: give each automation only the tools its job needs, and be careful with the ones that can merge pull requests or hide comments. ### Keep a person in the loop on self-changes The self-improvement feature stops at a proposal. Keep it that way: have the owner of each automation read every proposed change to its prompt, tools or triggers rather than accepting them in bulk. ### Be careful with chains Chained automations can set off one another. Keep the default of "Only users" unless you have a reason to change it, and put a cap on any automation that another one can trigger. ## How does Atlas handle this? Atlas does not run standing automations that start from events in GitHub, Jira or monitoring tools. What it does today is keep its AI engineers on a board of tasks, with an optional daily budget that warns at 50% and 80% and pauses the team at 100%. Its landing train merges up to six finished branches, runs the project's own checks once on the result, and splits a red batch until it finds the branch that broke it. Event-started work with its own spending cap is coming to Atlas, built in, so it needs no setup on your side. Until then, you can use Copilot Automations on a repository alongside Atlas, and keep Atlas's board for the build work. You can read more on the [Atlas home page](https://bridge-terminal.com/atlas/). ## Conclusion The 28 October update turns Copilot Automations from a personal helper into something a team can own, trigger from many sources and cap. That makes background agents easier to adopt and easier to get wrong. Before anyone creates a shared automation, agree who edits it, set a spending limit, and give it the fewest tools that let it do the job. ## Questions people ask ### What are GitHub Copilot Automations? They are workflows that combine a prompt, a trigger and a set of allowed tools, which Copilot runs in the cloud on its own. A trigger is the event that starts the work, such as a pull request being marked ready for review or an alert from a monitoring tool. ### Can I limit how much a Copilot automation spends? Yes. Since 28 October 2026 you can cap AI credits per run, per day, per week or per month, in any combination. When a period limit is reached, new runs do not start until it resets. Automations without limits run as they did before. ### What is a shared Copilot automation? It is an automation owned by the repository instead of one person. Anyone with read access can see it, anyone with write access can edit it, and credits are charged to the repository's owner. It keeps running if its creator leaves. An administrator must enable a policy first in organization-owned repositories. ### What does Agent Merge do? It watches an open pull request and, when a blocker you chose appears (failing GitHub Actions workflows, merge conflicts or both), starts a cloud environment and works on a fix. It is available on paid Copilot plans, subject to organization and enterprise policies. ### Do self-improving automations change themselves without approval? No. According to GitHub, they only propose changes to the original automation's prompt, tools or triggers. GitHub notifies you, and you accept or reject each proposal before it takes effect. ## About Atlas: Standing jobs with a spending cap, coming to Atlas Today Atlas keeps its AI engineers on a task board, with an optional daily budget that warns at 50% and 80% and pauses the team at 100%. Event-started jobs with their own spending cap are coming to Atlas, built in, so they need no setup. Until then, run Copilot Automations beside Atlas. — https://bridge-terminal.com/atlas/ ## Sources - [New tools, triggers, and cost controls for Copilot Automations (GitHub changelog, 28 Oct 2026)](https://github.blog/changelog/2026-10-28-new-tools-triggers-and-cost-controls-for-copilot-automations) - [Build shared workflows for your team with Copilot Automations (GitHub changelog, 28 Oct 2026)](https://github.blog/changelog/2026-10-28-build-shared-workflows-for-your-team-with-copilot-automations) - [Copilot Automations now learn from outcomes and self-improve (GitHub changelog, 28 Oct 2026)](https://github.blog/changelog/2026-10-28-copilot-automations-now-learn-from-outcomes-and-self-improve) - [Agent Merge watches and fixes pull requests in the cloud (GitHub changelog, 28 Oct 2026)](https://github.blog/changelog/2026-10-28-agent-merge-watches-and-fixes-pull-requests-in-the-cloud) _Researched and drafted with Claude, then checked against the sources above. Atlas is an independent product, not affiliated with Anthropic or OpenAI._ ## Related - [Copilot Fusion: Model Routing for AI Coding Explained](https://bridge-terminal.com/atlas/blog/copilot-fusion-model-routing-explained/) - [How to Report a Bug to an AI Coding Agent](https://bridge-terminal.com/atlas/blog/how-to-report-a-bug-to-ai-coding-agent/) - [Can an AI Coding Agent Work Overnight? A Plain Guide](https://bridge-terminal.com/atlas/blog/can-ai-coding-agent-work-overnight-unattended/)