Coordination Strategies: Centralized vs. Decentralized Communication

Once you have defined your agent roles (Supervisor, Worker, Evaluator), the next challenge is Coordination. How does Agent A tell Agent B that the task is finished? How does Agent C access the data produced by Agent A?

In the Gemini ADK world, there are two primary communication patterns: Centralized (Hub-and-Spoke) and Decentralized (Peer-to-Peer). In this lesson, we will analyze these strategies, explore the "Blackboard" pattern for shared state, and learn how to prevent "Agent Loop Deaths" where your AI team gets stuck talking in circles.

---

1. Centralized Coordination (Hub-and-Spoke)

In this pattern, all communication flows through a single Supervisor Agent.

How it works:

• Step 1: Supervisor asks Worker A for research.
• Step 2: Worker A gives research ONLY to the Supervisor.
• Step 3: Supervisor digests the research and sends a summary to Worker B for drafting.

Pros:

• Maximum Control: The Supervisor acts as a semantic filter, preventing "Noise" from one worker from overwhelming another.
• Single Point of Truth: The state of the entire project is held in the Supervisor's context.

Cons:

• Supervisor Bottleneck: If the Supervisor is slow or hits its token limit, the whole system stalls.

graph LR
    subgraph "Centralized"
    A[Worker 1] <--> S[Supervisor]
    B[Worker 2] <--> S
    C[Worker 3] <--> S
    end
    
    style S fill:#4285F4,color:#fff

---

2. Decentralized Coordination (Peer-to-Peer)

In this pattern, agents talk directly to each other without a manager.

How it works:

• Step 1: Agent A finishes its task.
• Step 2: Agent A calls Agent B directly via a tool (e.g., handoff_to_coder).
• Step 3: Agent B processes the data and hands it off to Agent C.

Pros:

• Speed: No middleman slowing things down.
• Autonomy: Agents can decide who is the best person for the next step.

Cons:

• Complexity: Much harder to debug. If the system fails, you have to trace the "Hand-offs" through multiple separate logs.
• Drift: Without a supervisor, the agents might slowly wander away from the original user goal.

---

3. The "Blackboard" Pattern (Shared Memory)

Instead of passing massive blocks of text back and forth, advanced Gemini ADK systems use a Blackboard.

Concept:

The "Blackboard" is a shared database (Redis or SQL) where agents "post" their results.

• Worker A posts: {"stage": "research", "results": "..."}
• Worker B sees the post and starts: {"stage": "drafting", "depends_on": "research"}

Why this is great for Gemini: It allows you to use Flash for the workers (saving money) while keeping the shared state in a highly structured, queryable format.

---

4. Standardizing the Message (Inter-Agent JSON)

To ensure agents understand each other, you must define a Schema for their communication.

Bad Communication:

"Hey Researcher, give me some info on batteries."

Professional Communication (JSON):

{"intent": "RESEARCH_REQUEST", "topic": "Solid State Batteries", "requirements": ["cost", "density"], "format": "table"}

By using structured JSON for inter-agent talk, you reduce the "Hallucination" rate of the hand-off.

---

5. Preventing "Agent Loop Death"

A "Loop Death" occurs when two agents get into an argument or a recursive cycle.

• Agent A: "I have finished the code. Review it."
• Agent B: "There is a typo. Fix it."
• Agent A: "I fixed it. Review it." (But it didn't actually fix it).
• Agent B: "There is still a typo. Fix it."

The "Breaker" Strategies:

1. Turn Limits: Force the loop to break after 5 turns and call a human.
2. State Checking: If the "Observation" from a tool hasn't changed in 2 turns, the Supervisor should "Intervene" or "Reset" the worker.

---

6. Implementation: A Shared State "Blackboard"

Let's look at how we might implement a simple shared state object in Python for our agents.

class Blackboard:
    def __init__(self):
        self.state = {}

    def post_update(self, agent_name: str, key: str, value: str):
        print(f"[Blackboard] {agent_name} updated {key}...")
        self.state[key] = value

    def read_key(self, key: str):
        return self.state.get(key, "NOT_FOUND")

# Global Instance
shared_data = Blackboard()

# Agent A's Tool
def researcher_tool(topic: str):
    # Do research...
    shared_data.post_update("Researcher", "research_results", f"Facts about {topic}")
    return "Research complete. Posted to Blackboard."

# Agent B's Tool
def writer_tool():
    research = shared_data.read_key("research_results")
    if research == "NOT_FOUND":
        return "ERROR: No research found on the blackboard!"
    # Write blog...
    return f"Blog based on: {research}"

---

7. Coordination Archetypes: Pipelines vs. Orchestras

1. The Pipeline: Agent A -> Agent B -> Agent C. (Simple, predictable).
2. The Orchestra: The Supervisor (Conductor) brings in different workers as needed. (Complex, highly intelligent).

---

8. Summary and Exercises

Coordination turns a group of agents into a Unified System.

• Centralized is the best starting point for most developers (Hub-and-Spoke).
• Decentralized is for high-speed, high-autonomy scenarios (Peer-to-Peer).
• Blackboards solve the "State Scaling" problem by moving data out of the prompt and into a database.
• Standardized JSON ensures inter-agent clarity.

Exercises

1. Coordination Choice: You are building an agentic translation system that translates text into 10 different languages. Would you choose a Centralized or Decentralized coordination pattern? Why?
2. Loop Debugging: Imagine a "Researcher" and an "Editor" are arguing about the length of a summary. Write a "System Interrupt" rule for the Supervisor that would break this loop.
3. Blackboard Design: Design a JSON schema for a "Task Board." What fields (e.g., status, assigned_to, output_pointer) are necessary to coordinate a team of 3 agents?

In the next module, we leave the "Design" behind and start building: Building Your First Agent with Gemini ADK.