Workflow Information Flow Mapping

Introduction

In our previous lesson, we established the "job descriptions" for each agent in our system by translating a Product Requirements Document (PRD) into detailed agent specifications. We now have a team of specialized agents, each understanding its individual role, tools, and boundaries.

However, a team is only effective if its members can communicate and collaborate. This lesson addresses that critical next step. Our learning outcome is to map the information flow between agents in a multi-step workflow, identifying inputs, outputs, and handoff points.

We will move from designing agents in isolation to designing the network that connects them. Think of this as designing the communication protocols, data buses, and APIs for a distributed system. We'll explore the architectural patterns that govern how work is passed from one agent to another, how context is maintained, and how control is transferred, ensuring the entire workflow executes cohesively.

1. A Framework for Information Flow

Before diving into specific mechanisms, it's essential to have a high-level framework for thinking about how agents interact. As with any distributed system, the design of a multi-agent workflow can be analyzed along several key architectural dimensions.

This framework gives us three key questions to ask for any link between two agents in a workflow:

1. Execution: What is the temporal relationship? Is it a sequential handoff where Agent B starts only after Agent A finishes? Or is it concurrent, with multiple agents working in parallel?
2. Coordination: What is the "wiring" mechanism? Is Agent A calling Agent B as if it were a function (Agents as Tools)? Or is the flow dictated by a predefined Graph-based orchestration?
3. Interaction: What is the communication protocol? Are agents exchanging structured messages with defined schemas, or are they participating in a less formal chat?

These dimensions are not mutually exclusive; a real system is a composition of choices across all three. For example, a common pattern involves a central orchestrator using the Agents as Tools coordination model to trigger several specialist agents in a concurrent execution pattern, all communicating via structured messaging.

2. Visualizing Orchestration and Information Flow

A diagram is often the clearest way to represent information flow. Let's look at a canonical architecture that illustrates these concepts.

This diagram depicts a Centralized Orchestration pattern. Let's analyze its information flow using the framework from our reading:

• Flow Path: The user's request flows to the Orchestrator. The Orchestrator plans a series of steps and then sends specific task requests (inputs) to the Collaborator Agents. The Collaborators process these requests, interact with tools, and return results (outputs) to the Orchestrator. Finally, the Orchestrator synthesizes these results into a final response for the user.
• Execution: The Orchestrator might delegate tasks sequentially (e.g., analyze support tickets then create a pitch) or concurrently (e.g., check entitlements while analyzing tickets).
• Coordination: This is a prime example of the Agents as Tools pattern. The Orchestrator treats the Salesforce SDR Agent and Support Analysis Agent as callable specialists.
• Handoff Points: A handoff occurs every time the Orchestrator delegates a task to a Collaborator. For example, when the Orchestrator decides to "Create pitch," it hands off the necessary context (e.g., customer info, new offerings) to the "Pitch Deck Agent." This is a handoff of a specific task, not full ownership of the workflow.

3. The Mechanics of Handoffs and Context Passing

We've established the high-level patterns. Now, let's examine the low-level mechanics. How is information actually transferred between agents? How do we ensure the receiving agent has the necessary context without being overwhelmed by irrelevant history?

Your background in computer science will find parallels here with inter-process communication, API calls, and state management in distributed systems.

As the video explains, the two core mechanisms are:

1. Shared State: All agents have access to a common data structure (e.g., a dictionary, a JSON object, a "scratchpad"). An agent performs its task and writes its output back to this shared state. The next agent reads from this state to get its input and context. This is analogous to multiple processes communicating via shared memory.
2. Tool Call Parameters: The calling agent formats its request as a structured tool/function call, passing only the necessary information as parameters. The receiving agent executes and returns a value, just like a standard API. This is analogous to Remote Procedure Calls (RPC).

The choice between these two affects modularity and context management. Shared state can be simpler for closely-coupled agents, but tool calls create cleaner, more testable interfaces.

Let's see a more concrete implementation of these ideas, specifically focusing on the handoff itself.

This video crystallizes several key design patterns for mapping information flow:

• Handoffs as Tool Calls: Agents don't need global knowledge of the entire system. An agent can hand off a task to another simply by calling a "tool" that represents that other agent. This makes the system modular and extensible.
• Managing State Scope: The parent-subgraph model allows for a global state (e.g., the full user conversation history) managed by the parent orchestrator, while each specialist agent can maintain its own private internal state (e.g., intermediate tool call results). This prevents state pollution and keeps agents focused.
• Explicit Context Passing: Context is not passed implicitly. The handoff mechanism explicitly packages the relevant history (e.g., the entire message thread) and passes it to the next agent. This ensures the receiving agent has the information it needs to act.

4. A Formal Model: Communication Spaces

The patterns we've discussed can be formalized into a rigorous architectural model. Given your academic background, you may find this perspective particularly useful for designing robust and analyzable systems.

A research paper from Frontiers in Human Dynamics proposes modeling agent interaction through Communication Spaces, a concept analogous to layered network protocols.

The Communication Spaces model provides a powerful abstraction for information flow:

• Surface Space: The system's interface with the world (UIs, APIs, sensors). This is where raw inputs are received and final outputs are rendered.
• Observation Space: The bridge layer that transforms, routes, and validates information. It decodes raw input from the Surface space into a format the Computation space can understand, and vice-versa. This is where much of the inter-agent protocol logic resides.
• Computation Space: The core reasoning layer where decisions are made and tasks are executed by specialist agents.

When mapping your workflow, you can use this layered model to structure the flow. For example:

• A user query enters the Surface Space.
• An Observation Space agent parses the query, identifies intent, and routes it as a structured task to the appropriate agent in the...
• Computation Space. This agent executes its logic, possibly calling other agents within the same space.
• The result is passed back to the Observation Space, which formats it for the user.
• The formatted response is displayed in the Surface Space.

This formal separation of concerns helps ensure that raw data doesn't leak into the core logic and that communication protocols are explicitly managed.

5. Identifying Handoffs and Their Failure Points

Mapping the information flow is not just about drawing lines between boxes. It's about defining the contracts at the handoff points and anticipating where they might break.

As the diagram shows, handoffs are fraught with potential failures. When you map a connection between Agent A and Agent B, you must consider these risks:

• Misinterpreted Instruction: Did Agent A's output conform to the input schema Agent B was expecting? This is why structured messaging is critical. Define explicit JSON schemas for inputs and outputs.
• Context Loss: Did Agent A pass along all necessary background information? A handoff must include not just the immediate task data, but also relevant context like user preferences or previous steps in the conversation. This is where the "shared messages key" pattern is valuable.
• Incompatible Data Format: This is a classic API integration problem. Your agent specification (from the last lesson) must precisely define the data types, formats, and required fields for every agent's input and output.
• Redundant Work: If the handoff isn't well-defined, two different agents might be tasked with the same work. The orchestrator's logic must ensure tasks are mutually exclusive.

By proactively analyzing each handoff point against these failure modes, you can build a more resilient system.

Conclusion

In this lesson, we moved from designing individual agents to orchestrating a team. We established that mapping the information flow is a critical design activity, deeply connected to principles of distributed systems architecture.

Key Takeaways:

• Information flow has multiple dimensions: You must define the Execution (temporal flow), Coordination (wiring), and Interaction (protocol) for each connection between agents.
• Handoffs are implemented via concrete mechanisms: The most common patterns are updating a shared state or making explicit tool calls. Using tools to represent other agents is a powerful, modular pattern.
• Context must be explicitly managed: A key part of a handoff is deciding what information to pass. This often involves packaging relevant history (like a message thread) into the payload to prevent context loss.
• Formal models add rigor: Structuring your system's communication through layers like Surface, Observation, and Computation helps manage complexity and enforce clear boundaries.
• Handoffs are critical failure points: When mapping information flow, you must define the input/output contracts precisely and anticipate failures like context loss, data-mismatch, and misinterpretation.

Preview of the Next Lesson

We have now designed our agents and mapped the communication pathways between them. We've also identified the types of failures that can occur at these handoff points. In the next lesson, we will get even more specific, focusing on how to identify dependencies and potential failure points in a proposed agent workflow from the specification alone. We will practice analyzing our design artifacts—the PRD, agent specifications, and information flow maps—to debug our system before a single line of code is written.