← Blog Agent Memory June 25, 2026 · 2 min read

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:

  1. Inject project context at session start.
  2. Capture useful observations during work.
  3. Distill failures and fixes after idle.
  4. Compact repeated lessons into a durable project brief.
  5. 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.

Early access Waiting list

Get the code.

The gateway source is rolling out in batches. Drop your email and we'll send the repository invite and quickstart when your slot opens.

We'll only use your email to send the invite and quickstart. We never share or sell it, and there's no newsletter — unsubscribe with one reply.