What does an infrastructure agent actually need to remember?

IN PROGRESS

It’s easy to default to “remember everything” when designing an agent that operates over time — more context seems like it can only help. In practice, unbounded memory creates its own problems: stale state that no longer reflects reality, context that was true for a previous task bleeding into a new one, and a growing surface area for something to go wrong that has nothing to do with the task currently at hand.

The question we’re working through is what the minimum useful memory actually looks like for an agent operating on infrastructure specifically — not memory in the general sense, but the subset that’s actually load-bearing for making good decisions about systems that change state over time. Candidates under consideration include the outcome of recent actions (so the agent doesn’t repeat something that already failed), the current state of resources it’s responsible for (so it isn’t reasoning from stale assumptions), and the boundaries it’s operating under (so permission context doesn’t have to be re-derived every time).

What’s genuinely unresolved: how much of that should persist across sessions versus being scoped tightly to a single task. Persisting too much risks exactly the staleness problem that prompted the question in the first place. We don’t have a settled answer yet.