What causes "Agent with name {id.type} is not of type {type.__name__}" in microsoft/autogen?

Pass the type argument matching what the factory for that id actually constructs

microsoft/autogen · error · TypeError

Agent with name {id.type} is not of type {type.name}

Error message

Agent with name {id.type} is not of type {type.__name__}

What it means

After resolving the agent via _get_agent, try_get_underlying_agent_instance(type=T) performs isinstance(agent_instance, type) and raises TypeError(f"Agent with name {id.type} is not of type {type.__name__}") when the instance belongs to a different class. Unlike error 884 (which uses exact type equality on factories), this check is isinstance-based, so subclasses pass; only genuinely unrelated classes fail.

Source

Thrown at python/packages/autogen-ext/src/autogen_ext/runtimes/grpc/_worker_runtime.py:818

        if agent_id.type not in self._agent_factories:
            raise ValueError(f"Agent with name {agent_id.type} not found.")

        agent_factory = self._agent_factories[agent_id.type]
        agent = await self._invoke_agent_factory(agent_factory, agent_id)
        self._instantiated_agents[agent_id] = agent
        return agent

    # TODO: uncomment out the following type ignore when this is fixed in mypy: https://github.com/python/mypy/issues/3737
    async def try_get_underlying_agent_instance(self, id: AgentId, type: Type[T] = Agent) -> T:  # type: ignore[assignment]
        if id.type not in self._agent_factories:
            raise LookupError(f"Agent with name {id.type} not found.")

        # TODO: check if remote
        agent_instance = await self._get_agent(id)

        if not isinstance(agent_instance, type):
            raise TypeError(f"Agent with name {id.type} is not of type {type.__name__}")

        return agent_instance

    async def add_subscription(self, subscription: Subscription) -> None:
        if self._host_connection is None:
            raise RuntimeError("Host connection is not set.")

        message = agent_worker_pb2.AddSubscriptionRequest(subscription=subscription_to_proto(subscription))
        _response: agent_worker_pb2.AddSubscriptionResponse = await self._host_connection.stub.AddSubscription(
            message, metadata=self._host_connection.metadata
        )

        # Add to local subscription manager.
        await self._subscription_manager.add_subscription(subscription)

    async def remove_subscription(self, id: str) -> None:
        if self._host_connection is None:
            raise RuntimeError("Host connection is not set.")

View on GitHub (pinned to 027ecf0a37)

Solutions

Pass the type argument matching what the factory for that id actually constructs
Make config-driven factories deterministic per key, or register distinct type names per implementation
Catch TypeError and handle the mixed-type case explicitly in generic tooling
Add unit tests asserting try_get_underlying_agent_instance(id, ExpectedClass) succeeds for every registered type you rely on

Example fix

# before
agent = await runtime.try_get_underlying_agent_instance(AgentId('critic', 'default'), AssistantAgent)  # TypeError

# after
agent = await runtime.try_get_underlying_agent_instance(AgentId('critic', 'default'), CriticAgent)

Defensive patterns

Strategy: type-guard

Validate before calling

from autogen_core import AgentId
async def is_agent_of_type(runtime, id: AgentId, cls) -> bool:
    try:
        await runtime.try_get_underlying_agent_instance(id, cls)
        return True
    except (LookupError, TypeError):
        return False

Type guard

async def is_agent_of_type(runtime, id, cls) -> bool:
    try:
        await runtime.try_get_underlying_agent_instance(id, cls)
        return True
    except (LookupError, TypeError):
        return False

Try / catch

try:
    agent = await runtime.try_get_underlying_agent_instance(id, AssistantAgent)
except TypeError:
    agent = None  # present but different class; handle or skip

Prevention

Pass the concrete class the factory constructs for that id
Keep one implementation class per agent type name
Test the (id, class) pairs you depend on in CI
Subclasses are fine (isinstance) — unrelated classes are not

When it happens

Trigger: Requesting type=AssistantAgent for an id whose factory constructs CriticAgent; factories whose returned class varies by configuration/key so the same type name yields different classes for different keys; passing the wrong type parameter while iterating heterogeneous agents.

Common situations: Generic management code that assumes all agents under an id are one class; config-driven factories that switch implementation by agent key; refactors renaming or splitting agent classes while callers keep the old type argument.

Related errors

AI-assisted analysis of microsoft/autogen@027ecf0a37 (2026-08-15). Data as JSON: /api/errors/6c1281c032aa2940. Report an issue: GitHub.