The Dual Prompt: one task for the agent and the human supervising it

I used to write bad task descriptions on purpose.

That sounds irresponsible, but the calculation felt rational. A careful, complete brief took time to write. A busy teammate would skim it, miss a constraint, and come back to ask a question I had already answered. So I adapted to the reader: fewer details, more conversation, and more of the task kept in my own head.

Agents changed that calculation. An agent can work from a long, explicit brief, but the person running the agent does not need the same wall of text. They need a short operating role: how to start, what only a human can decide, what to verify, and when to stop.

That is the pattern we call the Dual Prompt: one work item written for two different participants.

It is not two hidden system prompts. It is not a trick for making a model think twice. It is a two-audience task design: detailed LLM instructions for the agent, and concise Human instructions for the teammate supervising the run.

Key takeaways

• A Dual Prompt gives the agent complete working context and gives the human a separate runbook for access, judgment, verification, and escalation.
• The agent brief should state the outcome, constraints, evidence, and stop conditions; the human instructions should name the decisions and checks that cannot be delegated.
• The pattern does not make ambiguous, unauthorized, or high-risk work safe to hand off; those tasks still need narrower scope or a specialist at the controls.

One task has two readers

Most task trackers assume that the assignee is the reader and the worker. With an agentic workflow, those roles split.

The agent needs the full working context: the intended outcome, repository or source material, constraints, edge cases, evidence required at delivery, and conditions under which it should stop and ask for help.

The human needs a runbook: why this work matters, how to start the right session, which checks require human eyes, which decisions they are authorized to make, and where the agent must not proceed without escalation.

The two branches meet again at a verified outcome:

                         one intended outcome
                                  |
                 +----------------+----------------+
                 |                                 |
        LLM instructions                  Human instructions
        context, constraints,              start, observe, decide,
        work, tests, evidence               verify, stop, escalate
                 |                                 |
                 +---------------+-----------------+
                                 |
                      delivery + human review
                                 |
                              acceptance

This separation is useful because the two readers fail differently. An agent can move quickly through the wrong interpretation. A human can skim a technically dense brief and miss the one action that belongs to them. One generic paragraph does not solve either problem well.

Detailed does not mean bloated

The agent side should be complete, not enormous.

Current OpenAI guidance for agent instructions recommends clear actions, explicit outputs, and planned handling for edge cases. Its current model guidance similarly recommends stating the goal, relevant context, constraints, required evidence, success criteria, and output format—while removing repetition. That is the right distinction: high-signal detail is useful; duplicated prose is not. See OpenAI's practical guide to building agents and current model guidance.

A useful agent brief usually answers six questions:

1. What outcome are we trying to produce?
2. What context, files, systems, and prior decisions matter?
3. What must change, and what must remain untouched?
4. What checks would count as credible evidence?
5. When should the agent stop, ask, or hand control back?
6. What should the delivery report contain?

Anthropic's engineering guidance reaches a compatible conclusion from another direction: agent use is most promising when tasks have clear success criteria, feedback loops, and meaningful human oversight. That is guidance from a model vendor, not proof that every agent workflow succeeds, but it is a useful design test. If we cannot explain what success looks like or how feedback returns, the task is probably not ready to hand off. See Building effective agents.

The human runbook is not a shorter prompt

The human side should not summarize every technical detail. It should make the person's responsibility unmistakable.

A useful human runbook answers a different set of questions:

1. Why are we doing this, and what outcome should I expect to see?
2. How do I start the correct agent, workspace, model, or environment?
3. Which access, judgment, or real-world observation can only I provide?
4. What exactly should I inspect before delivery?
5. What is a stop condition, and who should I contact?
6. How do I record what happened?

This distinction also prevents a dangerous fiction: adding a human does not automatically create oversight. If the person has no clear role, no way to inspect the result, and no authority to stop the run, they are only clicking buttons around an autonomous process.

The NIST AI Risk Management Framework explicitly recommends defining and differentiating roles and responsibilities for human-AI configurations and oversight. The framework's wording is broad, but the practical lesson is concrete: “a human is involved” is not a control until the human's responsibility is named.

A concrete Dual Prompt

Imagine a small software company wants to add CSV export to its invoice screen.

The weak version of the task is familiar:

Add CSV export to invoices. Make sure it works.

That sentence makes both participants improvise. The agent must guess what “works” means. The runner does not know what to check.

The agent side could instead say:

Outcome: Add CSV export to the existing invoice list without changing invoice calculations or permissions.

Work on the named repository and branch. Reuse the current filtered invoice query; do not introduce a second totals implementation. Export the visible columns plus invoice ID, use UTF-8, preserve the user's date format, and quote fields according to RFC 4180. Keep the existing authorization boundary: a user must never export invoices they cannot view in the product.

Add deterministic tests for commas, quotes, non-Latin customer names, an empty result, and the maximum supported export size. Run the relevant unit and integration suites. If the maximum size or date-format rule is not discoverable from current code or docs, stop and ask instead of inventing one.

Deliver the files changed, tests run, test results, screenshots or other requested evidence, and any limitation that remains.

The human side could say:

Run this in the test workspace—never with a real customer's invoices. Use the agent and environment named on the task. When it is ready, export the three synthetic invoice fixtures and open the CSV in both a text editor and a spreadsheet. Check the accented customer name, the comma in the address, the displayed total, and that the export still respects the active filter. Do not approve a change to tax rounding; escalate that to the task author. Record the delivery from the same agent session so its report reflects what actually happened.

Notice what is not duplicated. The human does not need the implementation plan. The agent does not need a motivational summary written for the runner. But the authorization boundary and the evidence requirement reach the participant who can enforce each one.

“The agent and the human babysit each other”

That is the deliberately informal way we describe the loop inside Wagglet.

The agent can keep the detailed written task in the active context, surface a shared QA requirement or ask for a human action named in its own instructions, and refuse or ask when an explicit stop condition is reached. It can help a runner who did not author the task understand what comes next.

The human can see the real environment, provide authorized access, notice that the result looks wrong, run the judgment-heavy check, correct course, or stop the work altogether.

Neither side becomes infallible. Models can ignore or misread instructions. People can skim, over-trust a plausible answer, or perform a check mechanically. The point is not that every word is guaranteed to survive. The point is that important information has a durable place, and each participant receives an explicit responsibility for carrying it through the handoff.

Research gives us a reason to be careful here. A 2024 preregistered meta-analysis of 106 experiments found that human-AI combinations, on average, performed worse than the better of the human or AI alone, even though they outperformed humans alone on average. Results varied substantially by task. That does not test the Dual Prompt or Wagglet, but it does reject the slogan that adding a human to AI automatically creates a superior team. Read the open-access study, When combinations of humans and AI are useful.

The design problem is therefore not “put a human in the loop.” It is:

• put the right context in front of the agent;
• give the human a check they can actually perform;
• define the decisions neither participant may improvise;
• preserve evidence so a separate reviewer can accept or reject the result.

Why this changed how I write tasks

Before this pattern, detail felt perishable. I could write a careful paragraph, but I still expected to repeat it aloud when the teammate reached that part of the work. So I wrote less than I knew.

Now I write the detailed version because it has an operational reader. The agent receives the context, constraints, prior discussion, and definition of done. The runner receives a short role they can act on. If the agent gets lost, the written brief remains the common reference. If the runner is unsure, the task says when to ask rather than forcing them to guess.

There is an encouraging—though still observational—signal in Anthropic's 2026 analysis of roughly 400,000 Claude Code sessions. Its classifiers attributed about 70% of planning decisions to people and about 80% of execution decisions to Claude in a typical session. The study also found that task-specific domain expertise was associated with better outcomes. Anthropic did not observe every real-world outcome, used model-based classifiers, and did not study Wagglet, so this is not causal validation. It is evidence that a real division between deciding what counts as done and executing how to do it already appears in agentic work. See Agentic coding and persistent returns to expertise.

The Dual Prompt makes that division explicit enough to hand from one person to another. The author can contribute deep task knowledge without personally sitting beside the agent for the entire run. The runner can contribute attention, access, judgment, and verification without pretending to have authored every technical decision.

How Wagglet carries the two sides

Wagglet stores LLM instructions and Human instructions as separate parts of the same task.

The LLM instructions are the actual agent brief. When a teammate claims the task, Wagglet can prepare a bounded Task Handoff containing the relevant task, project, repository, attachments, discussion, rework feedback, and related-work context. The agent can refresh authorized context while the claim is active, but the starting credential cannot browse the board, edit the task, or deliver work.

The Human instructions are for the runner and are not copied into the agent prompt. Wagglet also shows the runner the operating sequence and any configured QA requirements. When the work is ready, a separate delivery step lets the same agent session report the branch, outcome, changes, warnings, and useful failure information.

Delivery is not acceptance. An authorized reviewer still decides whether the evidence meets the task. That separation matters: the participant who did the work records what happened; the participant responsible for the outcome decides whether it is done.

For the exact current mechanics, read the Wagglet Task Handoff Skill.

Where the pattern should stop

The Dual Prompt is a task-design pattern, not a license to send every kind of work through an agent.

Do not use it to give an unqualified runner responsibility for a high-risk decision. Do not put credentials or unnecessary sensitive data into either instruction field. Do not turn a human check into ceremonial approval. Do not assume that detailed prose substitutes for tests, permissions, reversible actions, or an expert reviewer.

Some work should remain human-only. Some agent work needs a specialist at the controls. Some tasks are too ambiguous to hand off until the author narrows them. A useful Dual Prompt makes those limits visible instead of hiding them behind “use your judgment.”

A reusable starting template

For the agent:

Outcome:
Relevant context:
In scope:
Out of scope:
Constraints and permissions:
Evidence required:
Stop and escalate when:
Delivery format:

For the human:

Why this matters:
How to start:
What only you can provide or decide:
What to inspect:
Do not proceed when:
Who to ask:
How to record the outcome:

The best pair is asymmetric, specific, and short enough to use. The agent gets enough context to do serious work. The human gets enough clarity to supervise it seriously.

That is the shift: we are no longer writing a task for a person or a prompt for a model. We are designing one accountable unit of work for a human-agent pair.

If your team already passes agent work from one person to another, start with one bounded task and write both sides. Wagglet is being built to make that handoff explicit, reviewable, and repeatable.