Agent reliability across long runs: what happens when context fills up?

TL;DR: Long-running agents analyzing 20+ AWS accounts can lose early findings when the context window fills, according to Tetrate, because tool results accumulate faster than the run can finish. The practical fix is durable persistence, stable IDs, and preserved human decisions before a run truncates.

Editorial analysis by NHI Mgmt Group, based on content published by Tetrate: “Making Agents Reliable: Auto-Save, Stable IDs, and the Context Window Problem”.

Key questions

Q: What breaks when long-running agents depend on the context window for state?

A: They lose durable continuity when the conversation grows too large, which can truncate earlier findings, hide partial work, and make a crash indistinguishable from a successful run.

Q: Why should security teams persist agent findings before a run completes?

A: Because completion is not guaranteed.

Q: How do recurring agents avoid duplicate findings across weekly runs?

A: Use stable identifiers derived from the underlying resource identity, not from the time of discovery.

Practitioner guidance

• Implement auto-save for every discovered finding Write each result to durable storage before returning it to the model so a crash cannot erase completed work.
• Assign deterministic IDs to recurring resources Hash stable identity fields such as provider, account, and resource ID so the same object updates one record instead of creating duplicates.
• Preserve human review status across reruns Block automated overwrites when a finding is already dismissed, resolved, or acknowledged, and keep the prior status unless the condition materially changes.

Bottom line: Long-running agents fail in practice when their working memory doubles as their only system of record, because crashes and truncation erase prior results.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →