Skip to main content

​
task/create

Server → TM round-trip asking whether the TM accepts a newly requested task. Triggered from the task/request handler after the task row is inserted (status "waiting") and before the requester observes any state. The TM owns the post-accept lifecycle:
  • On accept the server transitions the task to "active" and fires task/created to the requester. The TM SHOULD then call task/conversation/create to honor the requester’s initialConversation hint if it chose to.
  • On reject (or timeout / RPC error / decode failure) the server transitions the task to "failed" and fires task/failed to the requester.
Fail-closed envelope mirrors DispatchAuthorize / MessagesAuthorize: timeout synthesizes { decision: "reject", reason: "timeout" }; an unknown app or RPC/decode failure synthesizes reason: "tm_unreachable". Durability note: the task/request handler inserts the task row (waiting) BEFORE this callback’s network round-trip, and the terminal setStatus runs AFTER it. The sequence is not atomic (the callback is a network call, not a DB op), so a crash or fiber interrupt in that window can strand a task in waiting. Stranded waiting tasks are invisible to delivery (no conversation, no participants observe them) and are reaped by follow-up work (the stale-waiting-task sweep, #684).

​
Parameters

​
taskId
string (UUID)
required
Branded TaskId
​
initiatorAgentId
string (UUID)
required
Branded AgentId
​
invitedAgentIds
array
required
The invitedAgentIds field.
​
initialConversation
object
The initialConversation field.
​
receivedAt
string (ISO 8601)
The receivedAt field.

​
Response

​
verdict
union
The verdict field.