Contribution Policy

AG2 is what it is today because of its contributors. This page explains how contributions will work in the v1.0 era — what lives in Core, what lives as an Extension, and what we ask of contributors in each.

Why a new policy#

AG2 v1.0 is focused on production and scalability. Teams building real systems on AG2 need a foundation that is small, predictable, and dependable under load. Core is what those teams depend on, and keeping it tight is critical to the v1.0 release.

Over the years AG2 has grown to include many agents, tools, and integrations — many contributed by the community. That is a great strength, but has made the framework heavier than it needs to be and harder to evolve and support.

For v1.0, we want a focused Core that AG2 actively maintains, alongside a vibrant set of Extensions maintained by the contributors who care about them most.

Core and Extensions#

Core is the foundational AG2 Beta framework — maintained by AG2 with contributions from the community and AG2 team, kept lightweight, and held to a strict quality bar.

Today, everything shipped under autogen.beta is Core: the Agent runtime, primary LLM providers, common built-in tools, middleware, structured output, telemetry, history management, and the context and dependency-injection primitives.

Extensions are first-class components of the AG2 ecosystem — agents, tools, providers, middleware, and integrations that extend what you can build with Core. Most are community-contributed, but AG2 may also author Extensions where it makes sense (for example, integrations we want to ship without expanding Core's dependency surface). The defining characteristic of an Extension is who maintains it — every Extension has a named maintainer (AG2 or community) who commits to keeping it working. Typical Extensions include:

• Additional middleware
• LLM providers and third-party model gateways
• Third-party code executors and sandboxing backends
• Domain-specific tools and integrations
• Adapters for external frameworks and services

Reliance on a third-party SDK is a strong signal that something belongs in Extensions, but the deciding question is who is best placed to own it long-term — AG2, or a contributor closer to the integration. An Extension can be just as widely used and just as polished as anything in Core; what differs is the maintenance model.

Phase 1 — until v1.0#

Core and Extensions live in the same repository. Extensions go under autogen/beta/extensions/ and ship as part of pip install ag2. The contribution flow stays familiar during the transition.

Phase 2 — at v1.0#

• Core stays in this repository.
• Extensions move to a dedicated repository, with their own documentation alongside.
• A separate Extensions-archived repository holds Extensions that are no longer maintained. Archived Extensions remain available and can be revived (see Maintainership and inactivity).

Contributing to Core#

Core is held to the rigour AG2 contributors are used to:

• A core maintainer must agree to support the change.
• Tests with meaningful coverage of new behaviour.
• Type hints, docstrings, and the development standards outlined in documentation and AGENTS.md.
• Documentation updated in the same PR where applicable.
• New dependencies added sparingly — Core is intentionally lightweight.
• Security considered — changes must not weaken Core's security, and contributors are expected to assess the security impact of what they ship.

If you are unsure whether a change belongs in Core or as an Extension, open an Issue or draft PR first.

Contributing an Extension#

Extensions are held to the same quality bar as Core; the difference is that the maintenance commitment sits with the Extension's maintainer rather than with AG2. An Extension contribution must:

• Include documentation that lets a new user understand and use it — at minimum a module-level docstring summarising the Extension, docstrings on public classes and functions, and a page under the Extensions section of the docs. Following standards as noted in Code Documentation example.
• Include tests covering the Extension's behaviour.
• Pass code review by AG2 so we can confirm it is safe to ship alongside Core.
• Have a named maintainer (you, your team, or a designated successor) who agrees to:
  • respond to issues and PRs,
  • keep the Extension working with current Core releases, and
  • let us know if you can no longer maintain it, so we can find a new maintainer or move it to the archive.

AG2 facilitates Extension PR reviews, but ongoing bug fixes and evolution are the maintainer's role.

Contributing Examples and Showcases#

Full, runnable, examples and showcases, using Core or active Extensions, belong in the build-with-ag2 repository, not in Core or Extension repos. This keeps each codebase focused on framework code and gives examples a single, discoverable home.

When Core functionality is deprecated or Extensions are archived, corresponding Examples/Showcases will be removed from the Build-with-AG2 repository.

Maintainership and inactivity#

We do not expect anyone to maintain an Extension forever. What we ask is that maintainers tell us when they cannot continue, so users are not left guessing.

In Phase 2, an Extension is considered for archival if all of the following hold:

• It has been broken (failing CI against the latest Core, or an unresolved critical bug) for 30+ days,
• The maintainer has not responded to issues or PRs for 30 days, and
• A 30-day notice has been posted asking for a new maintainer.

If no one steps up, the Extension moves to Extensions-archived. Archived Extensions can be revived at any time (with a commitment to maintain it) — open an Issue and we will help bring it back.

Promoting an Extension to Core#

Promotion to Core is an exception, not a planned path. It requires a core maintainer willing to own the component, a track record of stability and adoption as an Extension, and compatibility with Core's dependency and quality expectations. If you think your Extension is a candidate, open an Issue and we will discuss.

Working together#

We are grateful for everyone who has contributed to AG2 — past, present, and future. This policy exists so AG2 can keep growing without losing the stability production users depend on, and so contributors have clear, fair expectations on both sides.

If anything is unclear or you have ideas to improve it, open an Issue or join us on Discord.

Code documentation example#

Below is a minimal sketch of AG2's coding documentation standard. It includes the AG2 copyright header and Google-style docstrings on the module, public classes, and public functions.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

# Copyright (c) 2026, AG2ai, Inc., AG2ai open-source projects maintainers and core contributors
#
# SPDX-License-Identifier: Apache-2.0

"""Acme search Extension for AG2.

Provides a tool that lets agents query the Acme Search API and
receive ranked search results with cited sources. Designed for agents that
need up-to-date web information without managing the HTTP client themselves.

Maintainer: <github-handle>
Docs: https://docs.ag2.ai/extensions/search-tools/acme
Examples: https://github.com/ag2ai/build-with-ag2/extensions/acme-search-tool
"""

from autogen.beta.tools import Tool

class AcmeSearch(Tool):
    """Tool that performs web searches via the Acme Search API.

    The tool issues a single ranked-search request per call. Deduplication
    and re-ranking of results are the agent's responsibility.

    Attributes:
        api_key: Acme Search API key. Sent in the ``Authorization`` header.
        max_results: Maximum number of results to return per query. Must be
            between 1 and 20 inclusive.
    """

    def __init__(self, api_key: str, max_results: int = 5) -> None:
        ...

    async def search(self, query: str) -> list["SearchResult"]:
        """Run a search against the Acme Search API.

        Args:
            query: The natural-language query to send.

        Returns:
            A list of ``SearchResult`` objects, ordered by relevance.

        Raises:
            AcmeSearchAPIError: If the upstream service returns a non-2xx
                status code or a malformed response payload.
        """
        ...