Skip to content
MyDSHMy DSH Field Notes
中文
Independently maintained; not affiliated with DeepSeek. No association with mydsh.dev or other MyDSH sites.

All categories/Agents and automation

Designing agents · Level Advanced · Agents Agent Approval

Human in the loop: when to stop

The agent runs unattended and failures go unnoticed.

Prompt

Your first line in any agent design is what the agent must not do. Most failures come from unclear scope, sloppy tool contracts and missing failure handling, not from a weak model.

Task: The agent runs unattended and failures go unnoticed.

[Before you start, do three things]
1. Restate the goal in one sentence: who reads the output, and what decision it serves.
2. If I have not given you the following, ask me. Do not assume:
   - how irreversible the actions are
   - acceptable error rate
   - who reviews and how often
   - how work resumes after approval
3. Say how you plan to do it (at most 5 steps) and wait for my go-ahead.

[Go through each of these]
- list actions requiring review: payment, deletion, external send, permission change
- set a threshold by amount or impact
- the review UI shows the model's reasoning, not just the conclusion
- log every human correction for later evaluation

[Process]
1. Write the boundary: what it may do, must never do, and when to hand back to a human
2. Define each tool's inputs, outputs, failure semantics, idempotency
3. Write the flow as a state machine with exit conditions
4. Design failure paths: retry, degrade, abort, escalate
5. Give one testable success criterion

[Output]
Fixed shape: boundary, tool contracts, state machine, failure paths, criteria.

[Do not]
- No general-purpose agent that does everything
- Never let fuzzy prose stand in for a tool contract
- The agent must not decide whether approval is needed
- No 'do your best' instead of an abort condition

What to state before it starts

Leave these unsaid and the model fills them with an assumption. Most 'wrong answers' start here.

  • how irreversible the actions are
  • acceptable error rate
  • who reviews and how often
  • how work resumes after approval

Go through each of these

Where this kind of work most often goes wrong. Already in the prompt, so you do not have to remember it.

  • list actions requiring review: payment, deletion, external send, permission change
  • set a threshold by amount or impact
  • the review UI shows the model's reasoning, not just the conclusion
  • log every human correction for later evaluation