Mastra Code's harness design
Right after a long coding session compacts, the summary drops a requirement you gave forty turns earlier, and the agent starts contradicting a decision it already made. Sam Bhagwat's Anatomy of a harness reads that failure as a property of compaction itself and proposes an observational memory layer to replace it.
Compaction only summarizes the conversation, so the one thing it can lose is whatever the conversation alone records. A requirement you have already turned into code, or a decision you have written down, also exists outside the conversation, which means summarizing the conversation leaves it untouched.
A summary that drops something you needed is telling you the thing was still only a message when you compacted. The fix is to wait until the work is in a file before compacting, rather than to hunt for a better summarizer.
When a summary loses your requirements
A lossy summary drops whatever exists only as text in the transcript: an edge case you flagged, the exact wording of a constraint, a decision you were still half-applying when the context filled. Each of those survives the moment it becomes something other than a message - a line of code, a comment, an entry in a decisions file - because the summary rewrites the conversation and never touches those artifacts.
On a focused session the requirements turn into code or written-down decisions in order, one phase at a time, and a phase finishes before the context fills. Compacting at that boundary loses nothing that matters, because everything that matters has already moved into the files by then. Reaching the 40k or 80% mark only after a phase has closed means it never catches you partway through one.
The damage Sam's Claude Code users report comes from the opposite case, where a session that was never scoped piles up requirements that never become code, so the context fills while half the work lives only in the transcript. Compacting then drops a requirement, because no summarizer can save a decision that was never made into code, observational memory included. The real error is driving past 40% with nothing decided, which compaction only exposes.
Most of the eight features already ship in Claude Code
Sam frames the eight capabilities as the line between a "harness" and a naive agent loop. Against an agent that only appends to a growing array the line is real, but against Claude Code most of the eight items already sit on the harness side.
- Thread persistence and resume. Claude Code resumes a session with
--continueor--resumeand re-feeds the project throughCLAUDE.md. Mastra persists more on the thread - the mode, the per-mode model, the token count, the memory thresholds - but the resume capability is not new. - Live task lists. Claude Code writes and updates a to-do list as it works.
- Interrupt, queue, steer. Claude Code takes a new instruction mid-turn, and you can stack the next message while it runs.
- Tools that pause for a human. Claude Code's permission prompts and plan mode both block the agent until you answer.
- Plan-to-build handoff. Approving a plan in Claude Code drops it out of read-only planning into execution.
- The approval chain. Claude Code resolves each call to allow, deny, or ask, with per-tool rules and a built-up allowlist.
- Subagents. Claude Code spawns isolated subagents through its Task tool.
- Crash recovery and multiple surfaces. Claude Code persists sessions to disk and runs in the terminal, the desktop app, the web, and the IDE.
So the list separates a production coding agent from a teaching example, and Claude Code sits on the production side of all eight. What is genuinely distinct to Mastra is narrower, and worth judging on its own terms rather than as the line between an agent and a harness.
The shorter list comprises a conversation modeled as a pub/sub channel several clients can subscribe to at once, a subagent that forks the parent thread to keep the provider's prompt cache warm, each mode keeping its own model, and observational memory.
What is actually new
The forked subagent is the first of two Mastra choices that reward a closer look. A review subagent normally starts cold to stay unbiased, but when you do want the parent's context, Mastra clones the thread and runs it on the same agent so the provider's prompt cache still matches. It keeps every tool's schema identical and stubs only the blocked tools at runtime, which is what makes it cheaper and faster than starting the subagent cold.
Observational memory is the second, and how much it buys depends on how the agent is run. When the agent runs interactively, with the operator watching, the scoping discipline above already prevents the failure OM targets, because the operator narrows the session and compacts at boundaries by hand.
In the unattended case Sam opens with, you hand the agent a goal and go to sleep, so no operator is there to scope anything, and the agent has to distill its own decisions continuously or it compacts mid-phase by definition. That unattended run is what OM is built for, which leaves the interactive complaints it is pitched against as the one case where the operator could have scoped and didn't.