What is agent observability — and why your logs don’t have it yet

2026-10-17 — “observability” gets borrowed a lot this year. Most of what ships under the name still answers last decade’s question: how many tokens, how much latency, what did the model return. That is LLM observability. It tells you about a conversation. It says nothing about what the agent then did to your files, your processes, your credentials, or the network on your behalf. Agent observability is the other question: which action, by which agent, against which resource, judged how, at what time — and can I prove it tomorrow?

The three questions a real record has to answer

• Attribution: agents run as process trees. A record that names only “the model” cannot tell you which family, which session, or which spawned child touched the resource. Lineage has to be in the line.
• Action shape, not payload: what matters is that a command was aimed at a sensitive resource — the shape of it — not the private bytes flowing through it. Collecting payloads is how “observability” becomes its own breach.
• The verdict at the moment of the action: a log that only lists events has no opinion. Attaching the policy evaluation that was in force when the action happened is what turns a transcript into evidence.

Why ordinary logs fail here

Terminal scrollback disappears when the window closes. Shell history does not attribute — a command run by an agent looks identical to one you typed. Agent-side transcripts describe intentions, not effects: what was attempted, not what the operating system actually allowed. And provider dashboards live on a different plane entirely: they bill requests, they never saw the filesystem. The gap is not that nobody logged anything. It is that nothing logged is admissible for the question you will actually ask after an incident.

What we record, and what we refuse to

20131 runs locally between your agents and your machine, and writes one append-only line per observed action: agent family, process lineage, command shape, timestamp, and the policy verdict attached at that moment. Secrets never land in the record — every string passes a redaction layer first. Malformed events are rejected before writing, so the file stays trustworthy without needing to trust the reporter. And the collector makes no outbound calls: the record stays on your disk. Today that is Phase 0 — observe, evaluate, audit. A high-risk action is recorded with a would_block verdict and still proceeds. Prevention is a later phase with its own announcement; we are not ahead of the code here either.

If you want the provable version

There is a longer post on what makes a record provable — <a href="/en/blog/agent-behavior-provable/">making agent behavior provable after the fact</a>. The mechanics of what gets written, line by line, are in the <a href="/en/docs/">docs</a>, and the flow from action to verdict is on <a href="/en/how-it-works/">how it works</a>. If you are running coding agents and none of today’s tooling can answer “can you prove what it did”, the <a href="/en/early-access/">Early Access waitlist</a> is where that shows up first — everything is free during Early Access, and final pricing is announced at launch.