by Dmitry CreedThe busiest thread in the agent feed this fortnight is memory. Not a new model — memory.
In the last two weeks the “give your agent a memory” launches stacked up: LoreKit (Show HN, Aug 15) pitches durable memory as “a folder you own — no signup, no platform.” A widely-shared write-up on the shapes of agent memory surveyed file, vector, graph and RL-based approaches. Multi-agent runtimes like Taurus Agents (Aug 13) now headline “persistent identity + episodic memory + per-agent continuity logs.” The consensus has flipped fast: a stateless agent is a broken agent. Give it memory.
Here’s the part the launch posts skip. Durable memory is durable liability. The moment your agent remembers, it’s holding user data that outlives the conversation — and the interesting engineering isn’t that it remembers. It’s the boundary around what it remembers, where that sits, and when it goes away.
This fortnight Forge’s control plane gained memory. So here’s the honest write-up — not “look, it remembers,” but where the memory lives and what fences it in.
The bot that couldn’t hold a thought
Forge Control talks to you over Telegram. Until now it was stateless: every message a blank slate. Ask “What’s the weather in Belgrade?” and it answered — but the natural follow-up, “А в понедельник?” (“And on Monday?”), fell on the floor. No prior turn, no context, no thread. Operators told us plainly that a bot with no memory of the last message “isn’t really working.”
So forge-notifier PR #31
(merged Aug 12) gave it a rolling conversation memory. The bot now carries a per-chat window of recent turns into its intent classifier and its conversational fallback, so a bare follow-up resolves against what you just asked. That’s the visible win: multi-turn conversations that actually track.
But that’s the same win every memory launch this fortnight is claiming. The reason it’s a Forge story — and the reason it matches what our readers actually dwell on — is the second half of the sentence.
Memory with a shelf life, not a hoard
Most “agent memory” ships as accretion: keep everything, forever, and hope the retrieval layer sorts it out later. That’s how a helpful feature quietly becomes a data-retention problem you didn’t decide to sign up for.
Forge’s conversation memory is bounded by construction on two axes:
- It expires. On purpose. The store carries a 14-day TTL — a hard lifecycle, enforced by the datastore, not a cleanup job you hope runs. Memory is a rolling window, not an ever-growing archive. That’s the same discipline the context-budget crowd is chasing from the token angle — keep state small and fresh — except here it’s a property of the store, so old conversation state ages out whether anyone remembers to prune it or not.
- It’s encrypted at rest, per-org, and it fails closed. Conversation bodies are encrypted with a per-organization data-encryption key. No key, no read: without the KEK the path fails closed rather than falling back to plaintext. Your remembered conversations aren’t a plaintext table one misconfiguration away from being everyone’s.
That’s the distinction that matters. “The agent remembers” is table stakes now. “The agent’s memory expires on a fixed clock and is encrypted with a key scoped to your org, and refuses to run without it” is the boundary — and the boundary is the product.
Why the boundary is the story (and the data says so)
We know which posts this audience actually reads to the end. The single stickiest article on this site is the one on keys your agent never sees — readers spend four times longer on it than on the homepage, because it’s about a guarantee that holds by construction rather than by asking the agent to behave. Memory-with-a-TTL-and-a-DEK is cut from exactly that cloth.
It’s also the through-line of everything Forge ships. The browser agent that 401s the instant its token leaves its scope . The follow-up work an agent has to ask permission to spawn . The Telegram bot that fetches live answers through a tool that literally cannot run away. And now: memory that cannot quietly become a permanent, plaintext record of everything anyone ever typed at your bot.
One honest note, because we’d rather under-claim: this is conversation memory for the control-plane bot — a bounded, encrypted, expiring window that makes multi-turn chats work. It is not a long-term knowledge base or a cross-session vector memory, and we didn’t ship it as one. We shipped the smallest useful memory with the boundaries already in place, then stopped.
The takeaway
The whole ecosystem just agreed that agents need memory. The unglamorous follow-up question — the one that separates a demo from something you’d point at your own users’ data — is what fences that memory in. An agent that remembers everything, forever, in the clear is not a feature; it’s an incident waiting for a date. An agent whose memory expires on a fixed clock and is encrypted with a key scoped to your org is memory you can actually live with.
Give your agent a memory, by all means. Just decide where it lives and when it ends — before it decides for you.
Try it
Open your Forge Control Telegram chat and ask a follow-up question that leans on the last one — it’ll track now, in English or Russian. See the Workflow Engine for what runs the loop underneath, or reach out at [email protected] if you want agents that remember what they should — and forget what they shouldn’t.