How to Contribute to AAIF: The Real On-Ramp to All Five Projects

TL;DR - The Agentic AI Foundation splits cleanly in two. Its formal governance is organized through member companies and project committees. Its code and specifications live in five public projects: MCP, A2A, goose, AGENTS.md, and agentgateway. Individual engineers can contribute without joining AAIF, but each repository has its own contract. Read that contract before writing code.

Updated August 27, 2026 after Agent2Agent (A2A) joined AAIF as its fifth hosted project.

Most "how to contribute to a foundation" guides quietly assume the foundation is the thing you contribute to. For AAIF, that's misleading.

AAIF launched December 9, 2025 and put its structure in place fast: a Governing Board of nine, a Technical Committee with one representative per Platinum member, and seven working groups. Every one of those working groups is chaired by a Platinum member and open "to all membership levels" - which is to say, to members. Your employer joins; you don't.

The code is the opposite. Five hosted projects live in public GitHub repositories and accept community participation through their own issue, discussion, and pull-request processes. That asymmetry is the single most useful thing to understand before you spend a Saturday on this.

What does AAIF actually govern?#

Five hosted projects, as of August 27, 2026:

A2A is the newest hosted project. agentgateway joined in June 2026 as the fourth project; A2A followed on August 17, 2026 as the fifth. Any AAIF explainer that still puts A2A outside the foundation is now out of date.

Where does an individual actually fit?#

Three surfaces, in descending order of how open they are to you:

1. Project repos - fully open. Fork, issue, pull request. No membership, no permission.
2. Technical Committee meetings - biweekly, recorded and open to anyone to attend and observe on the LFX platform. You can't vote, but you can watch the requirements for new projects get set in real time. Underrated.
3. Working groups - member-organization territory, chaired by Platinum members. This is the surface an organization joins AAIF to reach.

So the honest sequence for an engineer is: land pull requests in a project first, observe the Technical Committee to learn where the standards are heading, and treat working-group participation as a company-level decision rather than a personal one.

Which project should you start with?#

Match the project to what you already do, because the review bar is high everywhere and domain familiarity is what carries you:

• You write Python and use MCP - the MCP python-sdk. It has clear issue labels and an unusually explicit contribution contract.
• You write Rust and care about infrastructure - agentgateway. It is the contribution surface nearest to Kubernetes and production traffic policy.
• You want the shortest possible first contribution - AGENTS.md. It's a spec plus a Next.js site; docs and compatibility fixes are real, mergeable contributions.
• You build agents day to day - goose. Most active repo, but the least forgiving of a large first pull request.
• You care about cross-framework interoperability - A2A. The protocol repo combines a normative protobuf definition, generated schema, specification text, and SDK-adjacent documentation.

What are the house rules, per project?#

This is the part that gets people's contributions closed. The five projects have genuinely different contracts, and they are explicit about them.

MCP python-sdk: an issue is mandatory, and declare your AI#

The most rule-dense project in the set, and the rules are unusually blunt:

• External pull requests need a linked issue and permission to proceed. A maintainer must assign the issue to you, unless the issue carries the help wanted label.
• good first issue is a difficulty signal, not an invitation to race. You still need to ask and be assigned before opening a pull request.
• ready for work describes the maintainers' internal queue. The label is not an open call for an external pull request.
• AI disclosure is mandatory. State how AI was used in the issue or pull request. The maintainers may close unmanaged autonomous submissions because the human contributor remains accountable for understanding, testing, and supporting the change.
• Anything touching the spec itself needs a SEP (spec enhancement proposal) first, not a pull request.

Their issue labels are useful, but each one answers a different question: good first issue describes complexity, help wanted opens an issue to external contributors, and ready for work tracks maintainer readiness. Read the label and the assignment state together.

goose: take an issue to Ready before code#

goose makes the pre-code workflow part of the contribution itself. New issues move through a public board: Inbox, Needs info, Accepted / design, and finally Ready. That sequence is how maintainers confirm the problem, scope, and implementation direction before someone spends time on a patch.

• Do not implement the change or open a pull request until the linked issue reaches Ready.
• Keep the pull request inside the scope agreed in the issue and explain how you verified it.
• A pull request without a Ready issue may be closed, even if the code works.
• AI-assisted development does not need a special disclosure, but the human contributor is responsible for every line, claim, and test result.

That process favors a well-scoped contribution with a shared design over a speculative patch. goose also documents a project ladder of Contributors, Maintainers, and Core Maintainers, with Core Maintainers owning overall technical direction.

A2A: keep the protocol definition, generated schema, and docs aligned#

A2A's repository is specification infrastructure, so a seemingly small wording change can have release implications.

• The normative protocol definition lives in specification/a2a.proto.
• Core specification changes use the docs(spec): commit scope; protocol-definition updates reserve feat: and fix:.
• If documentation changes protocol behavior, update the protobuf definition or its comments too so the release machinery sees the change.
• Build the docs with ./scripts/build_docs.sh, format with ./scripts/format.sh, and run the Docker-backed linter with ./scripts/lint.sh.
• Discussions are the right place for design questions; pull requests still require review.

This is a good home for developers who enjoy specification clarity, interoperability fixtures, conformance feedback, documentation, and SDK examples. It is a poor home for an implementation-first pull request that silently invents new wire behavior.

agentgateway: Rust, Conventional Commits, LF charter#

Standard Linux Foundation project mechanics:

• Fork, add an upstream remote, branch, rebase on upstream/main before pushing.
• Conventional Commits required: feat:, fix:, docs:, style:, refactor:, perf:, test:, chore:.
• Rust: make lint and make test must pass, and new functionality needs tests. UI: use the repository's Biome and pnpm workflow with pnpm check:fix, pnpm lint, and pnpm test:e2e.
• Governed by a formal Technical Charter under LF Projects, LLC. The Technical Steering Committee is the project's Maintainers, and its meetings are intended to be public.

Its contribution surface spans the Rust proxy, Kubernetes control plane, API definitions, policy, UI, tests, examples, and documentation.

AGENTS.md: the spec is the product#

A Next.js site plus the format itself. There's no CONTRIBUTING.md at the repo root, which in practice means normal GitHub etiquette: open an issue, keep the change focused.

Worth knowing before you pick it: this is a compact convention and documentation site, not a large runtime. Check the repository's current issues and recent review activity before estimating turnaround. Choose it for a focused documentation, tooling, or compatibility contribution whose value is clear without a broad implementation surface.

What does a first pull request look like mechanically?#

The same shape as any Linux Foundation project. Fork, branch, sign off, test, one thing per pull request:

# 1. Fork on GitHub, clone your fork, add upstream
git clone [email protected]:<you>/agentgateway.git && cd agentgateway
git remote add upstream https://github.com/agentgateway/agentgateway.git

# 2. Branch and commit with a Conventional Commit message (-s signs off for DCO)
git checkout -b fix/mcp-route-typo
git commit -s -m "docs: fix typo in MCP routing reference"

# 3. Run the project's gates BEFORE pushing
make lint && make test

# 4. Rebase on upstream, then push and open the pull request
git fetch upstream && git rebase upstream/main
git push origin fix/mcp-route-typo

Three things reviewers reward everywhere: a change that does one thing, a description linking the issue it closes, and green CI on the first push.

Watch the tempo before you pick#

Project activity varies more than the shared foundation branding suggests. Check the repository's latest commits, release cadence, open issues, and recently merged pull requests on the day you choose. Fast-moving projects require frequent rebases and reward narrow changes; settled specifications usually reward careful compatibility and documentation work. Neither is better, but they imply different review expectations.

What's the realistic first-90-days plan?#

• Weeks 1-2: pick one project. Build it from source, get its test suite green locally, and read its CONTRIBUTING.md end to end (they differ more than you'd expect). Join goose's Discord or the MCP community channels.
• Weeks 3-6: land one or two small changes: a doc fix, a test, or an appropriately scoped issue. For the python-sdk, ask to be assigned first, or choose an issue explicitly labelled help wanted; ready for work is the maintainer queue. Small and merged beats ambitious and abandoned.
• Weeks 7-12: take a slightly larger issue, start reviewing others' work, and sit in on a recorded Technical Committee meeting on LFX to see where the standards are going before they ship.

How does this connect to cloud-native work?#

The AAIF and CNCF worlds are not abstract neighbours. kagent, a CNCF Sandbox project, ships native MCP support, and agentgateway is the traffic layer that sits in front of exactly that kind of deployment. An engineer contributing to agentgateway and an engineer contributing to kagent are working two ends of the same stack.

That makes agentgateway the highest-leverage AAIF project for anyone already doing Kubernetes work: it compounds with what you know instead of starting a second, unrelated reputation from zero. If you want the sibling on-ramp, see How to Contribute to CNCF, and What Is the Agentic AI Foundation for the foundation context.

Frequently asked#

How do I contribute to the Agentic AI Foundation?#

Contribute directly to one of its five hosted project repositories on GitHub: MCP, A2A, goose, AGENTS.md, or agentgateway. No AAIF membership is required to contribute code, specifications, tests, examples, or documentation. Formal foundation governance uses its own member and committee processes.

Do I need to be an AAIF member to contribute code?#

No. Membership is an organizational tier that grants governance participation, such as board representation and working group seats. The five hosted projects accept individual contributors under their own contribution rules.

Which AAIF project is easiest to start contributing to?#

The MCP python-sdk has the clearest labelling (good first issue, help wanted, ready for work) and the most explicit contribution contract, but external work still requires either assignment or a help wanted issue. AGENTS.md has the smallest surface area for a focused documentation or compatibility contribution. goose has an explicit issue workflow: get the issue to Ready before writing code.

Will my AI-assisted contribution be rejected?#

Not simply because AI helped. The MCP python-sdk requires disclosure and may close unmanaged autonomous submissions. goose does not require AI disclosure, but it still requires a Ready issue and holds the human contributor responsible for the implementation and verification. In both projects, you need to understand and defend the change yourself.

References#

• A2A contribution guide
• MCP Python SDK contribution guide
• goose contribution guide
• AGENTS.md repository
• agentgateway contribution guide
• A2A joins AAIF's open agentic stack

Written by Aman Mundra - Founder & CEO, Welzin · Co-founder & CEO, CogNerd · ex-PayPal ML.