Golden Data

The workbench, measured over the most recent 90 days

The agent-vs-human scorecard

Every task I complete gets tagged with who did it — agent or human. This is the two-column readout of that split from my own task log over the most recent 90 days: outcome rate, dollars per instance, and minutes to complete. No pitch — just the numbers, aggregated straight out of the database and stripped of everything personal before they ever reach this page.

Agent

skills, automations, scheduled runs

Cost / instance
$1.13
Minutes / instance
11 minmed 5
Outcome rate
87.6%
Completed
465of 531

Human

me, by hand

Cost / instance
$25.58
Minutes / instance
34 minmed 17.5
Outcome rate
89.7%
Completed
210of 234
$24.45cheaper per instance when the agent handles it
3.0×faster — 11 min vs 34 min
2.1 ptsoutcome gap — the human lane still closes more of what it starts

Week of 8/17: agent slice closed 35.8% at $2.21; human slice closed 84.3% at $24.53.

Per-instance cost, week by week

Rolling 90-day view, bucketed by when work finished. The first and last weeks are partial.

Agent Human
How every number here is derived
  • Handler is the real origin tag on each task (agent or human) — 765 tasks touched in the most recent 90 days, tagged as I go, not reconstructed after the fact.
  • Outcome % = completed ÷ started for that lane. Minutes is logged time per task (actuals where I have them, my estimate otherwise).
  • $/instance is the one modelled figure: minutes × a fixed per-handler rate — $0.75/min for human labor (≈$45/hr) and $0.10/min for agent compute + oversight. Change those two rates and every dollar figure moves; nothing else is invented.
  • Privacy. These figures come from anonymized database views that emit only counts and durations — never a task title, note, or category. A dbt leak gate blocks publishing if any personal string slips through.
  • Honest caveats. The agent lane only started being tagged in June, so its history is short. One heavy batch week (208 agent tasks) reflects automation backfilling a queue. This is a workbench measuring itself, not a benchmark.

Read live from the database at build time · data as of Aug 24, 2026

How this is safe to publish

The numbers above come from my real task manager — every row in it has a title, notes, and people attached. None of that reaches this page. A dbt layer publishesallow-list views over the private tables: a column is invisible to the public until a model explicitly selects and reduces it to an aggregate. The only text the views emit is the handler tag, agent or human.

FIG. 1 · The safe-publish lineage
tasks (private)contacts (oracle)scorecard_handlerscorecard_weekly27 tests · leak gatethe sitePRIVATEMODELSGATESPUBLIC
Private tables never face the public. The models aggregate; 27 dbt tests gate the result; a red gate blocks the publish.

The leak gate, verbatim

Three checks, tightest first. Any row returned fails the build — and a failed build never publishes.

case
    when p.value is null or not (p.value = any(p.allowed)) then 'not-in-allow-list'
    when p.value ~* '[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}'  then 'email-pattern'
    when p.value ~ '(\+?\d[\s.-]?){7,}'                      then 'phone-pattern'
    when p.value ~ '\d{3}-\d{2}-\d{4}'                       then 'ssn-pattern'
    when lower(trim(p.value)) in (select pii from oracle)    then 'matches-contact'
end as reason

Last dbt build: 27/27 gates green · leak gate PASS · Jul 22, 2026

Read the full gateThe dbt project on GitHubThe full story →