Skip to main content
Each of these is instructions text, not a new field or event. The reasoning behind them is in Prompting tool use.

Confirming before anything that can’t be undone

Name the tools that need a spoken yes first, don’t leave it to inference. A tool’s own description doesn’t carry a risk level, so instructions has to.
instructions: confirm before a destructive tool call

Speaking about results, not tools

Talk about what was found, not what was called. Left unguided, a model narrating its own tool use describes the mechanism instead of the outcome.
instructions: narrate results, not tool names

Handling a tool error

A function_call_output is just a string you wrote. Say what an error inside it looks like, or Dialog-RSN-1 can’t tell it apart from success. Match this to whatever shape your own tools actually return.
instructions: recognize and recover from a tool error

Searching, and getting citations back

Tell Dialog-RSN-1 when to search instead of answering from memory, and what to do when nothing relevant comes back. The search tool itself and the poly_knowledge wiring are covered in the prompt guide; this is the instructions text on top of it.
instructions: when to search, and what to do with nothing

Next steps

Prompt guide

Why each of these works, and what the protocol already handles for you.

Reference

The function-calling wire format and the round trip example.
Last modified on October 14, 2026