See the pattern in action, tap through the tabs below:
The problem: an agent runs great for the first hour of a multi-day DevOps task, then the session ends, the context window fills up, or someone closes their laptop. When work resumes, it has no idea what it already checked or decided. A human ends up re-briefing it from scratch, which cancels out the time saved.
The fix: checkpoint task state (not the chat transcript) to a shared file, so the next session picks up exactly where the last one stopped.
# Task: Postgres region migration status: in_progress owner: agent-session-14 ## Objective Migrate prod Postgres cluster to us-west-2b with zero data loss. ## Done - Schema compatibility audit complete - 2 of 3 flagged tables resolved (orders, invoices) ## Blocked - users_history table: needs manual review of custom trigger ## Constraint Do NOT run cutover script until replication lag is under 2s. ## Next action Resolve users_history trigger, then re-check replication lag.
$ agent resume --task migration-postgres-west > reading task-ledger.md ... > last checkpoint: day 1, 22:40 UTC > 2 of 3 flagged tables resolved > constraint loaded: cutover blocked until lag < 2s > resuming on: users_history trigger review session ready. no re-briefing required.
Try it this week: pick one recurring multi-day task your team already hands off between shifts, add a single markdown checkpoint file to the repo it touches, and have the agent update it at the start and end of every session: objective, done, in progress, blocked, next step. Run it for two weeks before reaching for heavier tooling.
The problem: agents that forget mid-job
Ask an AI agent to summarize a log file or draft a PR description, and it nails the job in one shot. Ask it to run a three-day database migration, a week-long security investigation, or a phased rollout across a dozen regions, and something different happens. The agent runs great for the first hour, then the session ends, the context window fills up, or someone closes their laptop for the night. When work picks back up, the agent has no idea what it already checked, what it decided, or what's still open. A human ends up re-briefing it from scratch, which quietly cancels out the time savings the automation was supposed to deliver.
This is the gap most teams hit once they move past demo-sized agent tasks into real DevOps work: anything that spans multiple sessions, multiple days, or multiple people. The fix isn't a bigger context window. It's a workflow for handing a task off, cleanly, from one agent session to the next.
What "automated long-running task handoffs" actually means
Automated long-running task handoffs are a pattern, not a product. The goal is simple to state and easy to get wrong in practice: when an agent's working session ends, whether because of a context limit, a timeout, or a shift change, the state of the task survives that boundary. The next session, even a different agent instance, picks up exactly where the last one stopped, with the same understanding of what's done, what's pending, and why certain decisions were made.
Done well, this turns a multi-day job into a relay race instead of a series of false starts. Done poorly, teams end up with agents that either re-do finished work, skip steps because they misremembered progress, or quietly drop constraints a human set hours earlier.
How it's built
Checkpoint the task, not the conversation
The naive approach is to save the chat transcript and replay it next session. That fails fast: transcripts are bulky, full of dead ends and abandoned approaches, and they burn through the next session's context before real work starts. The workflow that holds up is checkpointing task state instead of conversation history: a structured record of what's been completed, what artifacts were touched, what's still open, and any constraints or decisions that must carry forward. Frameworks like LangGraph's persistence and checkpointing layer are built around exactly this idea, snapshotting graph state so a run can pause and resume without replaying every step.
Summarize before you run out of room
Long tasks need a compaction step triggered before the context window fills up, not after. A practical pattern is to have the agent write a running summary at fixed intervals (every N tool calls, or every logical phase of the task) and treat that summary as the source of truth going forward, discarding the raw history it was built from. This is the same principle behind context-window management features in coding agents that compress old tool output while preserving the decisions that mattered.
A shared task ledger beats a chat log
The most durable version of this pattern lives outside the agent's context entirely, in a plain file the team can read too: a task ledger. Something as simple as a markdown or YAML file in the repo, updated by the agent at each checkpoint, listing objective, steps completed, current blockers, next action, and any secrets or credentials handling notes (never the secrets themselves). Because it's a file, not a conversation, any agent instance, and any human, can open it and know exactly where things stand. It also gives you an audit trail for free, which matters when the "long-running task" is something like a production migration.
A worked example: a three-day database migration
Picture a team migrating a production Postgres cluster to a new region over a long weekend. Day one, an agent audits schema compatibility, flags three tables needing manual review, and checkpoints that state to the task ledger before its session ends. Day two, a different engineer starts a fresh agent session. Instead of re-explaining the migration from scratch, the agent reads the ledger, sees the three flagged tables and the resolution already applied to two of them, and picks up on the third. It also sees a note from day one: "do not run the cutover script until replication lag is under 2 seconds," and treats that as a hard constraint rather than something it has to be reminded of. By day three, the handoff has happened twice with no human re-briefing, and the ledger doubles as the postmortem draft.
Where this breaks
Three failure modes show up often enough to plan for. First, stale context: if the ledger isn't updated at every meaningful checkpoint, the next session inherits an outdated picture and makes decisions on bad information. Second, summary drift: an agent summarizing its own work can quietly drop a caveat or constraint it decided wasn't important, so summaries should be reviewed at major checkpoints, not trusted blindly forever. Third, secrets creep: task ledgers are convenient for state, but they should never hold credentials, tokens, or customer data. Reference where secrets live; don't inline them.
Getting started this week
You don't need a full orchestration platform to try this. Pick one recurring multi-day task your team already hands off between shifts or people, add a single markdown checkpoint file to the repo it touches, and have the agent update it at the start and end of every session: objective, done, in progress, blocked, next step. Run it for two weeks before reaching for heavier tooling. Most of the value in this pattern comes from the discipline of checkpointing, not the sophistication of the storage layer.
FAQ
Do I need a specific agent framework to do this?
No. The pattern works with a plain markdown file and any agent that can read and write files. Frameworks like LangGraph add durable, automatic checkpointing for more complex multi-agent graphs, but a simple task ledger gets most teams most of the value with no new infrastructure.
How is this different from just giving the agent a longer context window?
A longer context window delays the problem, it doesn't solve it. Even generous context limits fill up on multi-day tasks, and raw conversation history is a worse handoff artifact than a structured summary regardless of size. Checkpointing task state, not transcripts, is what makes the handoff reliable.
What's the biggest mistake teams make when they try this?
Treating the checkpoint as optional. If updating the ledger is a "when I remember to" step, it becomes stale exactly when you need it most, mid-incident or mid-migration. Build the checkpoint into the workflow as a required step, the same way you'd require a commit message.
Want this workflow built out for your team's actual pipeline, with the checkpoint format and handoff rules tailored to your stack? Our DevOps Boot Camp covers this and other agent automation patterns hands-on.
