Conversation Memory

### What memory actually is in the object model PyRIT does not thread a log object down the call chain. It keeps **one process-wide memory instance**, held by `CentralMemory` and chosen once at start-up — in current releases through `pyrit.common.initialize_pyrit(memory_db_type=...)`, which takes a store kind such as the in-memory one or the durable file-backed one. Every other execution object — a prompt target, an attack strategy, a converter chain, a scorer — resolves that same instance through `CentralMemory.get_memory_instance()`. Memory is therefore *ambient* rather than wired: flipping the store kind on that single line changes the behaviour of every object in the run without any of them being reconfigured. That is precisely why the wrong choice is easy to make in a copied notebook and hard to notice until the run is over. ### What a stored record contains The unit is not a conversation but a **request piece**: one prompt, or one response. A piece carries the `conversation_id` it belongs to, its role (`user` or `assistant`), a sequence number ordering it within that conversation, the original value, the **converted value** — the string as actually sent after the converter chain ran, which is usually not the seed you typed — an identifier for the target it went to, an identifier for the attack that produced it, and timestamps. Scores are stored as their own records that reference a piece, which is why a verdict is inseparable from the exchange it judged. "The transcript" is a reconstruction: `memory.get_conversation(conversation_id=...)` pulls the pieces and orders them by sequence, and that reconstruction is exactly what a multi-turn strategy feeds back in to compose its next prompt. ### The durable store versus the in-memory one Both implement the same interface, so nothing downstream can tell them apart — which is the point, and the trap. The durable store writes into an embedded database file on the host (the engine and the default path have changed across PyRIT releases; check what your installed version writes rather than trusting a tutorial). The in-memory store keeps the same tables for the life of the process, and then they are gone: no file, no export, no re-read, no resume. ### What it costs Storage is trivial. A piece is a few kilobytes of text; a forty-objective run at ten turns each is roughly 800 pieces and single-digit megabytes, and the write is far below the latency of the model call that produced it. The cost that matters is the **cost of not having it**. A multi-turn red-team run bills three metered calls per turn — the attacker model that composes the next prompt, the target, and a model-backed scorer — so that same forty-by-ten run is on the order of 1,200 calls, plus its wall-clock, plus a second window of live attack traffic against someone's production endpoint if you have to repeat it. Losing the store converts all of that into a re-run, and re-runs against a customer system usually need fresh authorisation, not just fresh budget. ### Where the number misleads Two readings go wrong routinely. - **Row counts are not attempt counts.** A multi-turn run stores many pieces per objective, so "the store holds 812 rows" is not "we ran 812 attacks" — it is roughly forty objectives times ten turns times two roles. Any success rate whose denominator came from a raw piece count is wrong by the turn multiplier. Count distinct `conversation_id` values, or objectives, and say in the report which one you counted. - **A reused `conversation_id` silently merges runs.** Because history is reconstructed from whatever is stored under that identifier, two runs sharing one will each see the other's turns: the strategy builds on a conversation it never actually had, and the exported transcript reads as a single long coherent attack that never happened as one exchange. The in-memory store produces the mirror-image failure — every process starts blank, so a strategy expecting prior turns quietly behaves as though it were on turn one. ### What to check before a run you care about Print the configured store kind from the entrypoint itself rather than trusting the snippet you copied. Then do a two-turn throwaway against a harmless objective and read it back: confirm the pieces are there, that the converted value is populated and not just the seed, that the score records attached to those pieces, that the file landed on the path you intended and the process can write there, and that whatever export you plan to hand to the report actually runs end to end. Doing that check after the engagement, when the only possible answer is bad news, is the mistake this question is really about.