A model can read a file, call a tool, inspect the result, and decide what to do next. That makes a useful starting point for an agent. It does not yet tell me who approves a change, how a failed job resumes, or which result counts as finished.

I use loop, graph, and factory for three different decisions: how the agent acts, how work moves between steps, and how an organization delivers and owns the result. The structures can coexist. Adding more agents is a separate choice.

The loop lets the model choose its next action

An agent loop repeats observation, decision, tool use, and feedback until it reaches a stop condition. The model might search before editing because it does not yet know where a function lives. It may inspect a failed test and try another edit. The sequence depends on what it finds.

For a small bug fix, one agent can inspect the repository, edit the function, run the relevant test, and report the diff. The tool interface should return useful failures. A vague result such as “command failed” gives the model less to work with than an exit code and a short diagnostic.

I would bound that loop by time, tool calls, and cost. I would also give it a clear completion test: the requested behavior works and the diff contains only the intended change. Repeating actions until a model sounds confident is a weak stop condition.

Anthropic’s distinction between agents and predefined workflows

The graph makes transitions explicit

A graph names steps and connects them with transitions. A node may call a model, run deterministic code, or contain an entire agent loop. An edge says where execution goes next. A conditional edge can route a failed test back to editing or route a risky change to human review.

Keep state explicit

The same bug fix now has a visible path. The graph can require testing before review even if the model would prefer to finish early. State might hold the requested change, repository revision, touched files, test result, and approval status. Keep those fields explicit instead of inferring them from a long conversation.

LangGraph expresses this through state, nodes, and edges. That is one implementation, not the definition of all agent systems. A graph can use one model and one agent. It can contain cycles; “graph” does not imply a fixed one-way checklist.

LangGraph Graph API: state, nodes, and edges

A factory adds ownership and delivery rules

Here, factory means an operating model for repeatable software delivery. It is my working term, not a universal agent standard. A factory accepts work, records scope, assigns execution, verifies evidence, releases approved changes, and keeps enough history to investigate failures.

For the bug fix, the factory records the repository and revision, the allowed files, the acceptance criteria, and who can approve release. It may choose a simple loop for the edit and a graph for validation. A release step then checks that the reviewed artifact is the artifact it will ship.

The factory needs a durable job identity and a record of attempts. If a worker crashes after opening a pull request, the next attempt should find that pull request instead of creating another. Retries must distinguish “the action failed” from “the action completed but the reply was lost.”

Parallel workers help when their work can be separated. They also introduce conflicts, coordination cost, and a need to combine evidence. I would add them for independent modules or reviews after measuring the bottleneck. A single agent with clear tools remains a reasonable worker.

Choose the smallest structure that answers the problem

Use a loop when the next useful action depends on discovery. Add a graph when certain transitions must be enforced, inspected, or resumed. Add factory rules when several jobs need ownership, release controls, and an audit trail.

For each added mechanism, name the failure it handles. A test gate handles an unverified edit. A checkpoint handles interrupted work. An approval handles authority to release. A job record handles repeat attempts. If I cannot name the failure, I would leave the mechanism out of the first version.

Before expanding the system, run real tasks and inspect both results and tool traces. Record completion, incorrect edits, retries, elapsed time, and cost. Those observations decide whether the structure needs to change; the architecture diagram alone cannot.