Agentic Compute Graphs: Choosing Static and Dynamic Workflows
Watch on YouTube: Agentic Compute Graphs: Static vs Dynamic Agent Workflows
One design choice shapes the behavior and cost of an AI workflow: do you define the route before it runs, or let the system select some routes at runtime?
I find it useful to model an agent system as a compute graph. Nodes do work. Edges pass control and data. I use “plasticity” to mean how much freedom the graph gives the runtime to choose its route. It is a framing for design decisions, not a formal standard.
The plasticity spectrum
A fully static workflow defines its nodes and routes before execution. It may still have fixed conditional branches, but the topology and rules are known in advance. At the other end, an agent can select tools, decide among routes, and sometimes start subagents while it runs.
Most systems mix the two. The useful question is not whether a graph is static or dynamic in the abstract. It is where runtime choice is worth the extra uncertainty and overhead.
Fixed workflows
Static workflows are often the right fit for tasks with clear requirements. A known path is easier to test, review, and explain. Payment flows, data pipelines, and compliance checks often benefit from that predictability.
The trade-off is that a fixed workflow can spend effort on cases that do not need it. Imagine a verification chain that always runs five steps, even though only 5% of requests need the full chain. If every step runs unconditionally, the other 95% pay for work that adds little value. Caching, early exits, and fixed conditional routing can reduce that cost without handing routing to a model.
Dynamic routing
Agent-selected routing can send simple requests down a shorter path and reserve costly work for difficult ones. It also adds model calls, coordination overhead, and paths that are harder to predict. Dynamic routing can lower wasted work in some systems; it does not automatically lower total cost.
The choice is a cost and reliability trade-off. Add runtime freedom only when the variation in the task is real enough to justify it.
LangChain and LangGraph
The distinction between LangChain and LangGraph is best understood as an emphasis, not a hard boundary. LangChain provides components such as prompt templates, model wrappers, tool integrations, and output parsers. It also has agent and orchestration features, often with LangGraph underneath.
LangGraph focuses on stateful graph execution. It is useful when a workflow needs explicit state, cycles, conditional edges, or routes selected at runtime. In many projects the two are complementary: LangChain supplies integrations and components, while LangGraph makes control flow and state visible.
Observability follows flexibility
When a system can choose different routes, two runs may not take the same path. Production teams then need to record which nodes ran, in which order, and with what state. Observability becomes hard to avoid once routing is no longer fixed.
A trace supports diagnosis and can help approximate a replay. It does not guarantee that an LLM or external tool will reproduce the same result, since sampling, models, context, and external state can change.
A practical sequence
My preference is to begin with a fixed graph. It forces the team to describe the task and gives a baseline for tests and costs. Then look for steps that run without earning their cost. Add dynamic decisions only where variable inputs or open-ended work make them useful, and keep the resulting routes observable.
That is not a universal rule. It is a reasonable default when an agent system needs to be understandable as well as capable.