Sequential Agent Chain Communication Flow

[AMGMNPLK]

We're having an issue with sequential agent communication in our Agency Swarm implementation. Sometimes the message routing works as expected, other times it breaks the chain.

Setup:
We have a chain of agents that should process messages in sequence:

InitialAgent -> ProcessorA -> ProcessorB -> ProcessorC -> Final Output

Current Implementation:

1. Agency Configuration:

agency = Agency([
    orchestrator,  # Entry point
    [initial_agent, processor_a],
    [processor_a, processor_b],
    [processor_b, processor_c],
    [processor_c, orchestrator]
])

2. Base Agent Implementation:

class BaseAgent(BaseAgent):
    def handle_message(self, message: dict) -> str:
        try:
            initial_response = super().handle_message(message)
            validated_response = self.response_validator(initial_response)
            
            self.send_message(
                recipient="ProcessorA",
                message=validated_response,
                my_primary_instructions="Process this message and forward to ProcessorB",
                additional_instructions="Maintain the message format"
            )
            
            return None
            
        except Exception as e:
            logger.error(f"Error: {str(e)}")
            return None

3. Custom SendMessage Implementation:

class ChainMessage(SendMessage):
    recipient: str = Field(
        default="ProcessorA",
        description="Next processor in chain."
    )

    @model_validator(mode='after')
    def validate_recipient(self):
        if self.recipient != "ProcessorA":
            raise ValueError("Messages must be sent to ProcessorA first")
        return self

    def run(self):
        self.recipient = "ProcessorA"
        if isinstance(self.message, str):
            self.message = {
                "content": self.message,
                "metadata": {
                    "requires_chain": True,
                    "chain_sequence": [
                        "ProcessorA",
                        "ProcessorB",
                        "ProcessorC"
                    ]
                }
            }
        return super().run()

Issue:

• Sometimes the message correctly flows through the chain: InitialAgent -> ProcessorA -> ProcessorB -> ProcessorC
• Other times it returns to the Orchestrator instead of following the chain
• No error messages when it fails
• Behavior is inconsistent

Questions:

1. Is there a specific way to enforce sequential message routing in Agency Swarm?
2. Should we be using a different approach for agent-to-agent communication in a chain?
3. Are we missing any configuration in the Agency setup to ensure consistent message routing?
4. Is there a way to debug the message routing to understand why it sometimes goes back to Orchestrator?

Any guidance would be greatly appreciated!

[bonk1t]

Hey @AMGMNPLK,

Thank you for raising this important question about sequential flow support in Agency Swarm. Below are some clarifications and recommendations:

1. Is there a specific way to enforce sequential message routing in Agency Swarm?

Currently, there isn’t a straightforward or efficient way to enforce strictly sequential message routing in Agency Swarm. A sequential flow implies no real decision-making among agents—essentially a prompt chain—which isn’t considered truly “agentic.”

2. Should we be using a different approach for agent-to-agent communication in a chain?

In short, we don’t recommend a purely sequential/prompt-chain approach if you want to leverage the framework’s agentic capabilities. However, if you do want to adapt this into a working solution using Agency Swarm, you’ll need an orchestrator agent that triggers other agents in the correct order based on your instructions and the input request.

You can also pass shared context between tools by using shared_state, as described in the advanced usage documentation.

3. Are we missing any configuration in the Agency setup to ensure consistent message routing?

For clarity:

• You need to connect your entry point (the “user proxy”) to your other agents; otherwise, you’ll only be interacting with your main agent.
• Each conversation flow creates a separate thread, forming a directed graph (a tree). The response of the second agent will always return to the first agent in each chain.
• This makes purely sequential flows less efficient in this framework.

4. Is there a way to debug message routing to understand why it sometimes goes back to the Orchestrator?

Yes. You can use:

• Agency.run_demo()
• Agency.demo_gradio()

These methods let you visualize all the messages and function calls within the framework, helping you see exactly how and where the routing happens.

Additional Notes

• Could you describe your use case? This will help us propose an optimal agentic workflow.
• If you truly need a simple sequential chain with no branching or decision-making, consider using regular chat completion calls instead of the Agency Swarm framework.

We hope this clarifies the current limitations and offers a path forward. Let us know how we can further assist you!

[AMGMNPLK]

This is my use case:

Here's a top-down hierarchical diagram of our agent structure:

graph TD
    subgraph "Layer 1: Entry"
        User[User]
        O[Agent O]
    end
    
    subgraph "Layer 2: Core"
        A[Agent A]
        B[Agent B]
    end
    
    subgraph "Layer 3: Phases"
        direction LR
        C[Agent C]
        D[Agent D]
        E[Agent E]
        F[Agent F]
        G[Agent G]
        H[Agent H]
        I[Agent I]
        J[Agent J]
    end
    
    subgraph "Layer 4: Specialists"
        direction LR
        K[Agent K]
        L[Agent L]
        M[Agent M]
        N[Agent N]
        P[Agent P]
    end

    %% Connections between layers
    User --> O
    O --> A & B
    
    %% Core to Phases
    A --> C & D & E & F & G & H & I & J
    
    %% All Phases connect to first specialist
    C & D & E & F & G & H & I & J --> K
    
    %% Specialist chain
    K --> L
    L --> M
    M --> N
    N --> P
    P --> O

    %% Shared Context connections omitted for clarity
    
    %% Styling
    classDef layer1 fill:#e6f3ff,stroke:#333,stroke-width:2px
    classDef layer2 fill:#f0fff0,stroke:#333,stroke-width:2px
    classDef layer3 fill:#fff0f0,stroke:#333,stroke-width:2px
    classDef layer4 fill:#f0f0ff,stroke:#333,stroke-width:2px
    
    class User,O layer1
    class A,B layer2
    class C,D,E,F,G,H,I,J layer3
    class K,L,M,N,P layer4
    

Loading

Layer Description:

Layer 1: Entry

• User interaction
• O: Orchestration

Layer 2: Core

• A: Analysis
• B: Information Management

Layer 3: Phases

• C through J: Phase-specific handlers
• Each handles different stages
• Activated based on A's analysis

Layer 4: Specialists

• K through P: Sequential enhancement chain
• Each adds specialized layer
• Must process in order
• Returns to O after completion

Key Features:f

• Hierarchical structure
• Clear layer separation
• Sequential specialist chain
• Feedback loop to orchestrator
• All phases funnel to specialist chain

This top-down view helps visualize the hierarchical nature of the system while maintaining the sequential flow through the specialist chain.