autogen - 💡(How to fix) Fix Feature proposal: Backpressure contract declarations for multi-agent coordination [3 comments, 4 participants]

Problem

In multi-agent AutoGen setups, agents that coordinate through message passing or tool calls have no way to express their capacity constraints as part of their definition. This creates a class of cascading failure that's hard to debug: Agent A retries when Agent B is saturated, each retry consumes Agent B capacity and generates more Agent A load, and the cascade amplifies until something times out or hits a hard resource limit.

The current workaround is to implement circuit breakers and backpressure logic inside the calling agent — but this means every agent that calls Agent B must independently discover and encode Agent B's capacity limits. When Agent B's capacity changes, every caller needs to update. The coupling is implicit and fragile.

Proposal

Add an optional capacity declaration to agent definitions, specifiable at the agent or team level:

# Agent-level capacity declaration
agent = AssistantAgent(
    name="data_processor",
    capacity=AgentCapacity(
        max_concurrent=3,           # max simultaneous tasks
        backoff_strategy="exponential",  # hint to callers: how to back off
        backoff_initial_ms=1000,
        backoff_ceiling_ms=30000,
        max_caller_retries=5        # callers should give up after N attempts
    )
)

The capacity declaration serves two purposes:

1. Introspection: Callers can query it via agent.capacity before making requests, and adapt retry behavior without hard-coding assumptions
2. Documentation: The declaration is visible in team configs, making capacity constraints auditable before deployment

Why the caller shouldn't own this

The backpressure spec belongs with the provider, not the consumer. If Agent B defines its capacity, Agent A doesn't need to know anything specific about Agent B — it just reads the contract and follows it. This is the same reasoning behind HTTP 429 (rate limiting) being a server-side responsibility: the server knows its limits, the client shouldn't have to guess.

For teams where multiple agents call the same subordinate agent, a shared contract avoids N implementations of the same retry logic.

Scope question

Happy to hear if this belongs in AgentChat's Team interface instead of (or in addition to) the individual agent level. Team-level capacity might make more sense for GroupChat patterns where load is distributed across team members.

Related: the discussion in #7265 about practical reliability patterns surfaces this as a recurring pain point in production setups.