A library team must choose between a LangGraph-style graph and a simple Claude tool loop for multi-step catalog repair. What should drive that framework choice?
Select an answer to reveal the explanation.
Short Explanation
Simple repairs are a checklist; tangled multi-branch repairs are a subway map. Pick LangGraph-style graphs when you need the map—not because better prompts alone can handle the branching and state you've got.
Full Explanation
Whether the task's branching and state needs justify a graph framework versus a simple tool loop should drive the library team's choice between a LangGraph-style graph and a simple Claude tool loop for multi-step catalog repair. Frameworks that model explicit nodes, edges, and durable state help when repairs branch (conflict resolution, rollback, multi-record dependencies). Linear repairs may need only a simple tool loop. Match abstraction cost to task shape—subway map versus checklist—not to fashion.
Picking a graph because of total tool-call count fails by concept: execution speed doesn't create branching or durable-state needs, and a graph adds overhead when a simple loop will do. Letting model context window size dictate graph-based orchestration fails operability; context limits don't by themselves create branching or durable-state needs, and a graph won't fix a too-small window. Relying on improved prompt wording to provide branching and persistent state fails as a criterion; prompts can't replace explicit nodes, edges, and durable state when the repair flow genuinely requires them.
Exam caveat: graphs are not automatically better for every civic agent. Prefer the simplest pattern that meets branching, persistence, and observability needs, and be willing to revise if catalog-repair complexity grows.
Operational check: map the catalog-repair flow's branches and state; if mostly linear, prototype a simple tool loop; if multi-branch with re-entry, use a graph; compare maintainability, testability, and incident debug time before standardizing.