Who owns the bot when its author leaves? GitHub's agentic workflows and shared automations answer differently

Every engineering organization has a script that only one person understood, running under that person’s token, until the day they left. Agent automations are about to multiply that problem, because they are easy to create and do more than scripts did.

GitHub’s October 28 releases are interesting less for what the agents can do than for how they answer the ownership question. There are now two serious ways to run reasoning-based automation on GitHub, and they make different choices.

The two options

GitHub Agentic Workflows, now generally available. You write the automation in a Markdown file in natural language, and it compiles into a standard GitHub Actions workflow. Typical uses are issue triage, CI failure analysis, documentation updates and test writing. The agent runs with read-only permissions by default, in a sandboxed container behind an agent workflow firewall; anything it wants to change passes a “safe outputs” validation step and a dedicated threat detection job before it is applied. GA adds self-hosted runners on Actions Runner Controller, isolation in a micro-VM, enclaves to prevent leaks in cross-repository workflows, and a cost forecast command. The default engine is the Copilot CLI, which needs a Copilot license; you can bring another coding agent.

Shared Copilot Automations, rolling out. These combine a prompt, triggers and allowed tools into a workflow that runs in GitHub’s cloud. A shared automation belongs to the repository, not its creator. Its actions appear as Copilot, its AI credits are billed to the repository’s owner, anyone with write access can edit it, and if the creator leaves, it keeps running with a history of how its prompt, tools and triggers changed. In organizations, an admin has to enable the policy that bills the cloud agent to the organization.

GitHub also added self-improvement to Automations. You can create a pair: the main automation and a weekly one that analyzes outcomes (whether people changed the labels it applied, accepted its review comments, merged its pull requests) and proposes changes to its prompt, tools or triggers. You accept or reject each proposal.

Five questions that decide

1. Where must it run? If the automation touches code or data that must stay on your infrastructure, Agentic Workflows on self-hosted runners keeps it inside your existing Actions policies. Shared Automations run in GitHub’s cloud.
2. What may it write? Agentic Workflows starts from read-only and validates outputs. For a shared automation, the allowed tools list is the boundary; review it like a permission grant, because it is one.
3. Who answers for it? Repository ownership solves the departure problem, but “Copilot did it” is not an accountable party. Name a human owner in the repository for each shared automation, as you would for a service.
4. Who pays? Both bill AI usage, to different places. Run gh aw forecast for workflows; set budgets on the organization for automations before teams discover them.
5. How does it change? An automation that proposes its own improvements needs the same review as a code change, because it is one. Outcome signals are proxies: a review bot can raise its acceptance rate by commenting less. Look at what the proposal stops doing, not only at the metric it improves.

Treat automations as services with owners

We have argued that verification capacity, not generation, sets the pace of AI in production, and automations that write changes are where that limit shows first. GitHub’s releases give teams the pieces: compiled definitions in version control, read-only defaults, validated outputs, repository ownership and reviewable proposals. What they do not supply is the inventory. Ask each repository owner to list the automations that act in their repository, the identity each acts as, its owner and its monthly spend. The first list will be longer than anyone expects, and that is the point of making it.

Accenture reports large gains from Agentic Workflows in one team, including AI authoring 91% of commits and production errors falling from about 11,000 a day to under 1,000. Those are one team’s self-reported figures. Your own baseline, measured before the automations arrive, is the only comparison that will hold up.