In the early days of LLM applications (2023), we treated Agents like ETL pipelines. We used tools like LangChain to define rigid chains: Prompt A -> Parser -> Prompt B -> Tool.
Mathematically, these are Directed Acyclic Graphs (DAGs). They are excellent for deterministic processes where the steps are known a priori.
But intelligence is not a DAG. It is not linear, and it is not acyclic. It involves loops, backtracking, recursion, and - most importantly—self-modification.
If you are building your multi-agent system on a static graph (like an Airflow DAG), you are not building an agent; you are building a fancy script. The future belongs to Dynamic Topology.
Here is the technical breakdown of why static graphs fail and how dynamic architectures work.
1. The "Plan-Execute" Fallacy
Standard architectures separate "Planning" and "Execution."
- Planner: Breaks the goal into 5 steps.
- Executor: Runs steps 1 through 5 in order.
The Failure Mode
What happens when Step 3 reveals that Step 1 was based on a false premise? In a DAG, you are stuck. You have to error out or execute a predefined "failure branch." In a Cyclic Graph, the agent can observe the failure, modify its own state, and jump back to Step 1 with new context. This is the TOTE Loop (Test-Operate-Test-Exit), the fundamental unit of cybernetics and cognitive science.
Key Shift: Moving from Sequence to State Machine.
2. Runtime Topology Mutation (Graph Rewriting)
This is the cutting edge. In a static topology, the nodes (agents) and edges (communication paths) are defined at compile time.
- Static: "Research Agent talks to Writer Agent."
- Dynamic: "Research Agent realizes the topic is too broad. It spawns three temporary sub-agents (History, Economics, Politics), orchestrates a debate between them, synthesizes the result, kills the sub-agents, and then talks to the Writer Agent."
This is Dynamic Topology. The structure of the multi-agent system changes in response to the data flowing through it.
The Architecture
- The Super-Node: A "Manager" agent with the permission to instantiate new docker containers or runtime environments (Nodes).
- The Message Bus: A publish/subscribe model (like Kafka or NATS) where agents subscribe to topics dynamically, rather than having hardcoded HTTP links to specific peers.
3. The "Blackboard" Pattern vs. Message Passing
In a DAG, data flows like water in a pipe. Output of A becomes Input of B. In a Dynamic System, this is insufficient. Agents need a shared, mutable reality.
We are seeing a resurgence of the Blackboard Architecture (popular in 1980s AI):
- The Blackboard: A shared state (Redis/Vector DB) containing the current understanding of the world.
- The Knowledge Sources: Agents that watch the blackboard. When they see a state they can act on (e.g., "Draft is pending review"), they wake up, perform work, update the blackboard, and go back to sleep.
This decouples the agents. The "Reviewer" agent doesn't need to know who wrote the code. It just knows that there is code on the Blackboard that needs reviewing. This allows for massive, uncoordinated parallelism-aka a Swarm.
4. From Orchestration to Choreography
- Orchestration (DAG): A central conductor (The Code) tells every agent what to do next. "Step 1 is done. Run Step 2."
- Choreography (Dynamic): Agents are autonomous actors reacting to events.
Why Choreography Wins
In complex tasks (e.g., "Refactor this codebase"), you cannot predict the dependency graph. You might fix a bug in auth.py that breaks login.py. In a choreographed system, the "Linter Agent" and "Test Agent" are constantly reacting to file changes. They form a feedback loop that stabilizes the system naturally, rather than following a rigid "Build -> Test -> Deploy" line.
Conclusion: The Actor Model
We are reinventing the Actor Model (Erlang/Akka) for AI.
- Actors: Agents.
- Messages: Natural Language Prompts.
- Supervision Trees: Only allowing an agent to crash (hallucinate) if a supervisor is watching to reset it.