What you will be able to do
- Read what each step of a long task depends on and pick the Databricks strategy that keeps that dependency
- Justify a replacement by naming the specific characteristic that makes the original strategy insufficient
- Enable and drive Supervisor Agent task continuation correctly over the streaming API
1.Read what each step depends on
To choose a replacement strategy, ask one question about the task: what does the next step need in order to run? The documentation does not use "dependency structure" as a formal term. The dependencies it does describe line up cleanly with the available strategies.
If the next step depends on the exact earlier steps of the same interaction, the agent needs its ordered transcript. A managed session keeps that. Its service keeps "a deterministic order for a session's items," and items cannot be changed once appended. That is what an agent replays to continue where it was.
If the next step depends on facts from earlier, unrelated conversations, an ordered transcript is the wrong tool. Managed memory stores durable entries for an actor and returns the most relevant ones by search. The overview page describes this as semantic search. The managed memory page specifies that search ranks entries with a full-text (BM25) relevance score. Either way, the result is a set of relevant pieces ranked by relevance, not a replayable history.
Both stores are backed by Lakebase, but the shared backing does not make them interchangeable. What separates them is scope: a session belongs to one interaction, and memory belongs to a subject across conversations.
If the next step depends only on the previous step finishing, inside one long request, the problem is time, and Supervisor Agent long-running task mode is the replacement.
If the steps never vary, so the next step is always known in advance, a dynamic agent may be the mismatch. In a deterministic chain, "The LLM does not make decisions about which tools to call or in what order." The design-patterns guidance recommends chains "For well-defined tasks with predictable workflows." A single dynamic agent, by contrast, "Must guard against repeated or incorrect tool calls."
If the work splits into separable pieces that do not need each other's results, such as distinct problem areas or skill sets, one agent carrying everything can become unwieldy. The design-patterns guidance points to a multi-agent system when "You have distinct problem areas or skill sets such as a coding agent or a finance agent." Each agent has its own domain, context and tool set, so one piece does not have to share a single agent's context with the others. The harness guidance also notes that sandboxes make it possible to run many agents in parallel at scale. The sources do not quantify a throughput benefit, and they list the cost: multi-agent systems are harder to orchestrate, trace and debug.
| Next step depends on | Strategy | Why it fits |
|---|---|---|
| Prior steps of this same interaction, in order | Managed agent sessions | Ordered, immutable items replayed to continue the interaction |
| Facts or decisions from separate, earlier conversations | Managed agent memory | Subject-scoped entries retrieved by search across conversations |
| Previous step finishing, within one long request | Long-running task mode | Splits the run into request/response cycles at step boundaries |
| A fixed, known-in-advance sequence | Deterministic chain | Developer fixes tools and order; no on-the-fly decisions |
| Separable pieces in distinct problem areas, not needing each other's results | Multi-agent system | Each specialized agent owns its own domain, context and tools |
Checkpoint 1 of 5· Exam question
A single agent processes 50 unrelated documents one at a time in a sequential loop: summarize document 1, then document 2, and so on, where no document's summary depends on any other document's content or result. Throughput is far below what the underlying compute could support. What characteristic of this task makes the sequential single-agent loop an insufficient long-horizon strategy?
Correct answer: A — The subtasks are fully independent, so handling them one at a time forfeits available parallel throughput
- A. Correct. When subtasks share no dependencies, running them one after another in a single agent is a strategy mismatch - the task's structure allows parallel dispatch to multiple sub-agents, and a sequential loop leaves that throughput unused.
- B. Incorrect. The scenario states the documents are unrelated with no shared state; a shared mutable record would be a reason to serialize work, which is the opposite of what's described.
- C. Incorrect. The failure here is about throughput, not about losing an early fact; long-range recall is not part of this scenario.
- D. Incorrect. The scenario explicitly says no document's summary depends on another document, so there is no such step-to-step dependency to account for.
2.Justify the switch: name what the original cannot do
Saying "use X instead" is not a full answer. The justification has to name the specific characteristic that makes the original strategy insufficient for this task. Each case below pairs a documented failure with that characteristic.
Sessions are scoped to one interaction. A session holds that interaction's working state and is later cleared or ages out. The replacement is managed memory, which holds facts scoped to the subject (the user) and recalls them in later conversations. The documented bridge is to distill durable facts out of the session and write them to memory. Most use cases use both stores together.
Memory retrieval returns the most relevant entries ranked by relevance score, not the ordered transcript of messages, tool calls and results. Continuing an interaction depends on that order. The replacement is a managed session, whose service keeps items in a deterministic order and can rebuild full context on a follow-up.
Continuation can only checkpoint between steps, and this timeout happens inside a single step. The documentation states that support for timeouts during individual tool or model calls is not yet available. The design-patterns advice to set iteration limits or timeouts is aimed at runaway tool-calling loops. It does not give continuation a way to checkpoint inside a step. The continuation documentation describes no supported fix for a single call that exceeds the timeout. The correct diagnosis is that the step itself is too long, not that continuation is misconfigured.
Neither strategy checks the work. The harness guidance calls for feedback loops after each action that let an agent keep "catching errors and correcting course automatically." Pair that with iteration limits or timeouts so the retry loop cannot run without end.
Checkpoint 2 of 5· Check yourself
A dynamic single agent runs a nightly report job whose steps never change: retrieve, augment, generate. Failure reports show occasional repeated and incorrect tool calls. Which replacement does the guidance support, and why?
The deciding characteristic is that the steps are predictable. That removes the need for on-the-fly decisions, which are the source of repeated or incorrect tool calls in a dynamic agent.
“The LLM does not make decisions about which tools to call or in what order.”Source: docs.databricks.com
Checkpoint 3 of 5· Exam question
Which Databricks capability is typically used to give a long-horizon agent durable, resumable state that survives across steps or sessions?
Correct answer: A — Lakebase
- A. Correct. Lakebase provides a managed Postgres-backed state store that agents can use to persist progress and state durably outside the model's context, enabling resumability across steps or sessions.
- B. Incorrect. AI Search (formerly Vector Search) serves retrieval over indexed documents; it is not designed to hold an agent's evolving task-execution state.
- C. Incorrect. A Genie space is a natural-language-to-SQL interface over registered tables; it does not provide a durable state store for agent progress.
- D. Incorrect. Unity Catalog functions expose callable tools to an agent; they do not themselves persist an agent's long-horizon execution state.
- E. Incorrect. An Agent Skill is a packaged, discoverable capability definition (a Markdown file with front-matter); it is not a mechanism for persisting task state.
3.Applying the continuation replacement correctly
When the diagnosis is many steps adding up past the API timeout, switching to task continuation is the right choice. It can still fail if it is wired up wrong. In AI Playground, continuation is automatic: Playground sends the continuation response for you, and you see one uninterrupted conversation. A client that calls the streaming API directly has to do this work itself. It must detect task_continue_request events and send a follow-up request.
Note that the documentation shows the initial request with an input field and the follow-up example with a messages field. This lesson reproduces both shapes as the page gives them. Use the page's own examples as the reference for the exact field names.
Checkpoint 4 of 5· Fill the gap
Which option in databricks_options turns on long-running task mode?
{
"input": [{ "role": "user", "content": "Your message here" }],
"databricks_options": {
" ? ": true
},
"stream": true
}Long-running task mode is enabled by setting "long_task": true inside databricks_options on a streaming request.
Source: docs.databricks.comThe follow-up request carries the earlier messages, the original task_continue_request, and a task_continue_response whose continue_request_id echoes that request's id. It sets "long_task": true again. A client that works in Playground but stalls in production has usually missed this detect-and-respond step.
Checkpoint 5 of 5· Check yourself
A custom app calls a Supervisor Agent over the streaming API with long_task enabled. The same task completes in AI Playground, but in the app it stops after the first task_continue_request. What is the most likely cause?
Playground handles continuation automatically. Over the streaming API the application must detect the event and resume the task, with continue_request_id matching the request id.
“When using the streaming API directly, your application must detect task_continue_request events and send a follow-up request to continue the task.”Source: docs.databricks.com
Sources6
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Managed agent memory can stand in for session history when an agent has to resume a run.Why is that wrong?
Memory search returns the most relevant entries ranked by relevance score, not an ordered transcript. Resuming one interaction depends on the ordered items that a managed session keeps.
Covered in Read what each step depends on
2.Because continuation works seamlessly in AI Playground, a direct API client gets the same behaviour just by setting long_task.Why is that wrong?
Playground sends the continuation response for you. A direct streaming client must detect task_continue_request and send the follow-up request itself.
Practise it for real
Drive a Supervisor Agent long-running task over the streaming API, handling continuation yourself instead of relying on Playground
1.Send a streaming request to your Supervisor Agent endpoint with a multi-tool task in input and "databricks_options": {"long_task": true}, plus "stream": true
Why: Long-running task mode is opt-in per request
You should see: The supervisor starts calling tools and streaming output
2.Watch the stream for a response.output_item.done event whose item.type is task_continue_request, and record its id and step
Why: This event marks the checkpoint where the supervisor paused before the timeout
You should see: An item like {"type": "task_continue_request", "id": "continue_<unique-id>", "step": 16}
3.Send a follow-up request shaped like the documentation's continuation example: the earlier messages, the original task_continue_request, and a task_continue_response with continue_request_id set to the recorded id, keeping long_task true
Why: The continue_request_id must match the id from the task_continue_request
You should see: The supervisor picks up where it left off and keeps working
4.Repeat the detect-and-respond loop until no further task_continue_request appears, comparing the step value at each checkpoint
Why: step reports the total tool-call steps completed so far, so it shows progress across cycles
You should see: The task completes after one or more continuation cycles
Stuck? Get a nudge
If a request still times out with no continuation event, look for one tool or model call that runs past the timeout by itself. Continuation cannot checkpoint inside a single step.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“The service maintains a deterministic order for a session's items”
↩︎ Read what each step depends on“Items are immutable after they are appended.”
↩︎ Read what each step depends on - 2.
“Search returns the most relevant entries ranked by a full-text (BM25) relevance score.”
↩︎ Read what each step depends on“Search returns the most relevant entries ranked by a full-text (BM25) relevance score.”
↩︎ Exam trap 1 - 3.
“retrieved by semantic search”
↩︎ Read what each step depends on“As a session accumulates, an agent (or your application) distills the durable facts out of it and writes them to memory.”
↩︎ Justify the switch: name what the original cannot do“Persist and resume an agent's session state so an interaction survives restarts”
↩︎ Prediction - 4.
“For well-defined tasks with predictable workflows.”
↩︎ Read what each step depends on“Must guard against repeated or incorrect tool calls”
↩︎ Read what each step depends on“You have distinct problem areas or skill sets such as a coding agent or a finance agent.”
↩︎ Read what each step depends on“Infinite loops can occur in any tool-calling scenario, so set iteration limits or timeouts.”
↩︎ Justify the switch: name what the original cannot do“The LLM does not make decisions about which tools to call or in what order.”
↩︎ Checkpoint - 5.https://www.databricks.com/blog/ai-harnessSecondary source
“They also make it possible to run many agents in parallel at scale.”
↩︎ Read what each step depends on“repeatedly attempting work, checking results, catching errors and correcting course automatically.”
↩︎ Justify the switch: name what the original cannot do - 6.https://docs.databricks.com/aws/en/agents/agent-bricks/multi-agent-supervisor-long-running-tasksOfficial docs
“Full long-running agent support, including timeouts during individual tool calls or model calls, is not yet available.”
↩︎ Justify the switch: name what the original cannot do“The continue_request_id must match the id from the task_continue_request.”
↩︎ Applying the continuation replacement correctly“In AI Playground, Playground automatically handles task continuation.”
↩︎ Applying the continuation replacement correctly“In AI Playground, Playground automatically handles task continuation.”
↩︎ Exam trap 2“When using the streaming API directly, your application must detect task_continue_request events and send a follow-up request to continue the task.”
↩︎ Checkpoint