Accountability in Agentic Workflows by Measuring Your Agents’ Performance as You Build

Measuring cost and value directly instead of guessing at both

We’ve started building software products with AI agents, and pretty much developed this agentic mode of working within software engineering teams.

The problem has shifted from getting agents to execute our tasks to measuring their performance and ensuring accountability.

We don’t have a reliable way to know what an agent is actually doing with the resources it consumes, or whether what it produces is worth keeping. That gap in transparency hides two separate failure modes.

Invisibility of spend

When an agent burns through tokens, calls tools, and re-reads context across a dozen turns, that cost collapses into a single number on a dashboard: “tokens used”.

Looking at Claude Code Usage limits on my account and viewing an opaque report

I ran into this looking at Claude Code usage limits on my own account. The report tells you a total. It doesn’t tell you whether that total went to genuinely new reasoning, to re-sending the same system prompt and tool definitions on every turn, or to caching overhead that should be nearly free.

Without a structural breakdown, “optimise the agent” is a guess. You’re tuning a system you can’t see inside.

So the first thing we need is structural transparency. That means breaking spend down into the categories that actually drive it:

• repeated context

• tool scaffolding

• cache hits vs. misses

• genuinely new work

You can’t decide what’s worth fixing until you can see where the waste concentrates.

Invisibility of value

The second problem is harder.

Evals, even good ones, even LLM-as-judge setups, are proxies for usefulness. Most Agent evals currently, tell us how good or bad an agent’s response was. This is quite different from how useful the output was.

Traditional evals tell you whether an output resembles what a rubric expects, not whether a real person, on a real task, actually used it.

Imagine a team ships work an agent produced because it looked good, then finds out three weeks later, from a support ticket or a frustrated colleague, that the agent has been quietly wrong in production the whole time. There's no continuous, ground-truth signal for "did a human keep this or throw it away."

So accountability on value of output defaults to vibes.

Bridging the gap

Both problems have the same shape, and the same fix: stop treating cost and value as things you infer, and start treating them as things you measure directly, with the measurement kept honest by construction.

For cost, that means structural transparency. We need to see where resources are actually going.

For value, that means measuring what happens to the output after the agent produces it. Did a person actually use this, in whole or in part, or did they discard it?

A visual summary of the accountability gap in Agentic Engineering: from invisible spend and uncertain value to a workflow for measuring both.

Building accountability into the workflow

Turning that principle into practice takes a few concrete disciplines.

1. Capture the full session.

   Every agent tool leaves behind a full, raw log of the session it just ran, for example under ~/.claude/projects/.... Every prompt, every reply, every tool call, is written to disk the moment it happens.

   Capturing the full session starts with finding every one of those log files across every project you’ve worked in, not just the one you happen to remember.

   From each file, you pull the two things that matter: what was asked, and what came back, with the exact token usage attached to every reply. What you end up with is a queryable, turn by turn history of everything an agent has actually done.

2. Break usage down structurally.

   Every one of those log files also carries the exact breakdown of where tokens went on each turn: new input, cache write, cache read, output.

   Keeping those categories separate, instead of collapsing them into one cost number, and pricing each one at the moment the turn happens rather than averaging it out later, is what makes the breakdown useful.

   You end up with a cost picture you can actually act on, showing where the money goes instead of one total that hides all of it.

3. Review outputs by hand, and record what was kept.

   Once a response is captured, nothing about whether it was actually useful gets decided automatically.

   You go back over what the agent generated and tag it yourself, piece by piece, based on what you actually did with it afterward, marking each piece as used, copied, or discarded. Anything you haven’t looked at yet stays untagged rather than defaulting to a verdict either way.

   This is slower than trusting a score, but it’s the only way to build an adoption ratio from your own judgment rather than from a model grading itself.

4. Let automation assist the review, but not replace it.

   Tagging every response by hand takes time, so a cheap secondary pass can speed that up, flagging a chunk as likely core answer or likely filler, with a confidence score attached.

   The rule that keeps this honest is simple: automation’s output sits next to your own tags as a suggestion, never as the tag itself. You can accept it, edit it, or ignore it, and it only becomes part of the record once you’ve confirmed it.

   That’s how you get faster review without letting a guess quietly stand in for your judgment.

Conclusion

None of this needs a research team or a six-month platform. It needs treating your agent’s own logs as a dataset worth keeping, and treating “did a human keep this” as a number worth tracking rather than a feeling you’ll get around to checking someday.