Stephen O’Grady recently argued that AI agents may be becoming the new New Kingmakers. His point is that agents are no longer just helping developers write software. They are increasingly choosing technologies, frameworks, and services themselves, which means some of the power that shifted toward developers over the past few decades may now be shifting again.
I think that argument has another implication for open source. As agents become participants in software development, what happens if open source communities allow them to participate in processes designed to be governed by humans?
How would existing human governance work if AI agents were allowed to participate?
That is the question I keep coming back to. If communities choose to welcome agents, the same governance should apply. What may need to change is how explicitly those rules are expressed, so that agents can operate within them without blurring the fact that humans remain the decision-makers and ultimately accountable for what is accepted into the project. One possible answer is that governance increasingly needs to become an interface. Not an interface in the traditional software sense, and not necessarily a new file format or another standard. I mean something more fundamental: governance needs to become something that both humans and machines can discover, understand, and act within.
That may sound like a subtle distinction, but I don’t think it is. For most of the history of open source, we’ve had a fairly straightforward mental model. People write code. People open issues and pull requests. People review contributions. People become maintainers. People vote. People make decisions. And people are accountable for those decisions. The governance structures that open source projects and foundations have developed over the past few decades are built around that model.
That model is starting to change.
AI agents can already read repositories, modify code, run tests, open pull requests, respond to review comments, and interact with the systems around a project. O’Grady points to a broader shift in which products ranging from databases to development infrastructure are being rebuilt specifically for agents, which are increasingly making technology choices that used to belong to developers.
By “participants,” I don’t mean that an agent becomes a member of a community in the same sense that a person does. I mean something more practical. If communities permit it, agents could contribute work, interact with project infrastructure, prepare proposals, gather information, respond to other participants, and potentially initiate actions that have consequences for the project.
But participation is not authority, and it is certainly not accountability.
Those distinctions would matter a great deal.
The ability to act is not the authority to decide
One of the things that strikes me about agents is the growing gap between their ability to act and their authority to decide. An agent might technically have permission to perform an action without actually having the authority to make the decision behind that action.
We already understand this with humans. A contributor can open a pull request, but that doesn’t mean they can merge it. A maintainer may have write access to a repository, but that doesn’t mean they can unilaterally change a project’s governance. A project leader might be able to make certain decisions while others require a vote, consensus, or some other form of collective approval. Technical access and organisational authority are not the same thing.
Agents make that distinction even more important because their ability to act can be dramatically greater than that of an individual human. They can operate continuously, interact with many systems, process huge amounts of information and execute actions at machine speed. None of that gives them authority.
The ability to act is not the authority to decide.
I think that may become one of the defining principles of the agentic era. And there is another question underneath it: on whose behalf is the agent acting, and who is accountable for what it does?
An agent might be acting on behalf of an individual contributor, a company, a project team or perhaps some future automated service operated by the community itself. Those are materially different situations. Identity, delegation, and accountability therefore become part of the governance problem too. An agent doesn’t simply need to know what it is allowed to do. The community may also need to know who authorised it to do it and who remains responsible for the result.
Open source already has a lot of the answer
The interesting thing is that open source communities have already done much of the hard work. We have governance documents, contribution processes, defined roles and responsibilities, maintainers and project leaders, elections, review requirements, intellectual property processes, and security processes. We have rules about when an individual can act and when a decision requires collective agreement. We have spent decades figuring out how communities of people can collaboratively produce software while distributing authority, maintaining accountability, and resolving disagreements.
The problem is that most of this governance was written for people. A human contributor can read a project handbook, infer a fair amount from context, and ask another person when something is unclear. If a community allows an autonomous agent to act within its processes, that agent would need something more explicit. It would need to work out which rules apply to it, what it is authorised to do, who has authority over the next step, what evidence is required, when a decision needs to be escalated, and when it simply needs to stop.
In other words, governance needs to become understandable to machines.
This is where things like AGENTS.md become interesting. They provide a predictable way to tell coding agents how to work within a repository: coding conventions, testing requirements, build instructions and other project-specific guidance. That’s useful, but it addresses only part of the problem.
An agent can understand how a project wants it to work without understanding how the project makes decisions. Those are very different things. Who can contribute? Who can review? Who can approve? Who can become a maintainer? Who is the agent acting on behalf of? Which decisions require a vote or consensus? What evidence has to exist before an action can proceed? When does the agent need to involve a human? Who is accountable for the action? Where is the decision recorded?
Those aren’t implementation details. They are the constitutional layer of an open source community.
And today that layer is usually expressed through prose, convention, institutional memory and a collection of project-specific systems. Humans are quite good at piecing those things together. Machines may not be.
Governance as an interface
This is why I think there is potentially something bigger here than adding another file to a repository. Governance has traditionally been treated primarily as documentation for people. In an agentic world, it may also need to function as an interface.
I’m deliberately not arguing that the answer is a particular file format. Maybe there will eventually be a GOVERNANCE.md. Maybe parts of governance end up expressed in YAML or JSON. Maybe projects expose a standard discovery endpoint. Maybe existing tools evolve to handle all of this. The implementation is less interesting to me than the underlying requirement: if a community permits an agent to act within its processes, that agent should be able to discover the rules governing its participation.
That means understanding its role, the authority attached or delegated to it, the process required before an action can proceed, the evidence that must exist, the points at which a human or governing body must become involved, who is ultimately accountable, and where the resulting decision is recorded.
Imagine an agent identifies a bug and develops a fix. It runs the test suite and prepares a pull request. Nothing particularly novel there. But then the governance layer begins. Is the agent authorised to submit the contribution? If it is acting on behalf of a contributor, can that authority be established? Does the change require additional review? Are there intellectual property or security checks that need to happen? Who is allowed to approve it? Does the decision require a vote? Does some part of the decision specifically require human judgement? And where should the outcome be recorded?
If the answers already exist in the governance of the project, an agent should ideally be able to discover them and operate within them. If it can’t, we have a problem.
And that problem is not necessarily an AI safety problem in the conventional sense. An agent could be completely secure and still violate the governance of an open source project. It could bypass a required review, mistake repository access for decision-making authority, misunderstand someone’s role, or act beyond the authority delegated to it. Those are governance failures.
We’re starting to see pieces of this problem emerge across open source. Researchers have proposed an Agent Governance Manifest to make contribution risk, evidence requirements, human review, and maintainer decision authority more explicit. The Apache Software Foundation is exploring how AGENTS.md can make contribution rules and human approval boundaries explicit for AI agents, while the TODO Group is examining how agents affect open source management, contribution workflows, governance, and provenance. These are encouraging signs. But they also point to a broader question: beyond telling an agent how to contribute safely, can we make the governance of the community itself understandable to it?
The governance should govern the agent
This is also why I’m cautious about the phrase “governance for AI agents.” The important thing is not to create a parallel system in which autonomous agents somehow acquire independent governance authority. The existing governance of the community should govern the agent.
If the community authorises it, an agent could prepare a contribution, collect evidence, perform routine checks, identify the appropriate reviewers, route a decision and explain what it did. It may even be able to act autonomously in areas where the community has explicitly authorised autonomous action. But when it reaches a boundary that belongs to a person, a role or the community itself, it stops.
The agent doesn’t become the decision-maker simply because we gave it access to GitHub.
That sounds obvious, but I’m not convinced our current infrastructure makes it obvious enough for autonomous systems.
Why open source foundations should care
I think open source foundations are particularly well placed to explore this, not because foundations have some monopoly on good governance, but because mature foundations have spent decades turning collaboration into explicit institutional machinery. Their governance tends to be documented. Roles are defined. Processes are published. Decisions are expected to be transparent. Authority is intentionally distributed. Governance itself is developed collaboratively rather than defined by the product rules of a commercial platform.
That gives foundations something valuable: real governance systems that can be examined, tested and made more explicit. It also gives them a potentially important neutral role. If agents increasingly become intermediaries between people and software, there is a risk that the rules governing participation simply become whatever a handful of AI platforms decide they should be.
Open source communities should probably retain control over that boundary themselves. That is partly a question of neutrality. It may increasingly also be a question of sovereignty. A community should be able to say: these are our roles, these are our rules, this is how authority works here, and these are the conditions under which humans or machines may participate.
The agent should adapt to the governance of the community, not the other way around.
This is testable
The good news is that we don’t need to answer all of this theoretically. We can test it.
Take a handful of real open source projects with different governance models and give an agent a realistic contribution task. See whether it can discover the relevant rules, determine what it is authorised to do and on whose behalf, complete any required checks, identify who controls the next decision, and recognise when it must stop and involve a human. Then, afterwards, see whether a human can reconstruct what the agent did, why it did it, and under whose authority.
The results would be interesting almost regardless of the outcome. Maybe existing governance documentation works perfectly well. Maybe it simply needs to become more explicit. Maybe we discover that projects express common governance concepts in wildly different ways. Or maybe there is eventually an interoperability problem that justifies a common vocabulary or specification.
I wouldn’t start by assuming we need another standard. I would start by asking whether governance designed for human communities would remain legible if some of the actors operating within those communities were machines.
That is a much more interesting question.
When agents join the community
O’Grady’s “new New Kingmakers” argument is fundamentally about changing power dynamics. Agents are becoming increasingly influential in deciding what technologies are discovered and used. I think open source should be asking a related question about participation: what would happen if those same agents began interacting with the communities that produce the software?
I don’t think the answer is unchecked autonomy, and I don’t think it is putting a human approval button in front of every action an agent takes. If a community chooses to permit agent participation, the interesting space lies between those extremes. The community could authorise agents to perform defined actions and prepare or route decisions where human judgement is required. Authority and delegation would need to be explicit, accountability would remain with people and organisations, and agents would stop when they reached the limits of their authority.
Open source has always been about more than source code. It is also a collaborative model for distributing authority, building trust, and making decisions among people who may never work for the same organisation. If communities choose to allow agents to participate, that system may need to become legible to them too.
The interesting idea isn’t governance for machines. It’s governance that machines can understand and participate in, without forgetting who’s actually in charge.
