The commit log said the team shipped. It did not say what the team did. Twenty terse messages to main — "fix deploy," "encrypt secrets," "refresh compare page" — and no thread connecting them into a week of engineering.
When your engineers are coding agents, that gap gets wider, not narrower. The authors are Claude and Codex sessions that ended days ago, running across two machines, committing over SSH. GitHub shows the final diffs. It says nothing about how much work happened, which agent did it, what it was for, or what it decided along the way.
So we opened AgentPM — the layer recording every agent session in our org — and did what you do with any unfamiliar system: asked the broadest question first, then followed the answers down.
How much is even happening?
Before naming anything, we wanted scale. Is this a trickle of experiments or a running operation? One command enumerates everything the org's agents have recorded, grouped by the directory they ran in.
$ agentpm conv projects --org nine-oaks 45 project(s) /agent-workspace/outputs conversations=107 turns=21868 tokens=unknown latest=2026-07-20T22:37:50.266Z /Users/drew/Documents/src/ProjectRelay conversations=67 turns=42637 tokens=unknown latest=2026-07-20T22:23:15.318Z /Users/drew/Documents/src/ProjectAtlas conversations=36 turns=35671 tokens=unknown latest=2026-07-20T22:00:29.457Z /Users/drew/Documents/src/ProjectField conversations=39 turns=45602 tokens=unknown latest=2026-07-20T21:48:58.303Z … 41 more projects
Summed across all 45 directories: 1,426 conversations and 345,759 recorded turns. And this isn't an archive — the command ran at 22:40 UTC, and the freshest conversation had reported in at 22:37. The record was three minutes old when we read it.
What's it costing — and which agents are doing it?
Volume without cost is trivia. The dashboard's Utilization panel prices the day as it happens, split by agent product and by model. This is Monday, captured mid-afternoon.
The mix itself is a finding. Three agent products in daily use — Codex, Claude Code, Claude Cowork — on four models from two vendors, priced together on one panel no single vendor's console will ever show you. To connect the spend to actual software, though, we had to ask where the work landed.
Which repositories consumed the effort?
The same rollup, read for concentration instead of scale. AgentPM buckets work by working directory, across every agent and every machine — so the same repo shows up wherever it's checked out.
$ agentpm conv projects --org nine-oaks 45 project(s) — ProjectAtlas, by checkout: /home/drew/src/ProjectAtlas/apps/api conversations=331 turns=42473 tokens=unknown latest=2026-07-03T09:00:46.789Z /home/drew/src/ProjectAtlas/apps/web conversations=200 turns=22952 tokens=unknown latest=2026-04-29T04:34:19.080Z /home/drew/src/ProjectAtlas conversations=133 turns=28506 tokens=unknown latest=2026-07-11T07:47:31.272Z /Users/drew/Documents/src/ProjectAtlas conversations=36 turns=35671 tokens=unknown latest=2026-07-20T22:00:29.457Z … and the ProjectField app suite: /home/drew/src/ProjectField conversations=173 turns=46893 tokens=unknown latest=2026-07-03T10:21:06.544Z /Users/drew/Documents/src/ProjectField conversations=39 turns=45602 tokens=unknown latest=2026-07-20T21:48:58.303Z
/Users/drew is a laptop, /home/drew is a server. No per-repo view in any vendor console stitches those together. Project and identity labels have been replaced with neutral aliases.The rollup surfaced something else. Under ProjectAtlas, the newest session opens: "I'd like to continue the work my Claude Code session was doing in conversation goc_demo_01…" — an agent picking up another agent's thread by ID. The record isn't just for humans reviewing; the agents themselves use it as memory.
The heaviest live system was ProjectAtlas — real-money-adjacent — so that's where "what were they actually doing?" was most worth answering.
What were they actually working on?
We scoped to one checkout of the trading platform. work returns its recent sessions — from every agent that touched the directory, on any machine.
$ agentpm conv work --cwd /home/drew/src/ProjectAtlas 1 project result(s) nine-oaks /home/drew/src/ProjectAtlas conversations=4 goc_demo_02 [remote] 2026-06-23T16:39:46.543Z Ok so i am seeinga numvber of execution issues today can yoiu publish a report to /report expla… … 3 earlier sessions
In the CLI, every row opens with the session's first prompt, verbatim — typos and all. That's deliberate: this is a record, not a rewrite. [remote] means another agent on another machine; the query doesn't care whose terminal the work happened in. The dashboard's project page adds generated titles, per-session pricing — and one number that reframes the repo entirely.
A feed is orientation, not understanding. To trust any of it, we needed to see inside one session — the actual commands, outputs, and reasoning. We opened the broker-credential hardening.
What happened inside one session?
Every conversation is a turn-by-turn timeline: prompts, reasoning, every tool call and shell command, with output. This session began with the question "if we are storing tokens to auth brokerage accounts how do we make sure to have the utmost security" (turn 1, original spelling below) and ran for 773 turns. We jumped to the end.
$ agentpm conv show --around 750 --limit 8 goc_demo_03 goc_demo_03 nine-oaks [local] if we are toring tokens to auth brokerage accounts how to we majke sure to ahve the upmost secu… [749] tool_result Wall time: 1.4023 seconds Process exited with code 0 Output: api_root=200 admin_chat_unauth=401 session_expiry_constant=1209600 expired_session_rejected=True forged_clerk_rejected=True [750] assistant Deployed: yes. In `main`: no. On prod-node-01, the repo is on `main`, and `HEAD == origin/main` at `abc1234`, but the security changes are still uncommitted live changes: - modified: `apps/api/app/auth.py` - modified: `apps/api/tests/test_access.py` - untracked: `apps/api/app/security/` … [753] user lets commit [754] assistant I’ll commit the live prod-node-01 security hardening, but I’m going to stage only the relevant auth/broker/security files. The host has other dirty files, so first I’m checking the full status and diffs to avoid scooping unrelated work into the commit.
This is the "aha" in miniature. Without the record, "encrypt secrets" is a commit message. With it, you can see the verification that preceded it, the drift it caught, and the judgment applied at commit time — recoverable months later, long after the session and its author are gone.
Are there patterns across the whole org?
Nobody reads 1,426 conversations. AgentPM reads across every analyzed session and rolls behavior up into coaching signals — the part no individual transcript can show.
CLAUDE.md. Below it, resource accounting GitHub will never have: exec_command alone — 41K calls, 1.6B tokens. This is the organizational read — habits, not incidents.Can I find the risk directly?
An engineering leader's real worry isn't a metric — it's "did anything dangerous happen that I don't know about?" Instead of opening sessions hoping to stumble on it, we searched the whole corpus for the words that matter.
$ agentpm conv search "secret credential api key" 41 conversation(s) for agt_demo_01 … 3. goc_demo_04 nine-oaks [local] ok we're now going to add a live brokerage account and test live trades 2026-07-15T17:35:11.621Z home turns=8467 … 7. goc_demo_05 nine-oaks [local] Review ProjectAtlas security concerns 2026-07-09T21:23:12.311Z -Users-drew-Documents-src-ProjectDemo turns=44 … 14. goc_demo_03 nine-oaks [local] if we are toring tokens to auth brokerage accounts how to we majke sure to ahve the upmost secu… 2026-06-26T05:45:14.083Z home turns=773 … 38 more
dev-laptop and prod-node-01. No knowing where it happened required.That was the moment the review stopped feeling like archaeology and started feeling like operations. Every question — how much, what cost, which repos, what work, what happened, what patterns, what risk — had an answer one command or one click away.
GitHub shows the diff. AgentPM shows the operation.
Retrace the walk. Starting from a vague Monday question, and without reading a line of source, we reconstructed the operation: a six-agent fleet whose newest data was a minute old, the day's spend priced live at 66% cache, half the org's 1,426 sessions concentrated in one trading platform carrying a $2,134 list price, a security hardening that was live in production before it was ever committed, an org-wide habit of long unplanned sessions, and every credential-touching session — enumerated, not guessed at.
Worth saying plainly: this is our own two-user, six-agent org, and the day cost thirteen dollars. The point was never the size of the spend — it's that even at this scale, "what did our agents do, and what did it cost" had no answer without a second system. Scale the fleet to a fifty-engineer team and the spend grows two orders of magnitude; the question doesn't get easier — it just gets a CFO attached.
None of that lives in GitHub. GitHub is a record of artifacts — the final state of the code. It is silent on the operation that produced them: which agent, on which machine, at what cost, with what reasoning, verified how. When your engineers were humans you filled that gap with standups and memory. When your engineers are agents, memory isn't an option — the author forgets the moment the session ends. Unless the session itself is the record.
An org running coding agents needs two systems, not one. GitHub for the code that shipped. And an operational layer — activity, utilization, repositories, feed, timeline, insights, search — for the work that produced it. AgentPM is that second system: the answer to "what have our agents actually been doing?" when the honest starting point is "I have no idea."
You can read a diff and still have no idea what your team did. The operation is the part GitHub throws away — and the part you now most need to keep.