Agentic workflows: one word for two opposite designs, and the difference is who owns the loop

GitHub’s documentation for its Agentic Workflows product contains a sentence that tells you more about the design than any definition on the same site:

Decisions cannot override retry limits, budgets, deadlines, or
nonrecoverable failures.

The definitions on the same site point the other way. GitHub describes agentic workflows like this:

Agentic workflows are AI-powered automation that can understand context,
make decisions, and take meaningful actions

and contrasts them with automation built on fixed if-then rules. That is the popular meaning: the AI decides. Anthropic’s “Building effective agents” uses the word workflow for nearly the opposite, the arrangement where the model does not decide the plan. So the same term covers two opposite designs. GitHub’s product, read closely, is what Anthropic would call an agent, with the limits Anthropic only recommends switched on by default, and the model can’t argue with them.

The label isn’t carrying the information. What a team needs to know about a job someone calls agentic is narrower and more mechanical: who decides the next step, who decides the work is over, and whether anything other than the model checks that the work is right. Those last two are different questions, and most of the confusion lives in treating them as one.

What Anthropic means by workflows and agents

Anthropic’s December 2024 essay puts both under one umbrella, agentic systems, and draws the line inside it:

Workflows are systems where LLMs and tools are orchestrated through
predefined code paths. Agents, on the other hand, are systems where
LLMs dynamically direct their own processes and tool usage, maintaining
control over how they accomplish tasks.

Read quickly, that is a split between “the model follows a script” and “the model is in charge”. The patterns filed under workflows do not fit that reading. Prompt chaining, routing and parallelization are what you’d expect: fixed paths, the model fills in each step. But orchestrator-workers is also a workflow, and in it a central model breaks the task down on the fly, hands the pieces to worker models and synthesizes what comes back. The model decides what the subtasks are. Evaluator-optimizer is a workflow too, and it is a loop: one call generates, another evaluates, round and round.

So the model making decisions is not what separates the two piles. In orchestrator-workers the model picks the subtasks, but the roles around it are fixed in code: break down, delegate, synthesize. In evaluator-optimizer the evaluator’s verdict can call for another round, but the loop is one you wrote, and you can put a round cap on it. What lands a pattern in the agent pile is that the model directs the process itself rather than filling slots in a structure someone else built. Who gets to say the work is finished is a separate question, and it cuts across both piles.

GitHub Agentic Workflows: an Anthropic agent with the caps on by default

By Anthropic’s definition, GitHub Agentic Workflows (gh-aw) is an agent. You write natural-language instructions in Markdown with YAML frontmatter; gh aw compile turns that into a standard GitHub Actions lock file; at runtime an engine (the docs list GitHub Copilot, Claude Code, OpenAI Codex, Google Gemini and Pi) reads the instructions and works through the task with tools. Inside the run, the agent decides what to read and what to do next.

What GitHub added is the part Anthropic’s essay leaves as advice. The essay notes that agents commonly get stopping conditions, such as a maximum number of iterations, to keep control. In gh-aw those are defaults in the frontmatter: timeout-minutes for the agentic step defaults to 20, max-turns caps the model responses and tool calls in a run at 500 unless you set another value, and an AI Credits budget is on by default. The agent job gets read-only repository permissions by default, and the recommended write path is declared safe outputs (create an issue, add a comment, open a pull request) that are validated before they are applied; direct write permissions exist, as a separate trust boundary you opt into. That is the context for the sentence at the top: the model owns the path, the harness owns how long the path may be, what it may touch, and what shape a change must take to leave the sandbox.

Every one of those limits ends a run or narrows what it can do. None of them says whether the run did the job. A timeout is a way out, not a verdict.

Agentic workflows end three ways, and only one of them is a check

A loop that finishes normally ends one of three ways. A code path runs out: the pipeline has five stages and the fifth one finished. An external check passes: the tests are green, the schema validates, the record matches its source. Or the model says it is done. (Forced endings, a timeout, a spent budget, a cancellation, are a fourth kind, and belong in the log as incomplete, never as success.)

Only the second is evidence about the work. The first tells you the program ended, which is an exit code again, and I’ve argued before that an exit is a summary the process wrote about itself, not a verdict. The third tells you what the model thinks of its own output. In a multi-agent setup that is the familiar case of an agent reporting success for work that never ran, one of the coordination failures worth designing against. A Claude Managed Agents workflow run makes the same point in its own docs: a run can end completed while work on its threads failed.

There are two separate dials here, then. Who owns the loop decides how big a mistake can get. What checks the end decides whether you find out. Anthropic’s own write-up of its multi-agent research system, from June 2025, shows the first dial going wrong: early agents spawned 50 subagents for simple queries and kept going after they already had enough results. Those are overruns, and caps and scaling rules address them; Anthropic’s fix was effort rules written into the prompts. They are a different failure from a run that stops on time with the wrong answer, and nothing on the first dial catches that.

Anthropic’s step-count test for agents, and the test in its own appendix

The essay’s criterion for reaching for an agent is this:

Agents can be used for open-ended problems where it's difficult or
impossible to predict the required number of steps, and where you
can't hardcode a fixed path.

True, and not the deciding fact. Plenty of tasks have an unpredictable number of steps and still shouldn’t hand the model the stop: anything where “done” is a judgment nobody downstream will re-check.

The better test sits in the same essay, in its appendix on where agents work in practice. Coding agents are effective, it says, because:

Code solutions are verifiable through automated tests; Agents can
iterate on solutions using test results as feedback; The problem space
is well-defined and structured; and Output quality can be measured
objectively.

That is not a claim about step count. It is a claim that something other than the model can confirm the end, and the appendix says the same of both domains it covers: the useful ones have clear success criteria. Even there Anthropic adds that human review still matters for whether a solution fits the broader requirements, since tests only cover what they test. Within that limit, a coding agent can run for three turns or forty and still be reasonable to give the loop, with one condition the appendix doesn’t spell out: the tests sit outside its write reach. An agent that can edit the test it is graded by is checking itself again, and a check binds only over the paths it covers, which is the same limit any harness gate has. This is exactly what gh-aw’s read-only permissions and safe outputs buy. The agent can propose a change; it cannot quietly rewrite the thing that judges it.

What about a second model as the judge, the evaluator in evaluator-optimizer? It counts as an outside check only to the degree it fails differently from the worker: a different model, different context, criteria it was handed rather than ones it inferred. A copy of the worker grading the worker shares its blind spots and adds confidence, not information.

Agentic workflows in production: keep the loop in code unless the end can be checked

That gives me a default for any job someone calls agentic. It’s a preference about when handing over the loop is defensible, not about when it’s required; a checkable task with a known path can still be a plain script.

If something outside the model and outside its write reach can check that the work is done (a test, a validator, a reconciliation against a source of truth, a person at a gate who actually reads the output), the model can own the loop. Gate the exit on that check, not on the model’s claim, and put the perimeter in code the way gh-aw does: deadline, turn cap, budget, a narrow write path. The cap bounds the cost. The check is what makes a normal exit mean something.

If nothing outside the model can check the end, keep the loop in code. Write the states and transitions as a program you can test, with retries and a cap, and call the model at the decision points inside it: classify this ticket, extract these fields, draft this reply, judge whether these two records are the same. That doesn’t make the result verified; a drafted reply is still unchecked. What it buys is a ceiling. In a coded loop the model can be wrong inside a step. It cannot skip a step, add ten more, or declare the job over, so an error stays the size of one call, and the place it happened has a name in a log.

The case that blurs this is the model writing the plan and code running it. Claude Managed Agents dynamic workflows work that way: the agent writes the fan-out as a program the server executes. It looks like a coded loop, but the code path that “runs out” is one the model wrote, so the first kind of exit quietly becomes the third. There the only perimeter you set yourself is the session budget, and it attaches when the session is created, before the plan exists.

None of this needs the word “agentic” settled. When someone asks for agentic workflows, the useful reply is two questions about one specific job: when this runs at night and the model says it’s finished, what checks that, and what stops it if nothing does?