Second page in Operation Scarecrow. If you haven't read The Company Brain Is Four Different Problems yet, start there — this page assumes you already have the four-way split and picks up one tier at a time, starting with the cheapest one. Source citations at the foot of this piece.
Start with the cheapest tier, because it's the one most Company Brain pitches get right by accident and the one most governance proposals get wrong on purpose.
Working memory is whatever's true right now, for the task directly in front of an agent or a person, and nothing more. A sprint board's in-flight tickets. The current state of an active incident. Today's on-call schedule. A feature flag's rollout percentage this minute. The open PR review queue. None of it is meant to survive the workflow that produced it, and that's not a gap to fix — it's the design.
What it isn't for
The instinct, once an organization decides its AI agents need "memory," is to treat all of it the same way: capture it, index it, review it before it's trusted. Applied to working memory, that instinct is exactly backwards. A decision queue reviewed like a settled fact is ceremony spent on something that will be irrelevant in an hour. The tier that should be nearly free to write and just as free to discard is the tier most likely to get dragged into a governance process built for something else entirely — usually because nobody drew the line between "this needs a steward" and "this needs a TTL."
Meridian — the illustrative mid-market SaaS company this section's worked example uses throughout — makes the shape of this concrete. Its sprint board and open tickets live in Jira. The active-incident channel and current on-call state live in Slack and PagerDuty. Feature-flag rollout percentages live in LaunchDarkly. All of it is scattered across different tools, and that's fine — this tier was never supposed to be centralized. The actual problem isn't fragmentation. It's that almost none of it is queryable by anything other than a human scrolling. An agent joining an in-flight incident has to reconstruct what's happening from chat history instead of reading a structured state, the same way a new hire would have to if nobody briefed them.
What's already built, with nothing left to invent
This is the one tier where the research behind this section found existing tooling that already does the job correctly, with no gap to close. LangGraph's checkpointers persist a workflow's state as a snapshot after every execution step, keyed by a thread ID — an agent picking a task back up reads that snapshot instead of asking someone to re-explain where things stand. Temporal takes a heavier-weight approach built for the same short-lived intent: it persists a full event history and replays it to reconstruct state after a crash, with configurable retention — commonly around ninety days — after which it's gone unless explicitly exported. Access is scoped to the owning thread or workflow by default, not broadly readable, which is structural rather than an oversight: nothing about this tier benefits from being everyone's business.
Governance, deliberately, is none. No review gate, no approval chain, no steward. That's not a gap in the tooling — it's the tooling correctly reflecting what this tier actually needs, and it's the clearest confirmation available that treating working memory with backplane-level review would be exactly the wrong amount of ceremony for something built to be thrown away.
The actual fix, and where the leverage is
None of this means working memory needs nothing done to it — it means what it needs is infrastructure, not process. The fix is a queryable, task-scoped state store instead of chat scrollback: a checkpoint keyed by ticket or incident ID, so an agent picking up a live incident mid-stream reads current state directly rather than requiring a human to re-brief it first. On close, that state should collapse into a short summary and hand off to episodic memory rather than simply evaporating — the moment a live, mutable status becomes a closed, dated record is exactly the boundary the next tier up is built to hold.
The business case for building this out is narrower than for the other three tiers, and worth naming precisely: the leverage here is speed, specifically the re-briefing tax paid every time an agent or a person joins something already in motion. That's a real cost — anyone who has walked into a live incident twenty minutes late knows it — but it's not a risk-reduction case or a compliance case the way the semantic tier's argument is. It's an efficiency case, and efficiency cases get funded differently than risk cases, which is itself a reason this tier tends to be the one an organization builds last rather than first, even though it's the cheapest to get right.
What "working" costs at real scale
Cheap per unit doesn't mean cheap in aggregate. A single checkpoint is small by design, but checkpointing every step of every in-flight workflow across a real agent fleet — thousands of concurrent threads, not a demo — turns a trivial per-unit cost into real storage and IO volume. There's a second cost hiding behind that one: if an agent has to reload a large state blob on every invocation, that's context-window tokens being spent, not just disk space, which shows up as latency and inference spend rather than as a line item anyone thinks to check. Neither of these costs argues for governance. Both argue for treating this tier as an infrastructure and capacity-planning problem, which is a different budget line and a different owner than the steward this section's semantic-memory page argues for.
The metric that actually matters here isn't a memory-quality score — this tier is ephemeral by design, so there's nothing to score for accuracy the way a settled fact needs one. What it needs is an operational metric: checkpoint recovery success rate, the same reliability number any durable-execution system already tracks, simply relabeled as this tier's health signal rather than invented from scratch.
The one piece still missing
Here's the one piece that isn't nailed down yet. Every individual piece described above is real and already running somewhere — LangGraph and Temporal are production systems, not proposals. What hasn't been verified anywhere in the research behind this section is the specific handoff this page argues for: a live checkpoint collapsing into a short summary and passing itself to episodic memory on close, as a deliberate, designed step rather than something engineered ad hoc per team. That seam — not the checkpointing itself, but the moment this tier hands off to the next one — is the part still owed a real example, not just an architectural argument.
Sources. LangGraph persistence and checkpointers: LangChain documentation, docs.langchain.com/oss/python/langgraph/persistence. Temporal durable execution and event history retention: docs.temporal.io/workflow-execution/event. Meridian is an illustrative, composite company invented for this section — not a real business — standing in for the shape most mid-market software organizations are already in.