fabbrik/AgentExperience.NET

)
**Memory of what *worked*, verified by your own checks, for Microsoft Agent Framework agents.**
When your own code says a run worked (a test run, an exit code, a person's sign-off; never the model's word), the
library keeps what the agent tried as a lesson and hands it to the next run on a similar task. A preview, not
production ready. How it differs from MAF's own memory: Compared with MAF memory.
Quick start
Needs 0.1.0-preview.11 or later. Add AgentExperience.MicrosoftAgentFramework, AgentExperience.Storage.InMemory
(--prerelease) and Microsoft.Extensions.DependencyInjection; bring chatClient (any IChatClient) and
RunTestsAsync (your test run, returning text such as exit=0). Development and tests only: see In production.
What an agent sees
The quick start's second run gets this block (shortened; the whole block is from another sample):
Does it help?
On one synthetic task, for the two models tried, yes. Mean failed attempts per task in a live experiment:
| Model | No memory | Memory | Placebo | Stale |
| --- | ---: | ---: | ---: | ---: |
| Gemini gemini-3.1-flash-lite (report; pre-registered, confirmatory) | 2.17 | **0.00** | 2.42 | 2.75 |
| Claude claude-haiku-4-5 (report; exploratory replication) | 2.75 | **0.83** | 2.42 | 2.67 |
The experiment (opt-in, real models) gives the model a tool with one hidden working strategy, on 12 task instances, and
compares memory against no memory, a placebo block with the strategy withheld, and stale experience.
Read it with its limits: one run per model, one synthetic task family, 12 instances, and the working strategy reaches
the block verbatim, so it shows that a model acts on an injected lesson, not that the library helps on real tasks in
general. A harder experiment, where the lesson has to transfer to a different system through the library's own
retrieval, is in progress, no live results yet.
The samples and the reuse baseline use scripted models: they show the loop works, not that it helps.
Try it in a minute
With only the .NET 10 SDK, no key and no network:
It runs the quick start's wiring twice on the same ticket, against a tool with one hidden working
strategy. Run 1's outcome is verified by the tool's own state and stored as a lesson; run 2's model is handed it:
The stand-in is a script that tries first whatever strategy an injected block names, so this shows the loop working,
not that it helps a real model (Does it help? is about that). Set OPENAI_API_KEY to run it against
one; see the sample's README.
The whole block
The excerpt above comes from the quick start. This whole block comes from the
end-to-end sample, which hands it to its second run, verbatim (a test
keeps the two identical). There the first run failed once, then verified; the second run gets this:
Raw tool results never appear. An argument value appears only for a key kept at capture (SanitizationAllowing) and
listed in ExperienceInjectionOptions.ApproachArguments; error text appears only as an excerpt of a failed attempt's
error, with FailureDetail = Excerpt, and never in a call's [failed: ] marker ([failed] under None). The Injection guide covers the verbose layout, limits and labels.
In production
The quick start is for development and tests. Its caveats (which previews it needs, the environments
it runs in, when a run is stored, how a later run finds the lesson, the task text and task ID, argument values) are
in Starting from the quick start.
**Identity.** In production the identity comes from your own authentication, never from model output: replace
UseDevelopmentIdentity() with a resolver (returning null means no memory for that run).
**With PostgreSQL**, add the AgentExperience.Storage.Postgres package. You also supply two connection strings:
ownerConnectionString, for the role that applies the schema on every deploy, and appConnectionString, for the
application role the stores connect as (create both roles first: a few lines of SQL, in