DocumentationReplies
Replies — sending assistant messages
post_reply is the only way your agent's words reach the user. Your agent's own output is never shown automatically.
Transport
With MCP your agent calls these tools itself; with the HTTP API your backend makes the calls. The tools are identical.
#The one rule
Nothing is visible until your agent sends it: Whatever your AI model produces stays invisible to the user until your agent calls post_reply. If a run ends without a reply, the user sees nothing and the run times out.
Nobody has to tell ONBF *who* to reply to. The run key from the webhook already identifies the user, the conversation and the run — so post_reply carries only the message itself.
| What your agent sends | Required | Meaning |
|---|---|---|
message | Yes | The text the user will see. Up to 50,000 characters. |
idempotencyKey | Recommended | A label for this specific message, e.g. reply:<run>:1. If a retry sends the same key twice, the user still sees it once. |
#Who sends the reply
Nothing for you to build. Once your platform is pointed at ONBF's MCP server, your agent already has post_reply in its tool list and does the calling itself, mid-run, whenever it decides to. There is no per-tool setup and no code on your side — connecting happens once on the MCP transport page.
The only thing worth checking is that the run's credential reaches the tool call — see Connect it to a run.
#Timing
- Something must arrive within 60 seconds. A short "I'm working on it" counts — a good agent sends that first, then keeps posting as it goes.
- The first reply completes the run's turn. Your agent can keep sending more messages while the run key is still valid; they don't reopen the run.
- Each intended message should use a different idempotency key:
reply:<run>:ack,reply:<run>:progress-1,reply:<run>:final. - If a run is cancelled, work should stop. A reply from a cancelled run is rejected.
This one IS your job: acknowledge the webhook first: Answering the webhook and replying to the user are two separate operations, and the acknowledgement is your backend's responsibility — not your agent's. Return 200 immediately, then let the agent do the work. A slow model call before acknowledging causes timeouts and duplicate runs. See Test it.
#What doesn't belong in a reply
- Files. Real files are delivered as attachments with Files — never base64 or long file contents pasted into a message.
- Billable work. If something needs scope, approval or payment, that's Jobs. A chat message alone never creates or settles a job.
- Raw errors. If something upstream fails, a short plain-language explanation beats a stack trace.