Every long-running agent hits the same wall: the context window can't hold everything the task needs. This is a structural certainty, not an edge case, for any agent running multi-step tasks over a bounded window. Here's how Aiden's firmware handles it, and why, shipped this week across #497, #498, #530.
Two overflow conditions, one bad outcome
Cumulative overflow: enough turns accumulate that history exceeds the limit, even with no single large message. Single-event overflow: one tool call returns more than fits, regardless of prior history.
Two naive responses exist, both unacceptable in production:
- Hard failure — task stops, no resume path.
- Blind restart — agent repeats work it already did, because it lost the record of what happened. On a physical agent that can tap buttons and submit forms, this isn't cosmetic. A context error says nothing about whether the external device state changed.
What shipped: three coordinated behaviors
Context compression — reduces active material. Explicitly lossy; never sufficient alone to justify continuing.
Session switching — moves to a fresh session. Still requires preserved task info; not a blank-slate restart.
Saved-result-file recovery — the core mechanism. Task state persists outside the active context window, read back deliberately at recovery time.
The recovery read: four pieces of evidence
Before deciding whether to continue, the system reads:
| Field | Purpose |
|---|---|
| Continuation ID | Anchors recovery to the specific execution chain |
| Saved state | Progress: completed, pending, current phase |
| Saved errors | Distinguishes benign overflow from a different failure |
| Output tail | Recent activity clue — not a full execution history |
The actual design contribution is the three-way branch: continue, verify-then-retry, or stop-and-surface-to-user. Not binary continue-or-fail. Treating "uncertain" as a first-class outcome, distinct from success and failure, is what makes this a decision rather than a default.
overflow detected
→ compress context / switch session
→ read saved result file
→ continuation ID, state, errors, output tail
→ enough evidence to continue safely?
yes → resume
no/unclear → stop, surface to user
Why external state, not in-context summarization
Task bookkeeping (what step, what a tool returned, what errored) isn't reasoning content — it doesn't need to survive in the same budget-constrained space the model uses to think. Conflating the two means an overflow event destroys both simultaneously. Externalizing bookkeeping means overflow only costs the reasoning state, not the facts about what happened.
Related prior art: LangGraph's durable execution checkpoints workflow state for resume-from-last-step. OpenAI's conversation-state guidance offers persistent conversation objects to avoid re-deriving context per request. Aiden's approach is closer to the checkpoint model — the artifact is read selectively (four fields), not replayed wholesale.
Ties to the broader reliability loop
Aiden's device-interaction loop follows observe → interpret → act → verify — a conceptual pattern, not a specific architecture claim. Context recovery adds a continuity check: inspect persisted evidence before the next action, and for interface-facing tasks, re-observe the current interface rather than trust a stale checkpoint. Saved record = what the agent believed happened. Fresh observation = what's currently true. Neither substitutes for the other.
Explicit limits
- Compression is lossy by construction.
- Saved state can be missing, stale, partial, or corrupted — recovery has to handle an untrustworthy artifact, not just the happy path.
- Doesn't cover provider outages, network failures, unrelated tool failures, auth issues, or unexpected device states.
- No formal exactly-once execution guarantee — this reduces duplicate/lost work, it doesn't eliminate it.
Test matrix
| Test area | What to validate |
|---|---|
| Provider-limit recovery | All four evidence fields read before continuation |
| Oversized tool outputs | No silent discarding of critical info |
| Malformed saved files | Fails safely, not silently |
| Partial completion | Correct behavior mid-step interruption |
| Duplicate-action risk | Distinguishes completed / partial / unstarted work |
| Session handoff | Bounded relevant info, not a blind start |
| Changed device state | Forces fresh observation, doesn't trust stale checkpoint |
| Human controls | Pause/redirect/confirm function mid-recovery |
The malformed-file and changed-device-state tests specifically expose implementations that look correct in a demo and fail under real conditions.
Honest summary
Turns one common failure — running out of context mid-task — into a decision grounded in persisted evidence instead of "restart and hope." No unlimited context, no guarantee every task finishes safely, no replacement for human oversight on consequential actions.
Firmware: github.com/AidenAI-IO/aiden-firmware
Discord: discord.com/invite/bcJavjcnYz
Top comments (0)