graph-vs-loop-decision

Decides between bare loops, state machines, and graphs for agent control flow.

Updated Aug 2, 2026
One-click install
npx skills add https://github.com/dperussina/function2agent --skill graph-vs-loop-decision-dperussina
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: graph-vs-loop-decision
Source: https://github.com/dperussina/function2agent/tree/main/.cursor/skills/graph-vs-loop-decision
Command: npx skills add https://github.com/dperussina/function2agent --skill graph-vs-loop-decision-dperussina

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Agent builders routinely over-engineer control flow, reaching for graph frameworks like LangGraph when a simple loop would suffice, or under-engineering and relying on prompts for guarantees only structure can provide. This Skill gives a disciplined decision procedure for choosing the right topology and enforcing it structurally. ## Core Features & Use Cases - Decision procedure: A three-step test that defaults to a bare loop and only escalates to a state machine or graph when a declared constraint (ordering, mandatory step, human gate, compensating action) demands it. - Structural guarantees: Patterns for making critical steps unreachable except through required predecessors, plus topology tests using all_simple_paths that run without a model. - Node contracts and sagas: Specifications for node pre/postconditions, explicit channel reducers, idempotency keys, and compensating actions for side effects. - Serializable topology: Requirements that graphs be versioned, content-addressed data with machine-checkable invariants, plus a T0–T4 promotion ladder from plain tool to protocolled subgraph. - Use Case: When designing an order-fulfillment agent, use this Skill to determine that charging a card requires a graph with a human approval gate and saga compensators, while a simple research task stays a bare loop. ## Quick Start Ask the agent to review your planned agent control flow and decide whether it should be a loop, a state machine, or a graph, with the required invariants listed.

Frequently Asked Questions about graph-vs-loop-decision

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
When should I use a graph instead of a ReAct loop for my agent?▼

Use a graph only when you can declare a specific constraint: ordering between steps, a mandatory step that must not be skipped, a human approval gate, or a compensating action for side effects. If no step must happen but sometimes does not, a bare loop is sufficient.

How do I enforce that a step always runs in an agent graph?▼

Make the step structurally unavoidable by ensuring the target node is unreachable except through it, then test the topology with all_simple_paths assertions. These tests run in milliseconds without a model and catch regressions from automated topology edits.

Is the supervisor pattern a good choice for multi-agent systems?▼

The supervisor pattern is correct only when sub-domains have genuinely disjoint tools and policies. If sub-agents share most of their context and must re-explain it to each other, they are one agent with more tools and should not be split.

How do I handle side effects and rollback in agent workflows?▼

Use a saga pattern: every side-effecting node declares a compensator or is marked irreversible behind a human gate. Idempotency keys must derive from stable state, never a UUID generated inside the node, and compensation paths must be as testable as forward paths.

What are the limitations of dynamic planner agents?▼

Dynamic planners generate plans with zero observations, so the first tool call often invalidates their assumptions. They only earn their keep with an explicit replan edge and cheap trigger, and are generally not worth it under about five steps.