Memory for Agents That Keep Working

Three kinds of continuity

Chat history records the conversation. Compaction makes that history manageable. Durable memory preserves selected knowledge for future work. These layers complement each other, and keeping their responsibilities clear helps control both cost and quality.

A lengthy investigation may contain dozens of tool responses, abandoned approaches, and temporary observations. Its lasting value might be a verified configuration requirement and a repeatable recovery procedure. Those are useful memories. Replaying the entire investigation every time the agent encounters a related issue would consume context without adding the same value.

FabrCore supports facts, rules, instructions, observations, and procedures. Applications can retain source metadata and captured-state markers, then update a known memory when the underlying fact changes. A remembered instruction remains reference data under the agent's current policy; it does not become permission to act.

Use memory from code, tools, or both

Some moments are best handled directly by the application. When a user explicitly confirms a preference or a workflow completes with a verified result, code can save that information immediately. Other moments benefit from model judgment: an agent may recognize that a useful procedure should be retained, or that an earlier decision could help answer a new question.

FabrCore supports both through the same scoped memory service. Developers can call it from agent lifecycle methods, and the agent-memory plugin exposes tools for saving, recalling, updating, archiving, and forgetting memories. The host binds the scope; the model does not choose a different customer's memory store through a tool argument.

using FabrCore.Services.Memory.Abstractions;
using FabrCore.Services.Memory.Models;

// provider is an injected IAgentMemoryProvider.
// Resolve this stable scope from trusted application identity.
var memory = provider.GetMemoryService(trustedScope);

var saved = await memory.SaveMemoryAsync(
    title: "Weekly project update format",
    type: MemoryType.Instruction,
    content: "Use a short summary followed by blockers and next steps.");

// Retain saved.Id for an explicit correction later.

Sharing a scope deliberately shares access. Applications still own authorization and identity, and explicit updates are preferable when correcting a known fact: similarity alone does not establish that two statements describe the same thing.

Memory belongs in the harness lifecycle

FabrCore builds on Microsoft Agent Framework, so memory can participate in the context-provider pipeline used by a harness agent. The WithMemoryLifecycle integration combines bounded recall with memory-aware persisted-history compaction. Memory tools are a separate, explicit option.

Before a model response, the provider retrieves relevant memory and supplies a bounded reference context. Before history is replaced by a compacted summary, the memory path extracts durable knowledge. If extraction fails, the failure propagates and the original history is preserved for recovery instead of treating the failed extraction as a successful empty result.

The default injected-memory cap is 12,000 characters. That is a bound on this context contribution, not a claim about the entire prompt or a fixed percentage of token savings. Developers can use recall alone, attach the complete lifecycle, or keep explicit lifecycle calls where the application needs tighter control.

This extends the separation described in Context and History Are Not the Same Thing: reduce the working context while preserving the knowledge future work actually needs.

Private specialists need deliberate memory ownership

A core agent may delegate research or checking to private specialists. Those agents can benefit from shared knowledge without every draft observation becoming a shared conclusion. FabrCore offers three explicit choices:

• OwnOnly: read and write the specialist's own memory. This is the default.
• CoreOnly: read and write the core agent's shared memory.
• CoreAndOwn: read its own memory first, then core memory; write only to its own scope.

A research specialist can therefore consult established project decisions and retain private findings for its next run. Shared writes require an intentional binding. Background memory writes also require an explicit execution policy and scoped tools, with bounded run time. Giving a specialist memory does not automatically authorize unrelated external actions.

Keep retrieval selective and defaults predictable

The library retains its SQL storage and three memory temperatures. Hot memory is a small table of contents, Warm memory is active durable content, and Cold memory is archived content that remains searchable. Archive search covers retained embedded memories, including archived ones, without automatically promoting them.

We have frozen the existing default retrieval policy for release preparation. Ordinary recall scans up to 200 headers and selects up to five memories before related-memory expansion. It reads primary chunks; it is not an exhaustive search of every historical passage. The hot index is bounded to 20 pointers and roughly 3,000 tokens.

Semantic candidates and matched-chunk retrieval remain available as opt-in configurations. Automatic consolidation also remains off. Applications can evaluate these choices against their own histories, but experimental changes do not silently become the default.

As with our GraphRAG evaluation work, the useful question is whether a change preserves the answer's supporting evidence while improving cost or performance. Memory evaluations exercise recall, corrections, source coverage, and lifecycle behavior. Retained baselines let future changes be compared rather than judged by a plausible-looking response. Smaller context is valuable when it still contains what the agent needs.

Enterprise knowledge and agent experience work together

GraphRAG helps an agent work with documents and their relationships. Memory helps it carry forward what has been learned or agreed during its own work. A support agent might use GraphRAG to find the current product procedure, then memory to recall a customer's confirmed environment and the steps already completed.

The same pattern applies to onboarding, operational investigations, and project coordination: consult authoritative knowledge, recall relevant experience, and verify facts that may have changed. Memory can reduce repeated explanation and unnecessary rediscovery without making yesterday's observation permanently authoritative.

Agents that work for minutes, hours, or days also need scheduling, checkpoints, recovery, permissions, and execution budgets. Durable memory supplies continuity within that larger system. The next step is release validation against representative workloads, with the default policy held steady and future improvements measured against retained benchmarks.