Every few months the agent ecosystem rediscovers that it has no way to move an agent. You can copy a prompt. You can fork a repo of tools. But the thing you actually built — an agent with a personality it edited into itself over a hundred turns, a memory of who it's talking to, a set of tools wired to sequence in a particular order — lives inside one framework's database and dies there. Rebuild it elsewhere and you're not migrating; you're re-parenting.
Agent File, the .af format from Letta (the team behind MemGPT, whose memory model we've compared against Mem0 and Zep), is the most serious attempt yet to fix that. It's an Apache-2.0, human-readable JSON format — about 1.2k stars, small but pointed — that serializes a stateful agent into a single file you can share, checkpoint, and commit. And it captures far more than a config: the model settings, the complete message history (each message flagged for whether it's still in the context window), the system prompt, the memory blocks (the editable in-context segments where a Letta agent keeps its persona and what it knows about you), the tool rules that constrain how tools fire, the environment-variable slots, and every tool's actual source code plus JSON schema.
That last item is the tell. Most "export my agent" features give you a manifest — names and pointers. Agent File gives you the tool implementations inline. The agent isn't described by the file; it's contained by it.
The word doing too much work is "portable"#
The repo's own framing is portability across "compatible frameworks," and that's where you should slow down. A .af file is just JSON, so of course LangGraph or CrewAI can parse one. The question is whether the concepts survive the trip. They mostly don't. Memory blocks — the editable, in-context, sometimes-shared segments — are a MemGPT idea. LangGraph doesn't have them. The OpenAI Agents SDK doesn't have them. Tool rules are Letta's sequencing model, not a universal primitive. So any other runtime loading a .af file has to translate these into its own representation, and translation is exactly where fidelity leaks. Today, the only system that round-trips .af without loss is Letta itself.
A .af file is portable the way a chess PGN is portable: any program can read the moves, but only a chess engine understands the position.
So the honest read is that Agent File is, right now, a superb checkpoint and version-control format for Letta agents, and an aspiring interchange format for everyone else. Both are worth having. But they're different products, and conflating them will burn you if you adopt .af expecting to lift an agent into a framework that has never heard of a memory block.
The non-obvious part: what you load is a template, not a clone#
Here's the detail that reframes the whole format. On export, secrets are set to null. The structure of your environment variables travels; the values are stripped. This is obviously correct security hygiene — you do not want your Postgres password riding along in a file you post to a Slack channel. But follow the consequence: a .af file you import is not a running duplicate of the source agent. It's a cast of one. The tool code is there, but its live bindings — API keys, database URLs, whatever the tools reach for at runtime — are hollow slots you must re-provision before the agent can do anything.
Combine that with the other gap — Passages, the units of archival (long-term) memory, aren't serialized yet (they're on the roadmap) — and the picture sharpens. What .af captures beautifully is the agent's identity and behavior: how it thinks, what it remembers about the conversation, what tools it wields and in what order. What it deliberately leaves behind is the agent's live entanglement with the world: its secrets and its full external memory. That's not a flaw. It's the correct cut. A file you can safely email should not contain your credentials or a database's worth of history.
Which means the right mental model isn't "Docker image for agents." It's a savefile. The examples the repo ships — a memory-focused chat agent called Loop, a customer-service agent, a deep-research agent, a MemGPT agent, a workflow agent — are exactly that: starting positions you load, re-provision, and continue from. You're not teleporting a live process. You're saving your game and handing someone else the save.
Why a savefile is still the win#
Undersell it and you miss why 1.2k people starred a serialization spec. The moment an agent is one JSON file, it becomes a git-diffable artifact. You can review a change to an agent's persona in a pull request. You can roll back the version of your support bot that started apologizing too much. You can hand a colleague the exact agent that reproduced a bug instead of a paragraph describing it. None of that requires cross-framework portability to be real; it only requires the state to live in a file instead of a database you can't see into.
That's the quiet thing Agent File actually ships today, and it's more useful than the loud thing on the label. Judge it as "the open standard that frees agents from every framework" and it's early and partial. Judge it as "agents finally have a savefile you can version, review, and share without leaking your keys" — and it's here, it works, and it's the piece the ecosystem has been missing since the first time someone rebuilt an agent by hand because there was no other way to move it.
