AI Agent Memory Is Splitting Into Two Schools: Embedded State vs. Owned Files

Two competing philosophies for agent memory are hardening into real product choices. One embeds state inside the LLM session or a central store the orchestrator controls. The other hands the agent a small JSON file it owns outright. The gap between them is not academic: it determines whether you can debug a runaway agent at 2 a.m., audit what a customer-service bot told a user, or replay a workflow that silently failed.

The pattern

The AIPass project makes the ownership model explicit: each agent carries its memory as a small JSON file it reads and writes directly. Nothing is stored in a shared vector DB, a session object the orchestrator manages, or a hidden system-prompt injection. The agent is the custodian of its own state.

Contrast that with the implicit model most teams ship today: memory lives in a conversation buffer, a centralized retrieval layer, or a session managed by the framework. The agent reads from it but does not own it.

Meanwhile, Veryfront Code is betting on a full-stack TypeScript and React surface for building AI apps and agents, which implicitly favors the orchestrator-controlled model: state is a concern of the app layer, not the agent itself.

Why now

Three pressures are converging. First, agents are running longer tasks with more steps, so memory bugs compound. Second, teams are deploying agents into regulated or customer-facing contexts, like AI customer service teams, where auditability is not optional. Third, LLM tooling is starting to bake traceability in at the infrastructure level: Claude is now appending session URLs to commit messages and PR descriptions by default, which means the provenance of an AI-assisted action is becoming a first-class artifact in the development workflow. If the tool layer is moving toward full traceability, the memory layer has to keep up.

Explore more on this topic at Agents.

How it works in practice

1. File-owned memory (AIPass model): The agent reads a JSON file at task start, mutates it during execution, and writes it back. Human operators can open the file, read it, edit it, and hand it back to the agent. Replay is trivial: restore the file to a prior snapshot.

2. Orchestrator-owned memory (Veryfront / typical app-layer model): The framework manages a state object or retrieval index. The agent queries it via API. Centralized control makes cross-agent coordination easier but creates a single point of opacity.

3. Session-embedded memory (default LLM behavior): State lives in the context window or a managed conversation object. Fast and simple for short tasks. Breaks down at scale, across sessions, or when you need to inspect what the agent actually knew at step 7.

4. Hybrid with explicit handoff: Some teams are combining both: a lightweight owned file for the agent's working memory, and a shared store for long-term retrieval. The owned file is the "desk," the shared store is the "filing cabinet."

For developer tools teams, the Claude session URL behavior is a useful forcing function: if every AI-assisted commit now carries a provenance link, your agent's memory architecture needs to produce artifacts that are legible at that same level of granularity.

The trade-off

File-owned memory is not free. JSON files are not transactional: concurrent agents writing to the same file will corrupt state without careful locking. They do not scale to high-frequency writes. And they push schema management onto the agent itself, which means a poorly prompted agent can silently corrupt its own memory in ways a centralized store with a fixed schema would reject.

The orchestrator model is more robust under load and easier to version-control at the infrastructure level. But it concentrates opacity: when something goes wrong, you are debugging a system the agent could not itself explain.

The honest summary: file-owned memory is better for auditability and human-in-the-loop workflows. Orchestrator-owned memory is better for throughput and multi-agent coordination. Most production systems will need both, with a clear contract about which layer owns what.

Where it goes next

The session-URL-in-commit-message behavior from Claude is a small signal of a larger shift: the industry is moving toward agents that leave a legible paper trail by default, not as an afterthought. Memory architecture is the next frontier of that shift. Expect framework-level standards for memory schemas, snapshot formats, and agent-readable audit logs to emerge over the next two quarters, driven by the same compliance pressure that is already reshaping customer-service agent deployments.

The teams that define their memory contract now, before scale forces the decision, will have a significantly easier time when regulators or enterprise customers ask "what did your agent know, and when did it know it?"

Pick your memory model before your agent picks it for you.