A Telegram reply can depend on a model or another service. Treat that external call as a separate step with a clear input, expected output and failure behavior.
Keep the conversation understandable
Acknowledge the request when the result may take time. Avoid presenting an unfinished action as completed. A short status is useful only when it explains what the user can expect next.
Define the call boundary
Keep Telegram handling separate from the external adapter. Give the adapter a small contract: input, response shape and the errors the application understands. This makes it possible to change providers without rewriting the conversation.
Review retries as a product decision
Ask whether repeating the call can repeat a side effect. A model response and a payment operation need different retry policies. Choose a bounded policy and a clear fallback rather than retrying indefinitely.
Validate before showing the answer
If the next step requires structured data, validate the response before using it. Missing fields and invalid values need a defined path. For a consequential action, keep a human confirmation step between the suggestion and execution.
Make failures diagnosable
Record which step failed and the information needed to investigate it without copying sensitive conversation data into logs. Review the ordinary success case, a timeout, an invalid response and a user who changes their request.