Goals and workflows: long tasks through coding agents
I spend my days shipping work through coding agents, and the hardest part is the handoff: how do you describe a task well enough that an agent can carry it for twenty minutes without you feeding it every step? Three tools I use answer that differently. Claude Code gives the agent a goal condition and lets it loop. Codex has no goal primitive at all. ZCode turns the whole plan into a script you approve before anything runs. In September a production 500 on this site made the differences concrete.
What does a goal buy you in Claude Code?#
The /goal command takes a completion condition, and from that point Claude Code "keeps working toward a goal until a condition holds" (Claude Code docs). After every turn, a fast model checks whether the condition holds. If it does not, the agent starts another turn instead of handing control back to me. The goal clears itself once met.
A condition like all tests in test/auth pass and the lint step is clean works because it is checkable. The docs point at the same shape: substantial work with a verifiable end state, a module migration that runs until every call site compiles and the tests pass. A vague goal ("make the tests better") would loop forever or, worse, stop early with confidence.
On top of that sits orchestration. With /effort ultracode, Claude plans a workflow for each substantive task instead of working through it turn by turn (workflows docs). The docs describe dynamic workflows as JavaScript scripts that orchestrate many subagents, and one line carries the whole design: "A workflow moves the plan into code". The script holds the loop, the branching, and the intermediate results, so the model's context carries only the final answer. Before anything runs, an approval prompt shows the phases, and I can read the raw script, edit it in my editor, or cancel.
Codex: the goal lives in your head#
Codex took the opposite bet. I checked the CLI source while writing this (openai/codex): there is no --goal flag and no goal subcommand. What Codex has instead is a disciplined single-agent loop. It makes and updates plans as it works, every command can demand approval, and resume, fork, and review subcommands let me pick a thread back up or branch it. Structured output schemas pin down what a turn returns, and sandbox modes constrain what a run may touch.
So the stop condition in Codex is mine to hold. I write it into the prompt, I read the plan updates, I decide when the thread is done. That is more work in the moment and less machinery to trust, which for short tasks is the better trade.
The same task, three shapes#
| Claude Code | Codex | ZCode | |
|---|---|---|---|
| Goal primitive | /goal condition, re-checked by a fast model each turn | none, the stop condition lives in my plan and head | the workflow script returns one final deliverable |
| Plan gate | approve, read, or edit the script before it runs | per-command approvals, plan updates in stream | plan mode, explicit approval before execution |
| Orchestration | script with agent(), pipeline(), parallel() | one agent loop, threads | script with subagents, loops gated on real command output |
| Reuse | save a run as a /command in the repo or home dir | resume and fork an existing thread | saved workflows, named subagents replay from cache |
ZCode, the tool I am writing this in, sits closest to Claude Code's workflow model. Its runs are built from named phases, subagents that hand back typed results, and gates that decide from real command output, a failing check counts as data, not as a crash. The plan-then-approve step comes before any of it.
A production 500 through the mill#
Earlier this week four blog category URLs on this site returned HTTP 500 in production. The task sounded trivial. The same deployment had just fixed a different crawl problem, so my first hypothesis was wrong.
Through a planning agent, the run looked like this. Plan first: reproduce the 500s, list what changed recently, form one falsifiable guess at a time. Gates along the way: the container logs had to show the actual error, not an inference, before any fix was written. The log line that mattered was an ENOENT on a CSS file read at module load, which killed the first hypothesis and produced the real one: the file existed in the repo but never reached the Docker run stage. The fix was one COPY line. Verification ran before any deploy: build the image locally, hit the four URLs, expect 404 for empty hubs and 200 for the rest.
That is the shape a goal encodes well. no 500s for any blog URL and the four hubs answer 200 or 404 is checkable after every turn, and a fast model can hold the agent to it while I do something else. What the goal does not encode is the diagnosis path, and that is where the workflow layer earns its keep: a phase for reproduction, a phase for hypotheses with a gate on real log output, a phase for the fix, a phase for verification.
The responsibility stays at this desk#
All three tools are honest about this in their design. Claude Code shows me the script and waits. Codex asks per command. ZCode refuses to start without an approved plan. The human gate is not a formality, because the agent optimizes toward whatever condition I wrote, and a wrong condition produces confident, verified-looking work in the wrong direction. Without enough domain knowledge to judge the plan, I would not catch the missing edge case, the hole in the sandbox, the check that passes for the wrong reason.
The German tax office does not accept "the agent said the numbers were right", and production does not either. The final decision and the responsibility stay at this desk, which is why review is part of the task, never an optional extra (how I think about agent discipline in real business). The tooling around agents keeps maturing, from protocol layers like ACP and MCP to search an agent can trust. The gates are getting better. The person at the gate is still me.