Dynamic Workflows and Goal Loops

Most agent sessions are one conversation with one agent. The agent gathers context, acts, checks its work, and returns an answer.

Some problems are too broad for that shape. You may want several independent researchers to investigate different sources, competing debuggers to test different theories, or separate builders and critics to produce and challenge a result.

A dynamic workflow divides that work into phases and gives distinct jobs to different agents. Some jobs can run in parallel; later agents can synthesize, challenge, or verify what the earlier agents produced.

Codex and Claude Code expose this pattern differently:

Both harnesses also support /goal loops for work that needs to persist until a verifiable condition is true.

This is not “more agents = more intelligence.” A workflow is useful when the work has genuinely independent parts and when you can explain how those parts will be brought back together. Otherwise, you have multiplied cost, coordination, and opportunities for error.

Use a parallel workflow when independent perspectives or workstreams add value. Use a goal loop when the work may take many attempts but has a clear, verifiable end state. Use both only when the task genuinely needs both shapes.

Find a problem worth giving to a dynamic workflow

You do not need to invent a toy problem to try a dynamic workflow. Somewhere in your current work is probably a question that would benefit from several lines of inquiry, competing approaches, or broader coverage than one agent would normally produce.

This prompt will inspect your real work, find a few promising candidates, and give you one problem to carry into the next exercise.

Prompt

Find a real problem in my current work that would be interesting and useful to give to a dynamic, multi-agent workflow.

Inspect the goals, projects, files, recent work, unfinished threads, and past conversations you can access. Do not ask me to invent a task before looking at what is already here.

Look for problems where breadth would add value: several sources need to be investigated, competing explanations or approaches should be tested, different perspectives could challenge one another, or the space is too large for one linear pass.

Give me three candidates. For each:

  1. 1. State the problem and the useful result it could produce.
  2. 2. Explain why multiple lines of work could produce a better or more surprising result than one normal agent pass.
  3. 3. Point to the context, files, conversations, data, or prior work already available.
  4. 4. Name how I could tell whether the result is actually good.

Recommend the candidate most likely to produce an illuminating first experiment without creating consequential risk. End with a short statement of that problem that I can carry into the next exercise. Do not start solving it yet.

Prepare useful input for a dynamic workflow

The harness can decide how many agents to use, how to divide their work, and which steps should run in parallel. Your job is to make the problem legible.

Useful input describes the state you want to create, the context the workflow can inspect, the quality bar, hard constraints, non-goals, and where it has room to explore. Describe the problem richly without prescribing the process.

This prompt will turn a rough task into a brief you can give to a dynamic workflow.

Prompt

Turn this rough task into useful input for a dynamic, multi-agent workflow:

[DESCRIBE THE TASK OR POINT TO THE PROJECT]

Inspect the relevant project files, instructions, prior work, and available evidence. Infer what you safely can instead of making me restate context that already exists.

Produce a compact, launch-ready brief that establishes:

  1. 1. The outcome: what should be different when the work is finished, who it is for, and what artifact or change should exist.
  2. 2. The starting state: what already exists, what has already been tried, and which sources or files are authoritative.
  3. 3. The quality bar: examples, standards, acceptance criteria, and the evidence that would demonstrate success.
  4. 4. The constraints: deadlines, permissions, risks, practical bounds, and anything that must not change.
  5. 5. The non-goals: plausible adjacent work that should remain out of scope.
  6. 6. The open territory: genuine unknowns, competing possibilities, or questions where independent exploration may add value.
  7. 7. The autonomy boundary: decisions the workflow may make on its own and decisions it should bring back to me.

Do not design the workflow, assign agents, prescribe phases, or begin the task. Give me the finished brief I can give to a dynamic workflow and flag only the missing information that would materially change the run.

Check the emerging result

In a long-running workflow, it is easy to watch the agents instead of examining what they are producing. The useful question is simpler: how good is the result right now?

Send this while a workflow is running. It will inspect the current deliverable against the outcome you asked for and identify the most useful next move.

Prompt

Evaluate the best current version of the deliverable this work is producing. Inspect the actual files, artifacts, results, or behavior, and run relevant checks when possible. Focus on the work itself, not agent activity or status.

Show me:

  1. 1. What exists now and what it can already do.
  2. 2. Which parts of the intended outcome and quality bar it currently meets, with concrete evidence.
  3. 3. The strongest part of the result—the thing most worth preserving.
  4. 4. The most important gap, weakness, failure, or unproven assumption.
  5. 5. What a real user would experience if they used the result right now.
  6. 6. What would be delivered if the work stopped here.

Then recommend the single next move that would most improve the result. Do not summarize the agents, explain the workflow, or restart the process.

Keep working until a condition is true

Use /goal when “do your best and tell me when you are done” is too vague but the finish line can be demonstrated. Without a verifiable finish line, a long-running process can mistake activity for progress, stop at a plausible result, or keep polishing indefinitely.

A good goal condition names one observable end state, the check that proves it, important constraints, and how unresolved parts should be represented. This makes completion inspectable instead of leaving it to the agent’s feeling that it has done enough.

For example:

The research brief answers every question in brief.md, every factual claim has a primary-source link, contradictions are flagged, and the final file is under 1,500 words. Any question that cannot be answered from the available evidence is clearly marked unresolved.

This prompt will turn your desired outcome into a condition the current harness can actually use and prepare the project for a long-running session.

Prompt

Prepare a safe, verifiable /goal loop for this outcome:

[DESCRIBE THE STATE YOU WANT TO BE TRUE]

Inspect the project, its current instructions, acceptance criteria, tests or evaluation methods, and current state.

Then:

  1. 1. Rewrite the outcome as one state-based completion condition, not a list of activities.
  2. 2. Name the command, test, artifact, checklist, or observable result that proves the condition is true.
  3. 3. Add constraints for files, behavior, safety, quality, or scope that must remain true along the way.
  4. 4. Define what the finished result should say or contain when part of the outcome cannot be achieved or verified.
  5. 5. Identify any progress or checkpoint file the agent should update so a resumed session knows what happened and what remains.
  6. 6. Explain what evidence the agent must surface or record so progress and completion can be judged.

Return the exact /goal command and a short preflight checklist. Do not start the loop until I have seen the condition.

Close the loop without losing the work

When a large run ends, the final answer is not the only artifact worth keeping. The workflow may have discovered a better decomposition, a missing quality check, a source worth preserving, or an expensive branch that should never run again.

This prompt will harvest the run into a compact record that improves the next session instead of leaving the useful lessons inside an opaque transcript.

Prompt

Review the completed multi-agent workflow or goal run and preserve the durable value it produced.

Inspect the run journal, agent outputs, final artifact, verification evidence, failures, and any interventions I made.

Produce a compact run receipt containing:

  • - what the process attempted and what it actually delivered;
  • - the evidence that the result meets—or does not meet—the quality bar;
  • - which agents, phases, prompts, and checks created real value;
  • - which branches duplicated work, failed, or consumed disproportionate time or tokens;
  • - what should change before a similar run;
  • - and where the final artifacts and reusable instructions live.

Recommend at most three durable changes to the project instructions, workflow, skill, evaluation, or checkpoint process. Draft them, but do not silently modify the system.