Skip to content

Docs needed for PR #2086: AutoGen v0.4/AG2 are now unimplemented stubs, new AutoGenFamilyAdapter router, autogen_v2 alias, resolve_alias() protocol method, conditional autogen-tool registration #718

Closed
#719
Closed
Docs needed for PR #2086: AutoGen v0.4/AG2 are now unimplemented stubs, new AutoGenFamilyAdapter router, autogen_v2 alias, resolve_alias() protocol method, conditional autogen-tool registration#718
#719
Labels
claudeTrigger Claude Code analysisdocumentationImprovements or additions to documentation

Description

@MervinPraison
MervinPraison
opened on Jun 22, 2026

Source change

Upstream PR: MervinPraison/PraisonAI#2086 — fix: Wrapper layer: stub framework adapters, orchestrator-side version dispatch, and unconditional autogen-tool registration
Upstream issue: MervinPraison/PraisonAI#1590
Merged: 2026-06-22 to main (head 03d43a4acfddfcbae0acfae7740c7a73bc7e9c92)
Related (still open): Docs issue #615 (PR #1988) — same autogen.mdx file has an unresolved merge conflict that this PR's documentation work also needs to address.

PR #2086 implements the three fixes proposed in issue #1590. The change is user-visible and behaviour-changing, not just an internal refactor:

  1. AutoGen v0.4 and AG2 adapters now raise NotImplementedError at runtime instead of returning a "not yet implemented" success-shaped string. Any user currently relying on framework: autogen_v4 or framework: ag2 (the placeholder one) will see an exception on the next run.
  2. auto mode now prefers v0.2 over v0.4. Previously AUTOGEN_VERSION=auto would route to v0.4 if it was importable (and silently land on the stub). Now v0.4 is treated as unavailable (implemented = False) and v0.2 is the auto-pick.
  3. New family-router adapter AutoGenFamilyAdapter with name = "autogen". framework: autogen no longer maps directly to v0.2 — it maps to the family adapter, which dispatches via AUTOGEN_VERSION (now accepts v0.2, v0.4, ag2, auto).
  4. New direct alias autogen_v2. AutoGenAdapter.name was renamed from "autogen" to "autogen_v2" so it can be addressed unambiguously. framework: autogen_v2 skips the family router and pins v0.2 directly.
  5. New Protocol method FrameworkAdapter.resolve_alias() -> str. Returns the concrete adapter name to dispatch to. Default implementation returns self.name. Family adapters override it to consult env vars / config.
  6. Performance: autogen-tool adapter registration is now framework-scoped. AgentsGenerator.__init__ only calls register_builtin_autogen_adapters() when framework in {"autogen", "autogen_v2", "autogen_v4", "ag2"}. CrewAI / praisonai users no longer pay this hot-path cost.

AI-agent placement reminder (AGENTS.md §1.8): place all new pages in docs/features/. Do not write under docs/concepts/. Update docs.json under the Features group only.

TL;DR — what to do

Action Page Folder Why
🚨 FIX MERGE CONFLICT framework/autogen.mdx docs/framework/ Lines 60–98 still contain raw <<<<<<< HEAD / ======= / >>>>>>> origin/main markers. Same blocker as issue #615 — must be resolved before this PR's content lands.
🚨 REWRITE — major behaviour change framework/autogen.mdx docs/framework/ The page currently presents AutoGen v0.4 and AG2 as fully working. Per PR #2086 they raise NotImplementedError. Add an unimplemented warning and remove the detailed "How v0.4 works" / "How AG2 works" feature descriptions (or move them under "Future" with explicit not-yet-shipped callouts).
UPDATE — version selection table framework/autogen.mdx docs/framework/ AUTOGEN_VERSION now accepts ag2 as a value. auto now prefers v0.2 (because v0.4/ag2 are stubs). Update the precedence table to match SDK truth.
UPDATE — framework name list framework/autogen.mdx and framework-availability.mdx docs/framework/, docs/features/ New framework name autogen_v2 is registered in the registry alongside autogen. Document the distinction (autogen = family router; autogen_v2 = pinned v0.2).
UPDATE — resolve_alias() protocol features/framework-adapter-plugins.mdx docs/features/ Add the new resolve_alias() -> str method to the protocol table. Show AutoGenFamilyAdapter as the canonical worked example. Note it coexists with resolve_variant(config, registry) from PR #1988 (issue #615).
UPDATE — conditional registration features/tool-registry-autogen-migration.mdx docs/features/ The legacy approach (registry.register_builtin_autogen_adapters() called unconditionally on every AgentsGenerator()) is no longer how the orchestrator behaves. CrewAI/praisonai users do not trigger it. Document that callers who construct tools outside framework dispatch and want the autogen wrappers must register them manually.
NO new file — — All updates land in existing pages.

Summary of code changes (verified against PR #2086 diff)

# Change Source file Doc action
1 AutoGenV4Adapter is now a stub. implemented: bool = False; is_available() returns False; run() raises NotImplementedError("AutoGen v0.4 adapter is not yet implemented. Use framework='autogen' (v0.2) or pin AUTOGEN_VERSION=v0.2."). All ~150 lines of the prior v0.4 implementation (arun, _sanitize_agent_name_for_autogen_v4, RoundRobinGroupChat wiring) were removed. src/praisonai/praisonai/framework_adapters/autogen_adapter.py (lines ~159-205) REWRITE framework/autogen.mdx v0.4 section
2 AG2Adapter is now a stub. Same implemented: bool = False marker; run() raises NotImplementedError("AG2 adapter is not yet implemented. Use framework='autogen' (v0.2) or pin AUTOGEN_VERSION=v0.2."). All ~150 lines of the prior AG2 implementation (LLMConfig resolution, Bedrock support, GroupChat wiring) were removed. src/praisonai/praisonai/framework_adapters/autogen_adapter.py (lines ~215-260) REWRITE framework/autogen.mdx AG2 section
3 AutoGenAdapter.name renamed from "autogen" to "autogen_v2". The v0.2 implementation itself is unchanged; only the registry key changed. src/praisonai/praisonai/framework_adapters/autogen_adapter.py (line 18) UPDATE framework/autogen.mdx (new alias) and framework-availability.mdx (if it lists adapter names)
4 New router AutoGenFamilyAdapter with name = "autogen". Exposes is_available() (any variant available), resolve_alias() (string name), and resolve(*, config=None) (concrete adapter instance). run() raises RuntimeError — router must not be called directly. src/praisonai/praisonai/framework_adapters/autogen_adapter.py (lines ~262-end) NEW section in framework/autogen.mdx ("How the autogen family router works") + worked example in framework-adapter-plugins.mdx
5 AUTOGEN_VERSION accepts new value ag2. Behaviour: if ag2 requested but not available, logs a warning and still returns "ag2" (caller will hit NotImplementedError because the AG2 adapter is a stub). Same warning-then-fallthrough pattern applies to v0.2 and v0.4. src/praisonai/praisonai/framework_adapters/autogen_adapter.py (lines ~290-308, resolve_alias) UPDATE framework/autogen.mdx version precedence table
6 auto mode prefers v0.2. Order: v2 → v4 (with warning "installed but not yet implemented, falling back") → ag2 → ImportError. Critical reversal from the previous "prefer v4" behaviour. src/praisonai/praisonai/framework_adapters/autogen_adapter.py (lines ~310-322, resolve_alias) UPDATE framework/autogen.mdx
7 ImportError with full install hints when no AutoGen variant is installed. Message lists all three extras (praisonai[autogen], praisonai[autogen-v4], praisonai[ag2]). src/praisonai/praisonai/framework_adapters/autogen_adapter.py (lines ~324-331) UPDATE framework/autogen.mdx troubleshooting section
8 New Protocol method resolve_alias() on FrameworkAdapter and BaseFrameworkAdapter. Returns concrete adapter name string. Default implementation on BaseFrameworkAdapter returns self.name. Note: coexists with resolve_variant(config, registry) introduced by PR #1988 — they are not the same thing. src/praisonai/praisonai/framework_adapters/base.py (lines ~118-210) UPDATE framework-adapter-plugins.mdx protocol table + worked example
9 New registry entry autogen_v2 alongside autogen. autogen → AutoGenFamilyAdapter (router); autogen_v2 → AutoGenAdapter (concrete v0.2). src/praisonai/praisonai/framework_adapters/registry.py (lines ~22-49) UPDATE framework/autogen.mdx framework-name table
10 Conditional autogen-tool registration. AgentsGenerator.__init__ now only calls self.tool_registry.register_builtin_autogen_adapters() when framework in {"autogen", "autogen_v2", "autogen_v4", "ag2"}. Previously called on every construction regardless of framework. src/praisonai/praisonai/agents_generator.py (lines ~238-243) UPDATE features/tool-registry-autogen-migration.mdx

🚨 1) FIX MERGE CONFLICT — docs/framework/autogen.mdx

Same blocker as issue #615. Lines 60–98 still contain raw merge-conflict markers (<<<<<<< HEAD, =======, >>>>>>> origin/main). The Mintlify renderer will choke on this regardless of the new content this issue adds.

Resolution path (slightly different from #615 because PR #2086 changes the env-var semantics):

  • Keep the ## Auto Version Selection block from HEAD, but rewrite the precedence table per PR #2086 (see step 3 below) — the existing wording says "prefer v0.4" which is now wrong.
  • Keep the ### Async Usage block from origin/main but reposition it under a "Future / Not Yet Implemented" callout — await praisonai.arun(..., framework="autogen_v4") will now raise NotImplementedError, so the code sample is misleading without the caveat.
  • Remove all three marker lines.

🚨 2) REWRITE — docs/framework/autogen.mdx AutoGen v0.4 and AG2 sections

Why

The current page (lines ~102-272) describes AutoGen v0.4 and AG2 as fully working with detailed feature lists ("AssistantAgent + RoundRobinGroupChat", "AWS Bedrock with AG2", "GroupChatManager", "register_for_llm / register_for_execution"). After PR #2086, calling either raises NotImplementedError — the code that implemented all of those features has been deleted.

A user reading the current page will:

  1. Run pip install "praisonai[autogen-v4]"
  2. Write framework: autogen_v4 in YAML
  3. Run praisonai agents.yaml --framework autogen_v4
  4. Get NotImplementedError("AutoGen v0.4 adapter is not yet implemented. Use framework='autogen' (v0.2) or pin AUTOGEN_VERSION=v0.2.")

This is exactly the "documentation lied to me" gap PR #2086 was filed to close — it must not leak back through the docs.

Required edits

a) Add a prominent <Warning> callout at the top of the page (after the hero diagram):

AutoGen v0.4 (framework: autogen_v4) and the standalone AG2 adapter (framework: ag2, distinct from the framework: ag2 backend listed in the framework table) are not yet implemented in PraisonAI. Calling them at runtime raises NotImplementedError with a pointer back to framework: autogen (v0.2). Track the upstream issue #1590 for status.

b) Replace the ## AutoGen v0.4 section (currently lines ~102-172). Drop all of:

  • The "How AutoGen v0.4 Works" sequence diagram (the diagram describes code that no longer exists).
  • The "AutoGen v0.4 Features" bullet list (model config, agent creation, sanitization rules, tool registration via .run(), RoundRobinGroupChat, max-turns limit).
  • The "Async Usage" example (await praisonai.arun(..., framework="autogen_v4") — this now raises).

Replace with a short stub:

## AutoGen v0.4

<Warning>
The `autogen_v4` adapter is currently a stub. `framework: autogen_v4` raises `NotImplementedError` at runtime. Use `framework: autogen` (or `framework: autogen_v2`) for AutoGen v0.2 support.
</Warning>

When implemented, AutoGen v0.4 will use `autogen-agentchat` + `autogen-ext` with `OpenAIChatCompletionClient` and `RoundRobinGroupChat`. The placeholder adapter is registered in the framework registry but `AutoGenV4Adapter.implemented = False` causes `is_available()` to return `False`, so `framework: autogen` and `AUTOGEN_VERSION=auto` will not route to it.

Track [issue #1590](https://github.com/MervinPraison/PraisonAI/issues/1590) for implementation status.

c) Replace the ## AG2 (Full) section (currently lines ~175-276). Drop all of:

  • The "How AG2 Works" sequence diagram.
  • The "AG2 Features" bullet list (LLM resolution order, AWS Bedrock support, tool registration patterns, agent name sanitization, GroupChat wiring, result extraction).
  • The "AWS Bedrock with AG2" YAML example.

Replace with the same stub pattern as v0.4. Critical: call out that there is a real framework: ag2 backend listed in the framework table, distinct from the placeholder AG2Adapter. The current page conflates them.

## AG2

<Warning>
The standalone `AG2Adapter` is currently a stub. `framework: ag2` (when routed through the placeholder adapter) raises `NotImplementedError`. Use `framework: autogen` for AutoGen/AG2-family support via v0.2.
</Warning>

`AG2Adapter.implemented = False`, so `is_available()` returns `False` and `AUTOGEN_VERSION=ag2` will log a warning + fall through.

Track [issue #1590](https://github.com/MervinPraison/PraisonAI/issues/1590) for implementation status.

d) Update the existing "Not-yet-implemented adapters" block (currently lines ~356-360). The wording is partially correct but predates PR #2086. Refresh the error messages verbatim to match SDK truth:

  • v4: NotImplementedError("AutoGen v0.4 adapter is not yet implemented. Use framework='autogen' (v0.2) or pin AUTOGEN_VERSION=v0.2.")
  • ag2: NotImplementedError("AG2 adapter is not yet implemented. Use framework='autogen' (v0.2) or pin AUTOGEN_VERSION=v0.2.")

3) UPDATE — docs/framework/autogen.mdx Auto Version Selection table

Why

PR #2086 changes both the accepted values and the auto preference. The existing table says auto prefers v0.4 — now it prefers v0.2.

SDK ground truth (read before writing)

src/praisonai/praisonai/framework_adapters/autogen_adapter.py:290-322 (AutoGenFamilyAdapter.resolve_alias):

def resolve_alias(self) -> str:
    requested = os.getenv("AUTOGEN_VERSION", "auto").lower()
    v2_available = AutoGenAdapter().is_available()
    v4_available = AutoGenV4Adapter().is_available()  # currently always False (implemented=False)
    ag2_available = AG2Adapter().is_available()       # currently always False (implemented=False)

    if requested == "v0.2":
        if not v2_available: logger.warning(...)
        return "autogen_v2"
    if requested == "v0.4":
        if not v4_available: logger.warning(...)
        return "autogen_v4"
    if requested == "ag2":
        if not ag2_available: logger.warning(...)
        return "ag2"

    # auto
    if v2_available: return "autogen_v2"
    elif v4_available:
        logger.warning("AutoGen v0.4 is installed but not yet implemented, falling back.")
        return "autogen_v4"
    elif ag2_available: return "ag2"

    raise ImportError("No AutoGen variant is available. Install with: ...")

Required edits

Replace the existing | AUTOGEN_VERSION | Behaviour | table with:

AUTOGEN_VERSION Behaviour
auto (default) Pick autogen_v2 if available, else autogen_v4 (with warning), else ag2. If none available, raise ImportError with install hints.
v0.2 Force autogen_v2. Warns if not installed; still returns the name (caller will hit ImportError at run).
v0.4 Force autogen_v4. Currently raises NotImplementedError at run because the adapter is a stub.
ag2 Force ag2. Currently raises NotImplementedError at run because the adapter is a stub.

Add a <Note>:

auto no longer prefers v0.4. Until the v0.4 adapter is implemented (implemented = True), it is treated as unavailable and auto lands on v0.2.

Add an explicit "raised when nothing is installed" example:

# No AutoGen variant installed
# framework: autogen → ImportError:
#   No AutoGen variant is available. Install with:
#     pip install 'praisonai[autogen]' for v0.2
#     pip install 'praisonai[autogen-v4]' for v0.4
#     pip install 'praisonai[ag2]' for AG2

4) UPDATE — docs/framework/autogen.mdx framework-name table

Why

PR #2086 registers autogen_v2 as a direct alias for the v0.2 adapter, alongside autogen (which now resolves through the family router). Today's table only lists autogen, autogen_v4, ag2.

SDK ground truth

src/praisonai/praisonai/framework_adapters/registry.py:22-49:

def _autogen_loader():
    from .autogen_adapter import AutoGenFamilyAdapter
    return AutoGenFamilyAdapter

def _autogen_v2_loader():
    from .autogen_adapter import AutoGenAdapter
    return AutoGenAdapter

_BUILTIN_ADAPTERS = {
    "crewai": _crewai_loader,
    "autogen": _autogen_loader,      # Family adapter for version resolution
    "autogen_v2": _autogen_v2_loader, # Direct access to v2
    "autogen_v4": _autogen_v4_loader,
    "ag2": _ag2_loader,
    "praisonai": _praisonai_loader,
}

Required edits

Replace the existing framework table (lines ~54-58) with:

Framework Install Best For Status
framework: autogen pip install "praisonai[autogen]" (v0.2) Family router — picks variant via AUTOGEN_VERSION ✅ Working (v0.2 only)
framework: autogen_v2 pip install "praisonai[autogen]" Pin v0.2 directly, skip the router ✅ Working
framework: autogen_v4 pip install "praisonai[autogen-v4]" Future AutoGen v0.4 support 🚧 Stub — raises NotImplementedError
framework: ag2 pip install "praisonai[ag2]" Future AG2 support 🚧 Stub — raises NotImplementedError

Update the decision-tree mermaid diagram (lines 37-52) to match: drop the "new project → ag2" recommendation; the only working path today is v0.2.

5) UPDATE — docs/features/framework-availability.mdx (autogen_v2 entry)

Why

The page lists known probe names but does not currently mention autogen_v2 as a framework name. It also says nothing about the implemented = False marker that overrides import-based availability.

Required edits

a) Add autogen_v2 to the "Known Probe Names" table (lines ~58-70):

Wait — autogen_v2 is an adapter name, not a probe name in _framework_availability. The probe name remains autogen (it imports autogen). The adapter AutoGenAdapter is now named autogen_v2. Clarify this distinction in a small <Note>:

The adapter names (autogen, autogen_v2, autogen_v4, ag2) are registered in FrameworkAdapterRegistry. They are not the same as the probe names checked by _framework_availability. is_available("autogen") still tests import autogen (v0.2 package). Use the adapter's .is_available() method to test whether a specific adapter will dispatch successfully — it folds in the implemented marker.

b) Add a short "Adapter availability vs framework availability" subsection. Two distinct concepts now matter:

Question API
"Is the underlying package importable?" is_available("autogen") from _framework_availability
"Will calling adapter.run(...) actually work?" AutoGenV4Adapter().is_available() (folds implemented flag)

For v0.4 and ag2 today: the package may import successfully (is_available("autogen_v4") returns True) but the adapter still reports False because implemented = False. Document this carefully — it's the safety-by-default behaviour PR #2086 added.

6) UPDATE — docs/features/framework-adapter-plugins.mdx (resolve_alias protocol method)

Why

PR #2086 adds resolve_alias() -> str to the FrameworkAdapter Protocol and BaseFrameworkAdapter. This coexists with resolve_variant(config, registry) from PR #1988 (still open as issue #615). The two methods do different jobs:

Method Returns When to override
resolve_variant(config, registry) FrameworkAdapter instance Pick concrete adapter from YAML config (e.g. read autogen_version key)
resolve_alias() str (adapter name) Pick concrete adapter name from env vars / runtime state, leave instantiation to the orchestrator/registry

AutoGenFamilyAdapter uses resolve_alias() (reads AUTOGEN_VERSION env var) and is the canonical worked example.

SDK ground truth

  • src/praisonai/praisonai/framework_adapters/base.py:118-130 — new FrameworkAdapter.resolve_alias() Protocol method: 
    def resolve_alias(self) -> str:
    """Return the concrete adapter name to dispatch to (e.g. 'autogen_v4').
    Default: return self.name."""
    ...
  • src/praisonai/praisonai/framework_adapters/base.py:205-215 — BaseFrameworkAdapter default implementation: 
    def resolve_alias(self) -> str:
    """Return the concrete adapter name to dispatch to.
    Default: return self.name."""
    return self.name
  • src/praisonai/praisonai/framework_adapters/autogen_adapter.py:262-360 — full AutoGenFamilyAdapter definition (router pattern).

Required edits

a) Protocol method table — add a row:

| resolve_alias() | ❌ | Return the concrete adapter name to dispatch to (string). Default returns self.name. Override when your adapter is a router that picks a sibling adapter at runtime by name. |

b) Worked example — AutoGenFamilyAdapter as canonical family router:

import os
from typing import Dict, Any, Optional
from praisonai.framework_adapters.base import BaseFrameworkAdapter

class AutoGenFamilyAdapter(BaseFrameworkAdapter):
    """Router adapter for AutoGen family (v0.2, v0.4, AG2)."""

    name = "autogen"

    def is_available(self) -> bool:
        v2 = AutoGenAdapter()
        v4 = AutoGenV4Adapter()
        ag2 = AG2Adapter()
        return v2.is_available() or v4.is_available() or ag2.is_available()

    def resolve_alias(self) -> str:
        requested = os.getenv("AUTOGEN_VERSION", "auto").lower()
        # ... pick concrete name based on env var + availability ...
        return "autogen_v2"  # or "autogen_v4" / "ag2"

    def resolve(self, *, config: Optional[Dict[str, Any]] = None) -> "BaseFrameworkAdapter":
        adapter_name = self.resolve_alias()
        from .registry import get_default_registry
        return get_default_registry().create(adapter_name)

    def run(self, config, llm_config, topic) -> str:
        raise RuntimeError(
            "AutoGenFamilyAdapter.run() should not be called directly. "
            "The resolve() method should have been called first to get the concrete adapter."
        )

c) <Note> callout reconciling with resolve_variant:

resolve_alias() (added in PR #2086) and resolve_variant(config, registry) (added in PR #1988) are both present on the Protocol. Use resolve_variant when your family decision depends on YAML config keys; use resolve_alias when it depends on environment / runtime state. They are not mutually exclusive — AutoGenFamilyAdapter uses resolve_alias internally inside its own resolve(config=...) override.

d) Update the orchestrator sequence diagram to show that family adapters get resolve() called (which internally uses resolve_alias()), and the result is the concrete adapter that the orchestrator then calls .run() on.

7) UPDATE — docs/features/tool-registry-autogen-migration.mdx (conditional registration)

Why

The page's "Builtin Registration" example (lines 174-190) shows registry.register_builtin_autogen_adapters() as an idempotent call you can make from anywhere. After PR #2086 the orchestrator only calls it for autogen-family frameworks. CrewAI / praisonai users no longer trigger it automatically.

SDK ground truth

src/praisonai/praisonai/agents_generator.py:238-243:

# Only autogen-family adapters need the autogen tool shim
# Note: autogen_v2 is also part of the autogen family
if framework and framework in {"autogen", "autogen_v2", "autogen_v4", "ag2"}:
    self.tool_registry.register_builtin_autogen_adapters()

Required edits

a) Add a <Warning> near the "Builtin Registration" section:

Since PR #2086, AgentsGenerator.__init__ only calls register_builtin_autogen_adapters() when the chosen framework is in the autogen family (autogen, autogen_v2, autogen_v4, ag2). If you construct tools outside the orchestrator (e.g. using ToolRegistry directly with CrewAI or praisonai), and you want the autogen-shaped tool wrappers anyway, call registry.register_builtin_autogen_adapters() yourself.

b) Add a performance note:

This change closes a hot-path regression where every AgentsGenerator() construction triggered the praisonai_tools import chain (CodeDocsSearchTool, CSVSearchTool, DirectoryReadTool, PDFSearchTool, RagTool, ScrapeWebsiteTool, YoutubeChannelSearchTool, ...) regardless of framework. CrewAI/praisonai users now skip the import.

c) Update the "Common Patterns → Builtin Registration" example to show both behaviours:

from praisonai.tool_registry import ToolRegistry

# Inside an autogen-family framework: orchestrator does this for you
# (called automatically by AgentsGenerator.__init__ when framework in
#  {"autogen", "autogen_v2", "autogen_v4", "ag2"})

# Outside framework dispatch (e.g. you only use ToolRegistry directly):
registry = ToolRegistry()
registry.register_builtin_autogen_adapters()   # call this yourself if you want them

8) NOT touched by PR #2086

To keep the docs PR scoped: PR #2086 does not change these and the existing pages do not need updates from this issue:

Source files in PraisonAI to read before writing

Per AGENTS.md §1.1–§1.3 (SDK-first cycle), open these at head SHA 03d43a4acfddfcbae0acfae7740c7a73bc7e9c92:

  1. src/praisonai/praisonai/framework_adapters/autogen_adapter.py (whole file, ~360 lines after PR) — three adapters + family router. Read top-to-bottom.
  2. src/praisonai/praisonai/framework_adapters/base.py:118-215 — new resolve_alias() Protocol method + default implementation on BaseFrameworkAdapter.
  3. src/praisonai/praisonai/framework_adapters/registry.py:22-49 — autogen (family) and autogen_v2 (direct) registry entries.
  4. src/praisonai/praisonai/agents_generator.py:238-243 — conditional register_builtin_autogen_adapters() call.
  5. Diff for the full PR: https://github.com/MervinPraison/PraisonAI/pull/2086/files

Do not paraphrase the error messages — quote them verbatim where they appear in code samples (especially the NotImplementedError and ImportError text, since users will literal-string-search for them).

Acceptance criteria for the docs PR

  • docs/framework/autogen.mdx no longer contains <<<<<<< HEAD / ======= / >>>>>>> origin/main markers.
  • docs/framework/autogen.mdx has a prominent <Warning> at the top declaring v0.4 and standalone AG2 unimplemented.
  • docs/framework/autogen.mdx "AutoGen v0.4" and "AG2" sections do not describe features that no longer exist (RoundRobinGroupChat wiring, AWS Bedrock with AG2, GroupChatManager, etc.). The detailed feature lists are removed or moved under a "Future" header with explicit not-yet-shipped callouts.
  • docs/framework/autogen.mdx AUTOGEN_VERSION table includes ag2 as a valid value, and auto is documented as preferring v0.2.
  • docs/framework/autogen.mdx framework table lists autogen_v2 as a distinct framework name with status column.
  • docs/framework/autogen.mdx decision-tree mermaid diagram does not recommend ag2 or autogen_v4 for new projects (since both are stubs).
  • docs/framework/autogen.mdx <Async Usage> example for v0.4 is either removed or moved under a "not yet implemented" callout (since await praisonai.arun(..., framework="autogen_v4") raises).
  • docs/features/framework-availability.mdx distinguishes between "package importable" (is_available(name)) and "adapter will dispatch successfully" (adapter.is_available()), with an explicit note about the implemented = False marker.
  • docs/features/framework-adapter-plugins.mdx protocol table lists resolve_alias() -> str with a default-impl note (return self.name).
  • docs/features/framework-adapter-plugins.mdx worked example shows AutoGenFamilyAdapter as the canonical family-router pattern.
  • docs/features/framework-adapter-plugins.mdx has a <Note> reconciling resolve_alias() with resolve_variant(config, registry) from issue Docs needed for PR #1988: AutoGen YAML version field, FrameworkAdapter.resolve_variant() signature change, tool registry cache invalidation, ToolSource protocol, autogen.mdx merge-conflict cleanup #615 (both coexist on the Protocol; pick based on whether the routing decision depends on YAML config or env state).
  • docs/features/tool-registry-autogen-migration.mdx warns that register_builtin_autogen_adapters() is now conditional in the orchestrator (only autogen-family) and shows manual-registration code for non-orchestrator usage.
  • No new files in docs/concepts/ (per AGENTS.md §1.8).
  • No edits to docs.json "Concepts" group entries.
  • No edits to docs/js/ or docs/rust/ (auto-generated).
  • Mermaid diagrams use the standard palette (#8B0000 / #189AB4 / #10B981 / #F59E0B / #6366F1, white text).
  • All code samples copy-paste runnable — no your-key-here placeholders, all imports included, no broken from praisonai... paths.
  • Frontmatter intact on every edited page (title, sidebarTitle, description, icon).
  • Validate docs.json is valid JSON if touched.

Coordination with issue #615 (still open)

Issue #615 (PR #1988) and this issue (PR #2086) both edit docs/framework/autogen.mdx. They are not duplicates — PR #1988 added the YAML autogen_version: field and resolve_variant(); PR #2086 stubs v0.4/AG2, adds resolve_alias(), and renames the v0.2 adapter to autogen_v2. They are compatible but the work overlaps on:

Recommendation: tackle this issue's changes on top of issue #615's, not in parallel — sequence avoids three-way merges in autogen.mdx.

Out of scope (do not document)

  • AutoGenFamilyAdapter.resolve(config=...) internal logic beyond the worked example — the resolve_alias() + registry.create pattern is the documented surface; the inner mechanics belong in source.
  • The _async_bridge.run_sync fallback path inside AutoGenAdapter (v0.2) — internal; not user-facing.
  • Anything in docs/concepts/* — per AGENTS.md §1.8, AI agents must not write there.
  • TypeScript / Rust SDK docs (docs/js/, docs/rust/) — auto-generated; AutoGen does not exist in those SDKs.

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    claudeTrigger Claude Code analysisdocumentationImprovements or additions to documentation

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions