Why Your Agent Harness Is Your Memory—and Closed‑Source Choices Threaten Data Ownership

Agent Harness is becoming the mainstream way to build agents and will not disappear.

LangChain founder Harrison Chase says Harness is tightly linked to an agent's memory; using a closed‑source Harness—especially one hidden behind a proprietary API—hands control of that memory to a third party.

Memory is crucial for creating sticky agent experiences and introduces significant lock‑in.

1. What Is an Agent Harness? Why It Won’t Disappear?

In the past three years the "best" way to build agents has evolved: simple RAG chains (LangChain) → more complex flows (LangGraph) → now large‑scale capabilities that gave rise to Agent Harness scaffolds.

Examples of Agent Harnesses include Claude Code, Deep Agents, Pi (driving OpenClaw), OpenCode, Codex, Letta Code, and others.

Some claim models will absorb more scaffolding; Harrison disagrees.

Many scaffolds needed in 2023 are now replaced by other types, but agents always need a system around the LLM to facilitate interaction.

Evidence: when Claude Code source leaked, it contained 512,000 lines of code—the Harness itself. Even the world’s top model makers invest heavily in Harnesses.

Even built‑in web search in OpenAI and Anthropic APIs is a lightweight Harness behind the API, coordinated via tool calling.

2. Harness and Memory Are Coupled

Letta’s CTO Sarah Wooders wrote that "memory is not a plugin—it is the Harness," a view Harrison endorses.

Some argue memory is an independent service, but currently it is not.

One major responsibility of a Harness is interacting with context; memory is a form of context:

Short‑term memory (dialogue messages, large tool call results) is handled by the Harness.

Long‑term memory (cross‑session memory) must be updated and read by the Harness.

Sarah lists other ways Harness binds with memory:

How AGENTS.md or CLAUDE.md files are loaded into context.

How skill metadata is presented to the Agent (system prompt? system message?).

Can an Agent modify its own system instructions?

What is retained or lost during compaction?

Is interaction stored and queryable?

How is memory metadata presented to the Agent?

Harrison notes memory is still early; long‑term memory is rarely part of an MVP. First you get the Agent running, then you consider personalization.

3. If You Don’t Own the Harness, You Don’t Own the Memory

Harness and memory are inseparable.

Harrison warns that using a closed‑source Harness, especially behind an API, means you don’t own your memory. He breaks the impact into three levels:

Minorly bad: Stateful APIs (e.g., OpenAI Responses API, Anthropic server‑side compression) store state on their servers, making it impossible to switch models while preserving the thread.

Bad: Closed‑source Harness (e.g., Claude Agent SDK built on Claude Code) interacts with memory in unknown ways; you cannot transfer artifacts to another Harness.

Worst: When the entire Harness, including long‑term memory, lives behind an API, you have no ownership or visibility of the memory and cannot even use it.

When people say "models will absorb more Harness," they really mean those memory‑related parts will move behind the provider’s API.

This is deeply concerning—it locks memory to a single platform and model.

Providers have strong incentives; Anthropic’s Claude Managed Agents puts everything behind its API. Even when Harness isn’t fully behind an API, providers move more components there—e.g., Codex is open‑source but emits encrypted compressed summaries unusable outside the OpenAI ecosystem.

4. Memory Is Important—it Creates Stickiness and Moats

Even in its early stage, memory’s importance is clear: it lets agents improve with user interaction, building a data flywheel and personalized experiences.

Without memory, anyone with the same tools can easily copy your agent.

Memory creates a proprietary dataset of user interactions and preferences, enabling differentiated, increasingly intelligent experiences.

Harrison shares a personal story: his internal email assistant built on Fleet’s template accumulated memory over months. When the agent was accidentally deleted, recreating it from the same template resulted in a much poorer experience, forcing him to re‑teach all preferences.

5. Sparked Discussion

Many agree that "harness and memory are inseparable, and closed‑source systems cause real lock‑in."

User Mohamadou adds that the deeper risk is not just who stores memory but who decides when memory is rich enough to act without invoking the model, turning memory into an active competitive advantage.

Conversely, Johannes Mauerer says he only partly agrees: when agents are consumer‑facing, lacking hosted solutions reduces the number of people who can fully leverage agents, even if memory storage should be safe, redundant, efficient.

Another commenter, [email protected], proposes a different approach: memory and documentation should live in your code repository, not in the Agent or Harness.

He recommends the free open‑source tool recursive-mode to solve "context rot"—the loss of decisions and implementations after long sessions or window overflow. recursive-mode makes static repository docs the factual source at every stage. Requirements, plans, evidence persist across sessions, contributors, and repos. Its core structure creates a .recursive folder in the repo:

.recursive/
├── /memory/              # structured memory store
├── RECURSIVE.md          # workflow spec
├── STATE.md              # current repo state
├── DECISIONS.md          # decision log
└── run/00-my-first-requirements/
    ├── 00-requirements.md
    ├── 01-as-is.md
    ├── 02-to-be.md
    └── ...

This keeps valuable information in the repository instead of disappearing in chat logs.

The discussion continues. Harrison’s article ultimately promotes LangChain’s upcoming Deep Agents, which are open‑source, model‑agnostic, use open standards (agents.md, skills), support plugins for Mongo/Postgres/Redis memory, and can be self‑deployed.

“To own your memory, you need an open‑source Harness.”