One task, two readers:the agent, the human

A developer at Wagglet has introduced a task-design pattern called the Dual Prompt, which splits each work item into two blocks: one detailed brief for AI agents and a short human-facing summary. The approach addresses the challenge of writing task descriptions that serve both an agent, which consumes long constraints without skimming, and a human supervisor, who needs concise instructions and explicit verification steps. The pattern emphasizes a shared outcome and definition of done, with a critical 'STOP and ask if' line to prevent agents from building coherent but wrong solutions.

I spent a long time writing deliberately vague task descriptions, and I could defend it. A complete brief took forty minutes. The teammate picking it up would skim it anyway, miss the one constraint that mattered, and message me a question I had already answered in paragraph three. So I wrote less and kept the rest in my head. Cheaper, given the reader. Then the reader changed. Half the tickets on our board are now picked up by someone who immediately pastes them into Claude Code or Codex. And an agent is the opposite kind of reader: it will happily consume two thousand words of constraints, and it will not skim. Suddenly the forty-minute brief pays for itself. Except the person supervising the run still does not want to read it. That is the actual problem, and it took me embarrassingly long to name it. A task in an agentic workflow has two participants with completely different needs: Writing one document for both produces something that fails both. Trim it for the human and the agent hallucinates the missing constraints. Write it for the agent and the human skims, misses the escalation rule, and rubber-stamps a bad delivery. Every work item gets two blocks. Same task, same intended outcome, two audiences. The agent block is long and boring on purpose: Outcome: CSV export on the reports page matches the on-screen totals. Source: apps/reports/, the export path is in exporters/csv.ts Constraints: - Do not change the on-screen aggregation. It is correct. - Currency must stay in minor units end to end. - Timezone for date bucketing is the workspace timezone, not UTC. Edge cases: empty result set, 50k rows, refunds negative amounts . Evidence at delivery: a diff, the new tests, and one exported CSV for the 50k-row fixture. STOP and ask if: the on-screen totals themselves look wrong. The human block is five lines: Why: finance is reconciling by hand every month because of this. Start: open the repo, run the agent against the task above. You decide: whether the refund rows belong in the export at all. Verify: open the CSV in Sheets, check one month against the UI. Escalate: any change to the on-screen aggregation. The second block is the one that gets read. That is the point. My first attempt at this was two separate tickets, one "for the AI" and one "for the human". That was worse than doing nothing. The two drifted within a week: someone updated the constraint in the agent ticket, nobody touched the human one, and the reviewer verified against a rule that no longer existed. They have to be one work item with two sections, sharing one intended outcome and one definition of done. If you cannot express both from a single outcome statement, that is a signal the task is really two tasks. The line I would keep if I could only keep one is STOP and ask if: . Agents are relentlessly agreeable. Handed an ambiguous task, they will pick an interpretation and build something coherent on top of it, and coherent-but-wrong is far more expensive to unwind than a question asked up front. Naming the specific conditions under which the work should halt converts that failure mode into a five-minute conversation. It is the single highest-leverage line in the brief and it costs one sentence. The other thing worth being explicit about: which checks a person actually has to perform with their eyes. "Tests pass" is not verification when the agent wrote the tests. Naming one concrete manual check — open the file, compare one month, click the button — catches the class of failure where everything is internally consistent and collectively wrong. We formalised this into a pattern we call the Dual Prompt, and there is a longer write-up with the reasoning and a fuller template here: https://wagglet.com/blog/dual-prompt-human-agent-task-design https://wagglet.com/blog/dual-prompt-human-agent-task-design If you want the mechanical version — a board where each item carries both blocks and the delivery loop enforces the evidence requirement — that is roughly what we built at Wagglet https://wagglet.com , and the workflow docs are at https://wagglet.com/docs/task-handoff https://wagglet.com/docs/task-handoff . Curious whether other people have landed on something similar. The failure mode I still have not solved is keeping the human block genuinely short as the task grows.