The settings below are configuration contracts. They do not prove working scheduling, background execution, speech timing, retries, or live tool calls. See current availability before building a conversation integration.
Timing and response settings
For client tools, also review
expects_response. MCP tools have their own approval policy. Use the exact tool schema instead of copying settings across tool types.
Prepare a result contract
1
Define success
Specify which result proves that the action completed. For a write operation, include a stable record identifier or another way your service can check the final state.
2
Define uncertainty
Decide what happens when a timeout occurs after the service may have accepted a request. A timeout is not proof of failure. Design duplicate-request handling in the service that owns the action.
3
Review error exposure
Avoid returning credentials, private records, or internal diagnostics in an error intended for the conversation. Do not depend on a saved error-handling mode as proof that sensitive output will be removed.
4
Separate the checks
First reopen the dashboard tool to confirm its saved settings. Next inspect the agent’s attachment in a draft. Keep actual invocation and result verification pending until the relevant execution path is available.
Frequently asked questions
Does async create a background job?
Does async create a background job?
The enum records the requested mode. This guide does not establish a released background-execution mechanism, retry policy, or delivery guarantee.
Can I retry every failed call automatically?
Can I retry every failed call automatically?
A write may have completed even if its response was lost. Your service needs a way to recognize repeated requests and inspect uncertain outcomes before retrying.