Using the deployed agent

You have deployed something. Now you use it, and using it is where the runtime vocabulary from lesson one stops being nouns on a page and starts being calls you make in order.

The order of operations

The shape of a conversation with a deployed agent is always the same. There is a thread, which is the state your conversation lives in. There is an assistant, which is the configuration deciding how the agent behaves, and you already have one because every graph gets a default. And there is a run, which is the thing you actually start: it takes that assistant configuration, applies it to that thread, and advances the thread’s checkpoint.

The first message creates or names a thread. Every message after that references the same thread, which is how the agent knows what you were talking about. That is the whole trick, and it is why “which identifier do I carry forward” is a real question with a boring answer.

Four statuses, and only four

A thread is always in exactly one of four states:

• idle: nothing is running against it
• busy: a run is in flight
• interrupted: execution paused, waiting to be resumed
• error: a run failed

The escape hatch: stateless runs

Not every call wants a conversation. The API separates Thread Runs from Stateless Runs, and that separation is the entire persistence question expressed as two groups of endpoints.

A thread run attaches to a thread and advances its checkpoint. A stateless run does not: no thread, no checkpoint, no history. You get the answer and none of the bookkeeping. Useful for one-shot classification or enrichment, useless for anything that has to remember.

When the user will not stop typing

The run starts. The user, being a human being, immediately sends another message. There are four documented strategies:

Learn it as that table rather than as four loose names, because the discriminating column is the third one. enqueue and reject both let the run finish and differ on the new input. interrupt and rollback both stop it and differ on the partial work. That second pair is the one most likely to be tested against itself, because the names sound like near-synonyms and are not.

The parameter you pass them under

The parameter is multitask_strategy, and the name carries a hint worth keeping: the platform’s word for double-texting is multitask, so if you are searching the docs for “double texting” and finding nothing, search for that instead.

The casing follows the usual split, and both forms are worth recognising:

// TypeScript SDK: camelCase on the client
await client.runs.create(threadId, assistantId, {
  input,
  multitaskStrategy: "interrupt",
});

// The HTTP API and the Python SDK: snake_case on the wire
// { "multitask_strategy": "interrupt" }

An option that offers something like on_conflict or concurrency_mode is built out of adjacent-sounding config vocabulary. on_conflict in particular is real, but it belongs to creating threads and assistants ("raise" or "do_nothing"), not to concurrent runs, which makes it the most convincing wrong answer available.