Agent Completions: each call is a new thread, owned by your user

Each Agent Completion runs in a new thread. Sume's docs list four things as not available yet: continuing a prior thread with thread_id, assistant turns in messages[], team-owned threads, and non-image attachments. So treat each call as a one-shot task and put everything the Agent needs into that one request.

What the docs say today

These all come from the 'Not available yet' and errors sections of Agent Completions. The thread_id in the receipt identifies the new thread.

How to design around it

Because the API rejects assistant turns instead of ignoring them, you cannot replay a past chat to give the Agent memory. Pass what it needs in instruction, or in the input field, which Sume writes to a file in the sandbox and treats as data, not instructions.

For a multi-step task, put the whole task in one completion, or run several completions and join their outputs yourself. generation_spend_cap_usd is required on every call and applies to that run only.

• Store your own conversation state in your backend.
• Send output_schema if you want a structured answer to feed the next call.
• Poll the receipt's status; the create call returns 202, not a result.

The tradeoff

A stateless model is simpler to reason about and to cap, because each run has its own spend limit and its own sandbox. It is more work for you if you were hoping to hold a long conversation with one agent through the API. If that is the use case, Agent Completions does not fit it yet, and the docs give no date for continuation.

If you do need memory across steps, keep the state in your own store and pass a compact summary in the next call's instruction. Keep that summary free of secrets, because it goes to an agent with tool access. For one-off tasks that change each time, the docs recommend Agent Completions over a saved schedule.