What you will be able to do
- Match a documented long-running agent failure to the limit it hit: request timeout, context growth, looping or early stopping, or state scope
- Explain what Supervisor Agent task continuation checkpoints, and the case it does not cover
- Tell managed agent sessions and managed agent memory apart by the scope of state each one keeps
Key concept
Long-horizon strategy mismatch — A failure where the strategy in place deals with a different limit from the one the task actually runs into. Each Databricks mechanism covers one specific limit: time per request, continuity inside one interaction, or continuity across conversations. Applying it to any other limit leaves the failure in place.
1.Start from the symptom: which limit did the task hit?
A long-running agent task does not fail at random. Its failure report usually shows one of a few signatures, and each one points to a different missing strategy. Before you replace anything, read the symptom and name the limit it shows.
The first limit is time per request. Some Supervisor Agent tasks need many tool calls, and such a task "might need more time than a single API request allows." The symptom is a task that dies at the API timeout even though every individual step is working.
The second limit is context growth. Databricks' harness guidance calls this context rot: "As conversation history grows, the model’s reasoning quality degrades." Nothing times out, but quality falls as the run gets longer. The matching strategy is context compaction, where the harness "decides what stays active and what gets summarized."
The third limit is runaway looping. The design-patterns documentation says that compared with a hard-coded chain, a tool-calling agent must guard against repeated or invalid tool calls, and that infinite loops can occur in any tool-calling scenario.
The fourth limit is verification, which is a different failure from looping. Here the agent stops, not too late but too early. The harness guidance warns that without testing loops or self-checks, agents "may stop too early or declare success on incomplete work." A runaway loop needs a limit. An early stop needs a check after each action.
The fifth limit is the scope of state. Some state has to survive a restart within one interaction. Other state has to still matter in a later, unrelated conversation. These are different requirements, and the last section of this page separates them.
| Observed failure | Limit hit | Strategy that addresses it |
|---|---|---|
| Task fails at the API timeout partway through many tool calls | Time per request | Long-running task mode (task continuation) |
| Quality degrades as history grows; no timeout | Context growth | Context compaction: trim or summarize older context |
| Agent repeats tool calls without end | Loop control | Iteration limits or timeouts |
| Agent declares success on incomplete work | Verification | Testing loops or self-checks after each action |
| Interaction lost on restart, or facts forgotten in a later conversation | Scope of state | Managed agent sessions or managed agent memory |
Checkpoint 1 of 6· Check yourself
A tool-calling agent's trace shows the same tool called again and again with no resolution, until the job is killed by hand. What does the Databricks guidance prescribe for this signature?
An unbounded loop is a loop-control failure. Continuation would only let it run longer. The documented guard is an iteration limit or timeout.
“Infinite loops can occur in any tool-calling scenario, so set iteration limits or timeouts.”Source: docs.databricks.com
Beyond the limits above, a long task can also be badly shaped for the strategy running it. The Databricks sources describe three strategies for this, and none of them uses the phrase "dependency structure". The mapping below is this lesson's reading of how they apply.
- Reactive execution with feedback loops. Where each step's result decides the next step, the harness can run tests, inspect results or have the model review its own output, so the agent can repeat "attempting work, checking results, catching errors and correcting course." This is the documented basis for re-planning mid-task: the agent corrects course from observed results rather than following a fixed plan. - Deterministic chain. Where the steps are known up front, a chain is predictable and easy to audit. It is also inflexible and "requires code changes to adapt", so it breaks when a long task needs different steps for different inputs. - Multi-agent decomposition. Where a task spans distinct problem areas, or has too many tools for one agent, a supervisor can delegate to specialized agents that each own a subset. The cost is that it is complex to orchestrate and harder to trace and debug, and the guidance is to start simple and add agents only when needed.
The sources give no guidance on running subtasks in parallel as a long-horizon strategy, so this lesson does not teach one. Decomposition addresses a task that is too broad for one agent. It does not address a request timeout, context rot or lost state.
Checkpoint 2 of 6· Check yourself
A coding agent finishes a long task and reports success. Later review shows that half of the requested changes were never made. No timeout, loop or error appears in the trace. Which strategy does the Databricks guidance point to?
Declaring success on incomplete work is a verification failure, not a looping or timeout failure. The harness should check the work after each action. Limits and extra time do not make an agent verify.
“Without testing loops or self-checks, agents may stop too early or declare success on incomplete work.”Source: www.databricks.com
2.Checkpointing a long task: Supervisor Agent task continuation
For the time-per-request limit, Supervisor Agent offers long-running task mode. In this mode the supervisor "automatically breaks long tasks into multiple request/response cycles so the agent can continue working without timing out." The cycle is a checkpoint-and-resume loop. The supervisor works until just before the request would time out. It then pauses and emits an event that tells the client to come back.
{
"type": "response.output_item.done",
"item": {
"type": "task_continue_request",
"id": "continue_<unique-id>",
"step": 16
},
"id": "resp_<response-id>"
}The step field gives the total number of tool-call steps completed so far. That makes it a useful marker of progress when you read a failure report. The client resumes by sending a follow-up request containing the task_continue_request and a matching task_continue_response. The supervisor "picks up where it left off and continues working," and the cycle repeats until the task is complete.
Checkpoint 3 of 6· Put it in order
Put the task-continuation cycle in order
- 1.The supervisor starts processing the request, calling tools and reasoning
- 2.The application sends a follow-up request with the task_continue_request and a task_continue_response
- 3.The supervisor picks up where it left off, repeating the cycle until the task is complete
- 4.Before the request times out, the supervisor pauses and emits a task_continue_request event
Continuation is triggered by the supervisor as the timeout approaches. The client's follow-up request then resumes the work.
“Before the request times out, the supervisor pauses execution and emits a task_continue_request event in the streaming response.”Source: docs.databricks.com
The characteristic that limits this strategy is where the checkpoint can fall. A pause can happen only between steps. If one tool call or one model call runs past the API timeout by itself, there is no point inside it where the supervisor can pause, so the request can still time out. The documentation is explicit that full long-running support, including timeouts during individual tool calls or model calls, "is not yet available." So when a long_task-enabled supervisor still times out, check whether the failure comes from many steps adding up or from one step that is too long on its own.
Checkpoint 4 of 6· Check yourself
A supervisor has "long_task": true and handles continuation correctly. It still times out, and the trace shows the timeout during one very slow sub-agent call. What explains this?
Continuation splits work at step boundaries. A single call that is longer than the timeout has no boundary inside it where the supervisor can pause.
“the continuation checkpoint can only be triggered between steps”Source: docs.databricks.com
Task continuation is one kind of checkpointing. It is not the only one, and it covers only one failure: a request that runs out of time. The documentation describes it only as a response to the API timeout. It does not describe a restart of the compute or process. A different failure is progress that is lost when a run is interrupted and has to start again.
For that, the Databricks harness guidance names persistent storage: it "allows agents to accumulate progress across long-running tasks," through a filesystem where an agent can keep "notes, plans and intermediate work that persist between sessions." Managed agent sessions are also built so an interaction survives restarts, and a framework that serializes its own state, such as a LangGraph graph, can persist it as session items. In both cases the progress is kept in a durable store outside the running process, and the agent resumes from what was stored.
The next question tests which of these strategies matches a failure.
Checkpoint 5 of 6· Exam question
An agent runs a multi-hour data migration made up of hundreds of sequential steps. It tracks its progress only inside its conversation context. When the underlying compute restarts after a transient failure at step 240, the agent has no record of what already completed and restarts the entire migration from step 1, wasting hours of work. Which replacement strategy most directly addresses this failure?
Correct answer: A — Persist step-by-step progress to a durable external state store so execution resumes from the last completed step
- A. Correct. Writing checkpoint progress to a durable store outside the agent's context (for example, a Lakebase-backed state store) lets the agent resume from the last completed step instead of losing all progress on a restart.
- B. Incorrect. An upfront plan describes the order of steps, not where completed progress is recorded; removing checkpoints would make the resume problem worse, not better.
- C. Incorrect. Restarting the full pipeline from scratch in each sub-agent does not solve the loss of completed progress - it reproduces the same problem across multiple agents.
- D. Incorrect. More frequent compaction summarizes context to save tokens but does not survive a compute restart; in-context state is lost regardless of how it was compacted.
- E. Incorrect. Few-shot examples shape output style and are fixed at design time; they cannot reconstruct which of 240 steps actually completed after a restart.
Use the question to check the pairing of failure and strategy. Task continuation fits a request that runs out of time between steps, and it does not by itself keep progress through a restart. Context compaction fits history that grows until quality degrades, and it does not preserve progress. Splitting work across sub-agents fits a task that spans distinct domains or tool sets, and it adds orchestration overhead without making any one agent's progress durable. When progress is lost on a restart, the matching strategy is to keep it in durable storage.
3.State-scope mismatches: sessions versus memory
The last limit, scope of state, has two halves. Databricks provides a managed store for each, both backed by Lakebase.
Managed agent sessions hold the state of one interaction, usually its conversation history: the ordered transcript of messages, tool calls and results. A session lets an interaction survive restarts and can rebuild full context on a follow-up. It is scoped to one interaction and "is complete on its own."
Managed agent memory holds durable facts, preferences and decisions scoped to a subject, not to an interaction. These are facts that "should still matter in a future, unrelated conversation." The two stores connect when an agent distills durable facts out of a session and writes them to memory. They stay independent: deleting a session, or a whole session store, does not delete memory.
A common misdiagnosis is to treat a session store as a checkpointing mechanism for a long run. Session stores persist whatever items the agent appends, but they don't add "runs, checkpoints, or approvals as first-class concepts." A framework that serializes such state can store it as items. The store itself does not pause and resume a task the way Supervisor Agent continuation does.
Checkpoint 6 of 6· Match them up
Match each mechanism to the limit it addresses
Tap a term, then the definition that fits it.
Each mechanism covers one limit. A mismatch means using one of them for a limit it does not cover.
“Sessions are scoped to one interaction: the working state the agent replays to continue that interaction, such as its conversation transcript.”Source: docs.databricks.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Long-running task mode also fixes quality loss on long runs, because it splits the work into smaller request/response cycles.Why is that wrong?
Continuation addresses time per request. The follow-up request carries the previous messages forward, so the history still grows. Quality loss from growing history needs context compaction.
Covered in Checkpointing a long task: Supervisor Agent task continuation
2.A managed memory store is the right place to keep the working state of a single in-progress interaction.Why is that wrong?
Memory is scoped to a subject, not an interaction, and holds durable facts for later, unrelated conversations. In-interaction state belongs in a session.
3.Any long task that struggles should be split across multiple specialized agents.Why is that wrong?
Multi-agent systems fit distinct domains or tool sets and add orchestration and debugging cost. The guidance is to start simple and add complexity only when needed. They do not fix timeouts, context rot or lost state by themselves.
Covered in Start from the symptom: which limit did the task hit?
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.databricks.com/aws/en/agents/agent-bricks/multi-agent-supervisor-long-running-tasksOfficial docs
“the supervisor supports long-running task mode, which automatically breaks long tasks into multiple request/response cycles so the agent can continue working without timing out.”
↩︎ Start from the symptom: which limit did the task hit?“The step field indicates the total number of tool call steps completed so far.”
↩︎ Checkpointing a long task: Supervisor Agent task continuation“The supervisor picks up where it left off and continues working.”
↩︎ Checkpointing a long task: Supervisor Agent task continuation“the continuation checkpoint can only be triggered between steps”
↩︎ Checkpointing a long task: Supervisor Agent task continuation“Include the original task_continue_request and a matching task_continue_response in the messages of your next request:”
↩︎ Exam trap 1“Before the request times out, the supervisor pauses execution and emits a task_continue_request event in the streaming response.”
↩︎ Checkpoint - 2.
“Infinite loops can occur in any tool-calling scenario, so set iteration limits or timeouts.”
↩︎ Start from the symptom: which limit did the task hit?“You have so many tools that fitting them all into one agent's schema is impractical; each agent can own a subset.”
↩︎ Start from the symptom: which limit did the task hit?“Can handle large, complex enterprise workflows that a single agent might struggle to manage cohesively.”
↩︎ Start from the symptom: which limit did the task hit?“start simple. Introduce more complex agentic behaviors when you truly need them”
↩︎ Exam trap 3 - 3.https://www.databricks.com/blog/ai-harnessSecondary source
“As conversations grow longer, the harness decides what stays active and what gets summarized, a process known as context compaction.”
↩︎ Start from the symptom: which limit did the task hit?“Without testing loops or self-checks, agents may stop too early or declare success on incomplete work.”
↩︎ Start from the symptom: which limit did the task hit?“repeatedly attempting work, checking results, catching errors and correcting course automatically”
↩︎ Start from the symptom: which limit did the task hit?“Persistent storage allows agents to accumulate progress across long-running tasks”
↩︎ Checkpointing a long task: Supervisor Agent task continuation“Without a strategy to trim or summarize older context, performance often breaks down on long-running tasks.”
↩︎ Prediction - 4.
“Persist an agent's conversation history so it survives restarts and can be resumed later.”
↩︎ Checkpointing a long task: Supervisor Agent task continuation“It doesn't add execution-control resources such as runs, checkpoints, or approvals as first-class concepts”
↩︎ State-scope mismatches: sessions versus memory - 5.
“Memories are scoped to a subject, not an interaction: the durable facts that should still matter in a future, unrelated conversation”
↩︎ State-scope mismatches: sessions versus memory“deleting a session, or an entire session store, does not delete memory retained in a memory store.”
↩︎ State-scope mismatches: sessions versus memory“sessions give the agent continuity within a conversation, and memory gives it continuity across conversations.”
↩︎ Key concept“Memories are scoped to a subject, not an interaction”
↩︎ Exam trap 2“Sessions are scoped to one interaction: the working state the agent replays to continue that interaction, such as its conversation transcript.”
↩︎ Checkpoint