By Brian Sanchez — 17 Aug 2026

Measuring Agent Productivity

Overview

Measuring productive work in the agentic era requires you to rethink how work is measured, data is acquired and preserved, and the tools are used. It requires building out tool-chains and systems of observability that can allow engineering managers to derive meaningful insights from the chaotic era of token economics.

Tools like Copilot CLI, Codex CLI, Claude Code, and others give users granular integration hooks and token metrics to seed discovery of productivity, but it is up to the organization to associate these values with their own systems of record to fully take advantage of this information.

Agent Execution Productivity

Our goal is to measure human and agent execution productivity. Before defining the method, we establish a set of assumptions around parameters that define our productivity calculation. For the purposes of this demonstration we will ignore human and agent efforts related to planning.

Assumptions

Time Estimations - Large Language Models (LLMs) are trained on a world-scale corpus of human knowledge. LLM-generated estimates provide us with a standardized estimation mechanism that can be applied consistently across work items. This should be calibrated against historical human estimations and actual execution data rather than treated as ground truth. As an example, if you were to ask ChatGPT to estimate the time it would take to implement a login, it would provide a reasonable answer (to a Senior Engineer).

💡

This is not a core requirement to measuring productivity, however it is beneficial for consistent reporting, and for the purposes of this measurement system, I enforce the LLM to estimate work.

User Stories - It is assumed that the User Story definition is standardized to achieve the most consistent estimations of time. As an example, a Login can mean different things to different engineers, so the granularity of the work should be standardized and encapsulate non-technical and technical requirements, UI elements and acceptance criteria.
Agent Run Time - Agent run time is the amount of time an agent spends on a User Story from "Doing" to "Completion". This is reflected in hours and used as the value to compare against traditional estimations. We save these as Timestamps. Again, "Planning", for the purposes of our demonstration, is not included in the calculation.

💡

Planning, Doing and Completion may have different definitions in your organization, so it is important to define these before implementing this methodology.

Agent Execution Productivity - Simply relative performance to human execution productivity (i.e. 1.5x). So our output would be a productivity multiplier based on a single engineer's standard expected execution time based on our LLM forecast.
Rework - For the purposes of this methodology we measure the agent rework time as the time it takes for any agentic rework to done on the task based on human review.

The Simple Method

Below is a method that takes the assumptions and develops a simple approach measuring relative agent execution productivity.

Create a User Story (With Reference ID)
Create the Plan from the User Story (Output in markdown)
Estimate the Plan (In Human-Hours)
Execute the Plan (Track agent start and end time)

As an example – A Login Estimation:

LLM estimate (human hours): 8 hours
Agentic completion hours: 0.5 hours

Productivity multiplier on execution-related work.

The user story was completed with a 16x execution productivity multiplier compared with the original human estimate for execution-related work.

Additional Metrics

There are a few additional noteworthy metrics that might be useful for assessing context usage versus output quality and overall performance of frameworks such as speckit, superpowers and others. They are identified below.

Tokens per Story Point

Tokens per story point can be used as a measure of efficiency of the skills, agents, and standards you employ. Because now we know that what the average tokens per story point may be depending on the complexity of the task, we can properly minimize token usage along agentic execution paths in our pipeline by fine-tuning prompts and skills along with optimizing up front context.

Agentic Hourly Rate

Agentic hourly rate is a hard measure of how much an agent is costing your organization on an hourly basis. This is a blended rate of Input Token Price, Output Token Price, and Cache Token Price if you would like to include it.

Conclusion

Above we demonstrate the ability to measure the execution productivity of agents on standardized tasks. However basic the demonstration, it reflects a clear approach to capturing simple data points to achieve a key metric for assessing whether or not your implemented agentic engineering processes are actually generating productive work for your business.

With this example comes a few considerations:

The example did not include rework hours since there was no estimated human rework, however the principle is the same.
The planning time is not included in the work. Depending on your measure, you may want to include any agent time spent beyond initial conception of the user story as part of the calculation.
A measure of story points can be assigned along with human-time estimations during the planning stage to also measure agentic velocity over numerous sprints.
Implement a test suite of estimations to measure data drift across various LLM systems and model updates to ensure that over time, your method of time estimation is stable (assume some variance).

If agentic engineering is going to become a meaningful source of engineering capacity, we need to measure it like one. Execution productivity gives us a practical place to start.