Agent memory should come from real sessions
The best memory is operational evidence: what the agent tried, what failed, what fixed it, and where the next agent should look first.
Static notes go stale quickly
Agent memory is useful only when it reflects how work actually happens. A hand-written runbook can help, but it drifts unless the team continuously updates it. That drift is costly because agents trust the memory they are given at session start.
The gateway already sees the shape of agent work. It can capture session IDs, request payloads, usage records, observations, and project context lookups. That makes it a natural place to build memory from evidence instead of ceremony.
Capture is not the same as memory
Raw payloads are too large and too noisy to inject into every future session. They are useful for audit and debugging, but memory needs compression. The valuable material is usually smaller:
- The command that failed.
- The error text that mattered.
- The file or function that owned the behavior.
- The workaround that became the durable fix.
- The user preference that changed the default next time.
Distillation turns captured work into those reusable facts.
Timing matters
Memory should not interrupt the request path. Capturing and distilling should be asynchronous, bounded, and allowed to drop work under pressure. The proxy should keep serving traffic even if the memory queue is full.
The right pattern is to record lightweight observations during the session, then distill after the session goes idle. That gives the system enough context to identify the lesson without blocking the agent while it is working.
Project context needs selection
Injecting every note into every session is just another kind of noise. Project memory needs retrieval: identify the current project, search for relevant lessons, include the latest runbook pointers, and keep the bundle small enough for the model to use.
Good memory does not try to be complete. It tries to be the first set of facts the next agent would otherwise rediscover the hard way.
The feedback loop is the product
The proxy is already the boundary between agents and providers. Adding memory at that boundary creates a practical loop:
- Inject project context at session start.
- Capture useful observations during work.
- Distill failures and fixes after idle.
- Compact repeated lessons into a durable project brief.
- Use that brief in the next session.
That loop is where agent infrastructure starts to feel less like isolated chats and more like an operating system for engineering work.