Understanding Agentic Workflows (ReAct, Autonomous Commits, and Plan-and-Execute) | From Zero to AI Hero

An agentic workflow turns a goal into a controlled loop that can choose tools, inspect results, and revise the next step. I checked the original ReAct research against current engineering guidance, and the useful distinction is who chooses each action and what evidence is required before the workflow can finish.

What an agentic workflow controls

A fixed workflow follows code paths chosen by a developer in advance. An agentic workflow gives a large language model (LLM) limited authority to choose the next action from an approved tool set, then feeds the result back into the next decision.

Anthropic separates workflows from agents along this boundary. Workflows use predefined orchestration, and agents dynamically direct their process and tool use. Both belong in agentic systems, so autonomy is a design choice rather than a requirement for every step.

System shape	Who chooses the next step?	Best fit
Fixed workflow	Application code	Stable tasks with known branches and predictable checks
Agent-directed loop	The model, inside tool and policy limits	Tasks where new evidence changes the next useful action
Hybrid workflow	Code sets stages and the model chooses within a stage	Software work that needs flexible investigation plus deterministic release gates

The loop needs more than a prompt. A usable implementation keeps a goal, approved tools, working state, observations, stop conditions, and an audit trail. My explanation of what AI agents are covers the agent itself, including its model, memory, and environment.

How the ReAct loop uses observations

Yao and colleagues introduced ReAct as an interleaving of reasoning traces and task-specific actions. An action changes or queries the environment, and the resulting observation updates the context used to choose what happens next.

For a coding task, the operational cycle can be recorded without publishing hidden model reasoning. Record the selected tool, its arguments, the result, the state change, and the next decision. That trace gives you evidence for debugging and evaluation without treating private chain-of-thought text as an interface contract.

Cycle step	Coding-agent example	State change
Goal	Resolve a failing user-search test	Task and acceptance check are stored
Action	Search the repository for the handler and its tests	Relevant files enter the working context
Observation	The test exposes an unbounded database query	The suspected failure gains evidence
Action	Edit the query and rerun the focused test	The repository and test result change
Stop check	Required tests pass and the diff stays inside scope	The workflow can request review or finish

The observation is the control signal. If the test exposes a different cause, the next action changes. A fixed script would need that branch encoded before the run.

ReAct and plan-and-execute solve different tasks

Plan-and-execute creates a task plan before execution, then works through its steps. ReAct chooses an action, reads the observation, and adjusts its next move throughout the run.

Decision axis	ReAct	Plan-and-execute
Uncertainty	Fits investigation where each result can redirect the work	Fits tasks whose dependencies are known early
Control flow	Reconsiders after tool results	Uses the initial decomposition as the main route
Cost and latency	Can require more model calls and tool round trips	Can reduce replanning when the plan remains valid
Failure handling	Adapts near the failed step	Needs explicit checkpoints or replanning to avoid carrying a stale plan forward

A hybrid is often the better coding design. Create a coarse plan, execute one bounded step, validate its output, and revise the remaining plan only when the evidence changes. This keeps dependencies visible without assuming the first plan survives contact with the repository.

Autonomous commits need deterministic gates

A commit is a useful artifact, but commit creation should not be the success criterion. The workflow succeeds when the change satisfies an acceptance contract that the model cannot rewrite during execution.

A competent objection is that LLM output remains nondeterministic, so another loop does not make code safe. That objection holds. Reliability comes from placing deterministic checks and explicit permissions around model-directed actions.

• Scope: Restrict writable paths, commands, network destinations, and secret access before the run.
• Isolation: Use a branch, worktree, or disposable environment so a failed attempt cannot damage the main checkout.
• Verification: Run focused tests, the required suite, linting, type checks, and security checks outside the model decision.
• Diff review: Reject unrelated files, generated noise, leaked credentials, and dependency changes that the task did not require.
• Budgets: Cap steps, runtime, tokens, retries, and tool errors so the loop has a forced stop.
• Approval: Keep merge, deployment, destructive commands, and other high-impact actions behind a human or policy gate.

If you want to see the implementation pieces, the JavaScript AI agent tutorial shows how tools, state, and the execution loop fit together. Add repository permissions and release checks before adapting that design to code changes.

Failure modes that deserve explicit tests

Agentic workflows fail at boundaries between the model, tools, state, and policies. Testing only the happy path leaves the most expensive behavior unmeasured.

• Tool mismatch: The model chooses a valid tool with invalid arguments, or asks for a capability that is unavailable.
• Stale observation: A cached file, test result, or ticket no longer matches the environment being changed.
• Context loss: Long runs drop an earlier constraint, acceptance check, or failed attempt from the active context.
• False completion: The model declares success before the required test, build, or review result exists.
• Loop exhaustion: Repeated edits and retries consume the budget without improving the measured result.
• Permission creep: A broad shell, network, or repository tool lets the agent act beyond the task boundary.

Test each case by injecting the failure and checking the stop behavior. A timeout should end in a clear failed state, and a denied tool call should remain denied after replanning.

Choose the smallest architecture that fits

Use a fixed workflow when you can enumerate the branches and validations. Use ReAct when observations must redirect the work, and use plan-and-execute when decomposition is stable enough to make an upfront plan useful.

For longer coding work, start with the hybrid. Keep planning flexible inside a bounded stage, then require deterministic evidence before the workflow advances to commit, pull request, or deployment. This design accepts model uncertainty without handing it control of the release boundary.

Frequently asked questions

Give the model freedom where new evidence changes the next useful action. Keep permissions, acceptance checks, and release transitions deterministic. That boundary is what turns an agent loop into an engineering workflow you can inspect and stop.