Contributing to Open-Source Agent Projects

The AI agent market hit $7.84 billion in 2025 and is projected to reach $52.62 billion by 2030. Every bit of infrastructure behind that growth is being built in public, on GitHub, by people who started exactly where you're standing now: staring at a codebase, wondering where to click first. Contributing to these projects isn't like contributing to a typical open-source library, and treating it that way is the fastest route to a closed pull request.

What makes agent codebases structurally different from typical open-source projects

Most open-source projects give you a library or a tool. You call a function, it does a thing, you move on. Agent frameworks don't work that way. They're runtimes. They coordinate language model calls, memory, tool use, and control flow across time, which means the thing you're reading isn't a static piece of logic, it's a system making decisions in a loop.

Four layers show up in nearly every agent codebase, and you need to know which one you're touching before you touch it:

• Orchestration layer, where the agent decides what to do next (planning loops, breaking a task into steps)
• Tool and integration layer, how the agent actually acts on the world, through function calling, MCP servers, or API wrappers
• Memory layer, the split between short-term context and long-term retrieval. This is the least standardized part of the whole stack. Mem0, a project focused purely on solving agent memory, has climbed past tens of thousands of GitHub stars, ahead of several full frameworks, which tells you the community still hasn't agreed on the right answer here
• Evaluation layer, how correctness gets measured. Most frameworks are still figuring this out, which sounds like a weakness but is really an open door for contributors

Here's the part that trips people up: agent test suites are often non-deterministic. A failing test might mean you broke something. Or it might mean the model gave a slightly different, still-correct answer, and the test wasn't built to handle that kind of variance. Before you panic over a red X in CI, find out how the maintainers actually treat flaky tests. Some have documented tolerance thresholds. Others expect you to ask.

State management deserves its own paragraph, because most agent bugs aren't logic errors, they're state errors. Open Hands, an open-source platform for running autonomous coding agents, surfaces this distinction through its sandboxed execution model. LangGraph handles this with a stateful graph model. CrewAI handles it with a role and goal model. These aren't interchangeable ideas dressed in different syntax; they're different philosophies about how an agent should hold onto what it's doing, and confusing one for the other while reading someone else's code will send you down the wrong path fast.

One more wrinkle: a single agent framework often spans multiple repositories. A core runtime here, a UI there, an evaluation harness somewhere else, protocol adapters in a fourth place. Before you open an issue in the wrong repo and wait a week for someone to redirect you, figure out who owns what.

Practical advice, and it's the single best use of your first hour on any of these projects: trace one full agent run through the code, start to finish. Not the README. The actual execution path. Follow the request from entry point to output. You'll learn more in twenty minutes of that than in two hours of skimming docs.

The projects worth understanding before choosing where to contribute

These projects don't just differ in purpose. They differ in culture, review pace, and what kind of work actually gets merged.

LangGraph sits around 34,000 GitHub stars with 34.5 million monthly downloads, and it hit its 1.0 release in October 2025 with production deployments at Uber, LinkedIn, and Klarna. That maturity cuts both ways: the codebase is well-established, which means contributions need to fit an existing graph model rather than reinvent it. Steeper learning curve, but a very stable target.

CrewAI has crossed 44,000 stars and pulls in 5.2 million monthly downloads, with an 82% task success rate in its own benchmarks. Its role and goal model is more approachable than a full graph abstraction, which makes it a strong pick if you want to understand agentic orchestration without climbing a wall first.

AutoGen, now branded AG2, sits at tens of thousands of stars, went production-ready in October 2025, and leads the GAIA benchmark for autonomous agent performance. It also signals something unusual for contributors: this is a team-oriented process, not a drive-by pull request shop.

MetaGPT, past 50,000 stars, organizes itself around a single idea: software is the output of structured team processes, or as the project puts it, Code = SOP(Team). Contributing here means understanding workflow structure first, individual agent logic second.

OpenAI's Agents SDK launched in March 2025, already sits at 26,900 stars and 10.3 million monthly downloads, and works across more than 100 different language models. Being younger means more greenfield opportunity, but also thinner documentation, so expect to do some archaeology.

Dify leads the pack on raw popularity, with 144,000 stars as of 2026, the largest count among agent-adjacent frameworks. Its workflow-builder orientation means most contributions land in the UI or integration layers rather than deep in agent core logic.

And then there's the growth chart nobody expected to move this fast. Between January and May 2026, Browser Use went from 10,000 to 50,000 stars, a fivefold jump. Playwright MCP went from 1,000 to 10,000, tenfold. Other breakout projects posted similarly dramatic star growth over the same period. Fast growth like that usually means active maintainers who respond quickly and genuinely need hands. It also means APIs that might look different in three months, so hold your assumptions loosely.

Worth noting that several other projects occupy adjacent space in the ecosystem, targeting organizations that want self-hosted, model-agnostic agent runtimes rather than managed services.

Pick your project the way you'd pick a gym: based on which muscle you actually want to build, not which one has the most people posting about it on social media.

MCP as one of the most accessible contribution surfaces in the agent ecosystem

The Model Context Protocol showed up in November 2024, introduced by Anthropic as an open standard for how AI systems connect to external tools and data. People call it "USB-C for AI applications," and the comparison actually holds up: one plug shape, works across many devices, nobody has to reinvent the connector every time.

In December 2025, MCP moved to the Agentic AI Foundation under the Linux Foundation, with OpenAI, AWS, Google, and Microsoft as founding members. That's vendor-neutral governance modeled on how Kubernetes and PyTorch operate, which means no single company gets to quietly bend the standard toward its own product line.

The growth here is genuinely wild. Within a few months of launch, over 1,000 community-built MCP servers existed. By late 2025, the ecosystem had expanded rapidly, with active public servers and SDK adoption spreading across Python and TypeScript.

Here's why MCP is the friendliest on-ramp in the entire agent ecosystem: every MCP server is a self-contained unit. You don't need to understand LangGraph's graph model or CrewAI's role system to build or improve one. You just need to understand the one tool or API your server connects to.

Concrete ways in: build a server for an API nobody's wrapped yet, improve error handling on an existing server, write usage examples for the SDK, or clean up interoperability rough edges between the Python and TypeScript implementations. And because MCP sits under Linux Foundation governance, the contribution process tends to be documented, not tribal knowledge you have to extract from a Discord history. For a first-time contributor to the agent world, that documentation gap alone is worth more than it sounds.

The AI slop crisis and what it actually means for anyone submitting a pull request

Across one million critical open-source repositories, AI-co-authored pull requests rose from a small fraction in October 2025 to a notably larger share by May 2026. Keep that trajectory going and agentic AI would be writing more pull requests than humans within a year. Maintainers noticed, and they didn't respond gently.

curl shut down its long-running bug bounty program. Other projects put in zero-tolerance policies against low-quality AI-generated submissions, with some auto-closing external pull requests entirely. The Jazzband Python collective shut down entirely in 2025, and its lead maintainer named unsustainable AI-generated spam as a primary reason. GitHub itself is reportedly building a maintainer "kill switch" for incoming pull requests. That's not a small list of grumpy volunteers. That's a pattern.

But the data has a wrinkle that matters a lot if you're the one submitting the PR. A May 2026 arXiv study (2605.22534, "Why Are Agentic Pull Requests Merged or Rejected?") looked at why agentic PRs actually got rejected, and the answer wasn't mostly "the code was bad." A notable share of rejections traced to workflow constraints rather than outright code failures, meaning the change itself might've been fine, but it showed up at the wrong time or skipped groundwork the maintainer expected to see first.

So the crisis isn't really about code quality falling off a cliff. What's exploded is volume. Maintainers are drowning, not because the average submission got dumber, but because there are so many more of them arriving. That distinction changes how you should think about your own submission. Maintainers are now pattern-matching for low-effort signals before they've even opened your diff. Show up looking like noise, and you'll get treated like noise, regardless of what your code actually does.

How to read a project before writing any code

Read the CONTRIBUTING file. Not skim it, read it. If a project has one, it's not a suggestion, it's the terms of engagement, and skipping it is the single fastest way to get your first PR bounced for reasons that had nothing to do with your code.

A handful of signals tell you whether a project is actually ready for outside contributors, or just says it is:

• Are "good first issue" and "help wanted" tags recently applied, or are they fossils from two years ago?
• How long does a typical PR sit before getting a merge decision? A long queue means the maintainers are stretched thin, and you should plan your patience accordingly
• Do maintainers ask clarifying questions on issues, or do threads just go silent? The former is a collaborative culture. The latter is a warning
• Pull up a handful of recently closed PRs and read the comment threads. What got pushback? Why?

For discovery, GitHub's own "good first issue" filter works, and so does CodeTriage, which matches your skill level to what a project actually needs. Most major agent frameworks also run a live Discord or Slack, and lurking there for a week teaches you more about maintainer temperament than any document will.

Agent projects specifically reward looking at the evaluation harness and test suite before anything else. That's where you find out what the maintainers actually care about measuring, which is often a different story than what the README is selling you. And check for an architecture decision record or a design doc folder. Projects that write down why they made a choice are dramatically easier to contribute to correctly, because you're not guessing at intent.

None of this is optional reading. Contributors who skip it make up a large share of the workflow-constraint rejections the arXiv study flagged, the "right change, wrong context" category. Reading first isn't slow, it's the fast path, it just doesn't feel like it in the moment.

Picking the right issue and scoping your first contribution

The most common failure mode isn't picking something too small. It's picking something too big. A contributor who tries to refactor an orchestration loop before understanding the state model underneath it produces scope creep, and scope creep is one of the rejection patterns the arXiv study calls out by name.

Good shapes for a first contribution tend to be small and specific:

• A failing test with a clean reproduction case
• A documentation gap, where the actual behavior and the written behavior don't match
• A tool integration or MCP server scoped to one specific API
• An evaluation improvement, like a new benchmark case or clearer result reporting
• A dependency or compatibility fix, a Python version bump or an LLM provider update

Before you claim an issue, comment on it. Ask if it's still open, whether there's a preferred approach, whether someone's already quietly working on it. Maintainers frequently want a description of your planned approach before they'll even assign the issue to you, and skipping that step reads as presumptuous.

AG2's two-hour-a-week expectation before scrum access is worth remembering here too: even a "first contribution" exists inside an ongoing relationship with the project, not a one-shot transaction you complete and disappear from.

For projects spread across multiple repositories, confirm which one actually owns the issue before you start writing code. Misrouted PRs waste everyone's time, yours included.

A useful gut check as you work: if your change touches more files than you planned to touch, more than two or three beyond scope, stop. Either you've drifted from the issue, or you've found a second problem worth its own separate ticket.

The process norms specific to agent framework reviews

Open a draft pull request early. This is close to universal advice across maintainers of major agent frameworks, and for good reason: a draft lets someone give you feedback on direction before you've sunk hours into an implementation that might get rejected on approach alone. A two-paragraph comment describing your plan costs nothing. A 500-line PR that gets rejected for going the wrong way costs your whole afternoon.

Reviewers on agent projects watch for a specific set of things that don't come up as often in ordinary software review:

• Test fakery. Does your test actually check agent behavior, or does it just confirm a function got called? Maintainers here are sharp about tests that pass by mocking away the exact thing they're supposed to verify
• Non-determinism handling. If your change touches agent output, explain how your tests accounted for probabilistic behavior. Silence on this point reads as either inexperience or corner-cutting
• License conflicts. Agent frameworks integrate with a lot of LLM providers under a lot of different licenses. Check before you add a new dependency, not after
• Mismatch between description and diff. If your PR description says one thing and the actual changes do something broader, maintainers notice, and it costs you credibility on your next submission too

The real test maintainers apply, though, is simpler than any checklist: can you explain every line of your own change? Maintainers report spotting AI-generated PRs almost instantly, not from the code itself, but from the contributor's inability to answer a basic follow-up question about it. That's the tell. Not the syntax, the silence when someone asks "why this way?"

Agent project maintainers are frequently volunteers with day jobs in AI engineering, so response times vary. Follow up politely after a reasonable wait; don't read a quiet inbox as rejection. And expect revision. Most merged PRs go through at least one round of changes, and reviewer feedback is meant as collaboration, not a verdict on your competence.

Using AI coding tools without becoming part of the problem

Using an AI tool to draft a first pass, debug a cryptic error, or get oriented in an unfamiliar corner of a codebase is fine, and nobody serious is arguing otherwise. What's actually causing the crisis described earlier is submitting output you haven't read and can't explain, then hoping the reviewer won't ask a follow-up question.

That's the whole test, really: if a reviewer asks why you made a change, "the AI suggested it" isn't an answer. You have to own the reasoning, the same way you'd own it if you'd written every line by hand. Nobody's checking whether a tool touched your code. They're checking whether a human understood it before it left their machine.

Use the tools to move faster through the parts of the work that are mechanical: syntax, boilerplate, first-draft explanations of a function you're still puzzling out. Don't use them to skip the part where you actually understand what you're submitting. That part was never optional, and the maintainers drowning in slop right now are the ones who'll notice fastest if you try.