Wink Pings

Treat the Agent as a Pipeline: This Claude Code Prompt Hardcodes Approval, Review, and Retry

A Claude Code prompt circulating on X breaks the agent harness into an orchestrator, builder, reviewer, and eval. What is really worth looking at is the approval boundary and the definition of done.

A Claude Code prompt circulating on X turns the agent harness into a pipeline. The tweet author NO1ennn says that Anthropic’s prompt guide for agent harnesses is free, and that compressing the entire guide into one prompt and handing it to Claude Code can build an execution crew from scratch.

A quick bit of background first. The agent harness is the orchestration layer outside the model: it decides how tasks are split, when tools are called, who verifies results, and how errors are retried. Ordinary users can think of it as giving the AI a project manager plus a QA person.

The skeleton of this prompt is not complicated:

  • An orchestrator breaks the goal into tasks, and each task carries a done-check, i.e. a completion criterion.
  • The builder runs at low effort, with one builder per task; the brief must be self-contained and not rely on assumptions from the previous round.
  • Subagents are used only for parallelism, because each one you spin up has a cost.
  • Reading files, running tests, and safe retries do not require approval; risky actions must be approved.
  • The reviewer looks at the diff, not the summary, and reruns the tests.
  • Evals score each change and record the tokens burned.
  • Errors and timeouts are not blockers; diagnose, retry, switch tools, and keep running.

Give it a tech stack, and it builds the corresponding execution crew.

Agent harness prompt illustration

What is interesting about this approach is not that the prompt is long, but that the boundaries are written in detail. Many agent projects like to chase stronger models first, and as a result the workflow has no done-check, the reviewer only looks at the model’s summary, and risky actions and read operations are mixed into one permission level. It looks fully automated when running, but when something goes wrong you cannot find the breakpoint.

In the replies, someone mentioned the pdf_table_read example: the scorer was broken, not the agent. Most teams would first go change the prompt, and the more they change it, the worse it gets. This reminder is very practical. Evals themselves can also be wrong; first distinguish whether it is an execution failure or a measurement failure.

Another part worth copying is tiered approval. Reading, testing, and safe retries are left open, while irreversible actions are blocked. This split is more practical than full automation, and more workable than confirming every step.

Do not treat it as magic. The prompt only provides structure; how well the done-check is written determines how far this pipeline can go. The tech stack, tool permissions, and test commands still need humans to decide. For people using Claude Code or similar agent tools, check two things first: does every task have a verifiable completion criterion, and do risky actions have hard approval gates.

Original tweet: https://x.com/N01ennn/status/2120036282214793497

发布时间: 2026-11-10 16:27