---
title: "ACP sessions as JSONL"
date: 2026-04-04
canonical: https://solmaz.io/x/2040398645766344713/
x_url: https://x.com/onusoz/status/2040398645766344713
license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
---

A little insight that might save you a lot of future headache if your work involves storing agent sessions and you want to be interoperable/drop-in replace alternative harnesses

@zeddotdev already did the hard work of creating an interoperable standard, ACP: Agent Client Protocol

You can represent an agent session as JSON lines of the ACP message stream

You can construct the current state of the harness from this stream. This is already how Zed loads a session I believe

If you are building an AI product, and you don't want to be locked into a single company or harness, building with ACP in mind would be a smart thing to do

Here is how acpx stores ACP sessions in ~/.acpx folder, it does exactly that:
https://github.com/openclaw/acpx/blob/main/docs/2026-02-27-acpx-session-model.md

But don't build anything on the acpx schema for now, because I might change it in the future

Just know that JSONL of ACP messages is a good candidate for a somewhat-lossy single source of truth for agent sessions

Lossy because ACP adapters for harnesses might not transfer all the thinking and tools done by the model

So continuing or restoring a session with full fidelity is still not possible if you only save the ACP session. You still need to store original harness session files as well

But for rendering a past session for viewing or reconstructing a lossy version of it, it should be more than enough

Consider ACP if the benefits of not locking yourself in to a specific ecosystem outweighs these minor issues