Your team is scaling from one operator running PyRIT locally to several running in parallel on the same engagement. How do you decide between per-operator local stores and one shared conversation store, and what does the shared choice oblige you to build?

### The mechanism is a one-line swap, which is what makes the decision easy to under-think Both the local file-backed store and a network-backed shared one implement PyRIT's memory interface, and both are selected the same way at start-up — the store kind handed to `initialize_pyrit`, resolved thereafter by every object through `CentralMemory`. No strategy, target, converter or scorer changes. Because the swap is invisible to the code, teams tend to evaluate it as a configuration choice when it is actually a decision about the engagement's reporting unit and about who may read a corpus of working attacks. ### Decide from the deliverable If each operator delivers findings separately, local stores are correct and aggregation happens in a document. If the deliverable is one engagement-level picture — coverage across operators, deduplicated findings, a defensible attempts-and-hits count with one denominator — then somebody has to join the transcripts anyway, and joining five laptops at the end is worse in every way than sharing from the first run. Multi-operator work fails at the report, not at the run: two operators unknowingly hammering the same objective while a third surface goes untested is a coverage failure that becomes visible only when the records are joined. ### What sharing costs, concretely - **Latency and failure mode.** A multi-turn strategy reconstructs conversation history from the store *on every turn*. A local file read is microseconds; a network round trip is tens of milliseconds, several times a turn. Over a campaign of thousands of turns that is minutes to tens of minutes of added wall-clock, and worse, a network blip now fails runs that a local file would have survived — and it fails every operator at once, which a set of independent laptops does not. - **Money and engineer time.** The hosted database itself is small change next to model spend. The real spend is human: initial setup, an access review, a destruction date someone owns, and a repeat of that per engagement — days, not hours, and recurring. - **Concentration.** One store holding every operator's successful attacks against a named customer is a high-value artefact. Over-broad access or compromise becomes a single event with engagement-wide blast radius, where before it was one laptop. - **Access and retention.** A local file is governed by whoever holds the machine. A shared store needs a real answer to who may read transcripts — the whole team, the leads, the client's engineers? — usually differing by role, plus removal when someone rotates off, plus scheduled deletion, because accumulation across engagements is exactly what makes the store attractive and what a client contract is least likely to permit. ### Where the number misleads The seductive metric after consolidation is a big total: "the shared store shows 4,000 exchanges across the team." That is a row count, and row counts are not coverage. Coverage's denominator is objectives or surfaces in scope, not stored pieces, and without labels distinguishing operator, target and deployment, a pooled store cannot even produce attempts-per-objective — it produces one large undifferentiated number that reads as thoroughness. The second misleading claim is qualitative: presenting the move as a security improvement. It is not. It relocates exposure from many small uncontrolled copies to one large controlled one, and it is an improvement only once the controls exist. ### A workable middle, and what to insist on Prefer a **per-engagement** shared store over one perpetual team store: created at kickoff, access scoped to that engagement's team, destroyed or archived at close under the client agreement. That keeps the join benefits inside the engagement while capping accumulation and making the retention decision a natural event rather than a chore someone remembers. Before switching, insist on: a labelling scheme applied from the very first run, since labels cannot be added retroactively; named access with removal on rotation; encryption in transit and at rest; a scheduled destruction date with an owner; and a rehearsal that the export you will need for the report actually runs — discovering at the end of a large engagement that it does not is expensive. And measure the per-turn latency delta on a throwaway multi-turn run before committing a campaign to it, because that number is cheap to obtain in advance and painful to discover halfway through.