← Four tellings Data Driven Partners
Data Driven Partners · A record of the work

The rise of the individual contributor

Over seven months, one self-taught operator’s leverage — agent-hours absorbed per hour of his own touch — rose roughly fivefold, because the job changed from typing to specifying. The evidence is a B2B data pipeline built end to end, alone — sourcing, enrichment, identity, certification, sale, self-monitoring — reconstructed from his own work logs.

Nov 2025 – Jun 2026 · figures are transcript telemetry, not audited books

Between December 2025 and May 2026, the agent-hours the system absorbed per hour of the operator’s attention rose roughly fivefold (Exhibit 1), because the job of Tristan — the operator behind Data Driven Partners — changed from typing, one conversation and one correction at a time, to specifying work precise enough to run without him. The evidence follows: a month-by-month record, then the record’s hours cut three ways — when they happened (Exhibit 3), whose they were (Exhibit 4), and where they pooled (Exhibit 7).

Across four tools — Cursor, Claude Code, Codex, and Claude desktop — the full record runs to roughly 1,350 system-active hours of data work in 802 sessions, steered by 12,565 of his own messages: specification, correction, review. What the transcripts document is the assembly, failure, and reassembly of an end-to-end agentic data pipeline — sourcing, enrichment, identity, certification, sale, self-monitoring — that today delivers records at about $1 a lead with 24-hour turnaround, re-verified on demand rather than left to decay in a static catalog.

November 2025

He runs a cold-email agency. It runs on business-contact data — who works where, what their address is, whether it still resolves — and that data decays at two to three percent a month, so a third of any rented list is wrong within a year (see “The economics” comparison table). In November he decided to stop renting it and build his own. The first move was a migration: drag the data off SQL Server, where the Azure bill was climbing, onto Postgres — the opening experiments in the store lane of Exhibit 2.

December

He wired an assembly line: take a company name, find its real domain, find the decision-maker, find the email, verify it, enrich it. Each step a worker; each worker its own small machine. Most of them broke. Jobs fell into retry loops that claimed a task, crashed before finishing, and handed it back to themselves. A second failure class was harder to detect: functions returned “200 OK” while the real work died in the background, so the dashboards reported green over a stalled queue.

December took 304 hours of work, nearly all of it one person in the Cursor editor, one message at a time — the tall single-tool bar at the left of Exhibit 4. The longest conversation in the record belongs to this regime: it opens on December 19 with a request to implement a pipeline design in Supabase and closes a month later, more than a thousand messages deep, with a working domain enricher and a store holding 37.2 million prospects. The instruction that repeats most in the logs is not a request for anything new. It is simple, simple, simple — tear the thing down and rebuild it with fewer moving parts.

January – February

He started re-deriving the discipline he’d never been taught. He had an assistant take on the methods of Ralph Kimball, the patriarch of data-warehouse design, and audit his work; he collapsed a tangle of tables into one jobs table where all the progression logic could be read in one place. Where a rule would do the job of a model, he used the rule: deterministic filters dropped foreign domains, broken characters, and anyone who wasn’t a founder or an owner before a cent was spent on them.

Then identity. The same company kept entering the store under three spellings, and the duplicates degraded the records that actually sold. The fix removed a problem rather than adding intelligence: rather than build a smarter merge, he made identity permanent and attributes perishable — mint an internal ID once, let domains and emails decay against it, and resolve duplicates on deterministic match keys (Exhibit 5, “Company identity”).

February – April

The next constraint was sourcing. Renting records made no sense for the supply side either, and cloud scraping failed on cost and on static-IP limits. So he moved from renting compute to owning it: a domain-finder scale-up and hand-written scrapers — a 190-hour workstream, the second-largest line in Exhibit 7 — then an Ubuntu laptop reachable over Tailscale, set up as a dedicated scrape box that fed the pipeline its raw material (Exhibit 2, “Sourcing & scraping”).

April – May

The change behind the fivefold figure came in the spring (Exhibit 1). Through the winter he had worked one conversation at a time, supervising every step; one logged session ran 186 hours. In April he stood up the scaffolding — specifications precise enough to run unattended, a load balancer to pool model capacity — and in May he ran fleets of agents in parallel. In May the system absorbed 524 hours of agent work, most of it running on its own while he steered: the dense right-hand cluster in Exhibit 3, and the month in Exhibit 4 when Codex and Claude Code swarms displaced the editor. The architecture caught up with the work: an append-only observation log, a trust-ranked golden record, a certified-leads view, and a freshness policy — build the data product, not just the process that fills it.

June

By June the system largely operates itself. Scheduled monitors check the morning’s pulls, a daily job chases anything stuck, and the system refuses to sell a record it can’t vouch for; the seven capability rows of Exhibit 5 summarize the November-to-June difference. He reads the summary. The next problem is already measured: reply rates on his outbound have fallen from twenty qualified leads a day to three — the number he is pointing the machine at next.

~1,350
system-active hours in seven months
802
sessions across four tools
12,565
messages directing the fleet
37.2M
prospects in the v1 store
524
hours in May, the peak month
The operating model
Leverage rose roughly fivefold as the job moved from prompting to swarming to looping
Read left to right, the seven months are three operating models — prompting, swarming, looping. In each, the operator moves further from the work, and the binding constraint moves with him.
Exhibit 1
The operator moved from in the loop, to above it, to outside it — and agent-hours per touch-hour rose ≈5×
The changing topology of one human and his agents, Nov 2025–Jun 2026
PHASE 1 · PROMPTING Nov 2025 – Apr 2026 · the conversation PHASE 2 · SWARMING May 2026 · the delegation PHASE 3 · LOOPING Jun 2026 → · the system one thread, both ways IC agent Human in the loop, every step IC specs ↓ ↑ results Human above the loop, directing ⏱ daily schedule summary IC Human outside the loop, reviewing
Phase 1The conversation
Phase 2The delegation
Phase 3The system
Leverage
≈ 1× — one human-hour buys one
≈ 5× — agent-hours per touch-hour
Standing — runs while he sleeps
Bound by
Human endurance — output ends when he does
Specification quality — you get only what you can describe
Self-awareness — the system fixes only what it knows to check
Signature artifact
One 186-hour thread; 304 hours in December alone
209 sessions in 10 days; 524 agent-hours in May
Control-tower loop, stage-pull monitor, daily rescue

Source: phase boundaries from harness mix and session structure in the transcript corpus; leverage is agent-active hours per operator-touch hour, December vs. May. Topology is illustrative. Figures are transcript telemetry, not audited financials.

The build map
Where hours did not compound: every component was built at least twice
No component was built once. The store was rebuilt around the observation-log schema; the enrichment pipeline twice; the storefront went GHL → bolt.new → Vercel. Each rebuild was triggered by a structural failure in the layer beneath it. By June, for the first time, the whole system is in operation at once.
Exhibit 2
No component was built once — each layer was rebuilt as the one beneath it failed
System components by development stage, Nov 2025–Jun 2026. Hover any segment for what was happening and why.
Experiment Build (new) Rebuild Operate Retired

Source: development stage inferred from session working directories, first-prompts, and dated migration files across the four-harness transcript corpus. Figures are transcript telemetry, not audited financials.

The hours, first cut: when
The same effort made two calendar shapes — a serial winter, then a parallel May
First of three cuts of the record’s hours: when the work happened. Each bubble is a project, placed on its date span; area is proportional to system-active hours. The prompting era runs serially across the left half — the Supabase pipeline build, then the scraper scale-up, largely one workstream at a time. The dense cluster on the right is May 2026, when swarming fractured the work into parallel agent sessions. (Exhibit 4 cuts them by whose they were; Exhibit 7 by where they pooled.)
Exhibit 3
The hand-built winter dominated the calendar; the May swarms matched it in a fraction of the time
Hours of data work by workstream, Nov 2025–Jun 2026. Bubble area = system-active hours; ticks below baseline = date span. Hover any bubble for detail.
DDDB platform Schema & pipeline core Audit & rules swarms Scraping & sourcing Productization & ops Knowledge & monitoring

Source: 467 Claude desktop audit logs; 786 Codex rollout logs; 36 Claude Code transcripts; 631 Cursor conversations (715,297 message bubbles), parsed June 12, 2026. Hours = event gaps summed, capped at 10 minutes. Figures are transcript telemetry, not audited financials.

The hours, second cut: whose
The hours changed hands twice: an editor, then swarms, then monitors
Second cut of the hours: whose they were. December’s 304 hours were almost entirely one person in Cursor, one conversation at a time — prompting. May’s 524 hours inverted the model: mostly Codex and Claude Code swarms running under direction — swarming. June’s smaller, steadier bar is looping — scheduled monitors operating the asset instead of rebuilding it.
Exhibit 4
December’s hours were one person in an editor; May’s were agent swarms — the same effort, restructured
System-active hours of data work per month, by tool
Cursor Claude Code Codex (multi-agent swarms) Claude desktop

Source: same transcript corpus as above. Autonomous agent runtime counts while producing events under direction; idle gaps >10 min excluded. Figures are transcript telemetry, not audited financials.

Then vs. now
Across seven capabilities, the system crossed from a process he ran to an asset that runs itself
No single month looks like a revolution — yet across seven dimensions, the system crossed from a process the operator ran to an asset that runs, sells, and checks itself. Every line in the right column is live in the transcripts.
Exhibit 5
On every dimension, the system crossed from a process he ran to an asset that runs itself
Seven capabilities, November 2025 vs. June 2026
November 2025June 2026
Getting data
Hand-run pulls; every list dies after one campaign
Any request runs the full pipeline on demand — the web vending machine, about $1/lead, 24-hour turnaround
Trusting a record
Trust lived in one person’s head; no field carried its own provenance
Certified-leads view with provenance, trust-ranking, and a freshness policy — “is this still good?” is a query
Company identity
The same company under three spellings; dupes double-counted
Deterministic match keys and survivor-based merges on permanent internal IDs
Quality
Leaks discovered by inspection, fixed one at a time
A rules engine distilled from a 350-session audit swarm; leakiness is a dashboard number
Sourcing
Renting records — per-record cost, no control of coverage
An owned scrape farm: gas-city orchestration, Crunchbase coverage, the NF-One server
Operations
Late-night hand-debugging; the pipeline ran when pushed
stage1-pull monitor, pipeline-rescue daily, control-tower loop — the system notices its own problems
Leverage
One person, one editor, one conversation at a time
Hundreds of parallel agent sessions under written direction, across four tools

Source: capabilities verified against session outputs — certified-leads view queries, vending-machine requests, monitor run logs, merge procedures in migrations 028–035. Figures are transcript telemetry, not audited financials.

The economics
An agentic pipeline carries almost no decaying inventory; a traditional catalog prices decay into every seat
A traditional provider builds a database once and licenses it many times — so every seat licence includes records that have already decayed. An agentic pipeline carries almost no inventory: records are sourced, enriched, and certified when asked for, at a marginal cost that is mostly compute. The comparison reflects design intent and early production behavior at boutique scale, not an audited benchmark.
Traditional providerAgentic pipeline (DDDB)
Marginal cost of a recordPer-seat licence or credits; the same stale record re-sold many timesNear-compute: owned scrapers plus waterfall enrichment; a refresh costs an API call
FreshnessStatic catalog decaying 2–3% a month, amortized across all subscribersPer-field freshness policy; re-verifies what moved; staleness is a queryable state
Turnaround on a custom listLimited to filters over the existing universe24 hours: the full pipeline runs on demand for any request
Quality guaranteeBounce credits, after the failureRecords gated before sale: provenance, trust-ranked resolution, certified-leads view
Coverage controlFixed: the provider’s universe is the universeSteerable: point the scrape farm at any niche (Crunchbase, NF-One targets)
Cost structureSales, licensing, and compliance overhead priced into every contractOne operator plus scheduled agents; priced at about $1 a lead
Failure modeSilent rotSelf-reporting: monitors file daily status; leakiness is a dashboard number

Source: pipeline behavior from transcripts and migration files; decay benchmarks from industry studies. Comparison reflects boutique-scale production, not an audited head-to-head. Figures are transcript telemetry, not audited financials.

The hours, third cut: where
Effort pooled in the 390-hour hand build; leverage came from hours that barely register
Third cut of the record: where the hours pooled, against where the leverage came from. The Supabase pipeline build’s 390 hand-built hours remain the single biggest line; the two May swarms together (262 hours, 350 sessions) approach it in half the calendar time. The moves that reorganized everything — the four-hour observation-log schema and the 2.7-hour north-star reset — sit at the bottom of the chart.
Exhibit 7
The two highest-leverage moves — the schema and the reset — barely register in hours
Hours by workstream. Sessions and date span below each name; same-project work across tools merged.

Method: Codex/Claude Code projects classified by working directory; Cursor and Claude desktop sessions by keyword match (≥2 data-domain terms) on the operator’s own messages. Pre-March Cursor splits are approximations from monthly totals. Concurrent sessions are not de-duplicated — totals are effort volume, not wall-clock. Figures are transcript telemetry, not audited financials.

A new class of builder
The tools removed the last mile; specification and persistence remained the human share

The record reduces to labor: about 1,350 system-active hours of data work in seven months — roughly eight months of a full-time engineer — produced by one self-taught operator and a fleet of language models. The 12,565 messages he wrote into these sessions are the human share: specification, correction, and the choice, at each fork, of what to build next.

The leverage curve is the finding. In December, output scaled with endurance — 304 hours, including a single 186-hour conversation, hand-debugging queue plumbing one message at a time (Exhibit 4). By May, output scaled with architecture: 524 hours of agent labor absorbed in a single month, steered in parallel across Codex and Claude Code swarms (Exhibit 3). Same operator, same problem — but agent-hours absorbed per operator-touch hour rose about five times over (Exhibit 1), because the job had changed from typing to specifying.

He has no formal data-engineering training. The tools removed the last mile — the syntax, the plumbing, the small competences between specifying a thing and having it run. What they did not remove is measured in Exhibit 2: no component was built once — the enrichment pipeline was rebuilt twice, the storefront moved platforms twice, and rebuild segments recur into the record’s final month. The hours that separated an almost-done component from a done one were the hours the tools did not save, and the record’s constant is that the operator kept supplying them, along with the decision of what to build next. Whether that holds beyond one operator’s telemetry (n = 1) is the question the record leaves open.

For leaders
Growing the high-leverage contributor
Five patterns from one operator’s record (n = 1) of prompting, swarming, and looping — each tied to the exhibit that shows it. Observations, not a playbook.
1
Promote ICs along the curve, on purpose
In this record, the operator stalls where he lingers at the prompting stage: from November through April, the monthly bars in Exhibit 4 are almost entirely single-threaded editor hours. What moved him forward was the shift from prompting to delegating to systematizing — treating “put a loop on it” as the default next step. Here the promotion was self-administered; whether it can be scheduled from outside is untested in this record.
2
Hire for specification, not syntax
The scarce skill in this record shifted from writing code to framing the structural problem. The observation-log schema that reorganized the store took about four logged hours, against the 390-hour hand build (Exhibit 7); the typing was never the bottleneck — the specification was.
3
Measure standing leverage, not hours
A contributor at the looping stage produces output that keeps running overnight — the third phase of Exhibit 1, the operations row of Exhibit 5 — which a count of hours or headcount misreads. The metric that fits is loops-in-production: how much of the work continues after the person logs off. It is measured here for one operator only.
4
Manage the bottleneck that moved
Each phase relocated the constraint — endurance, then specification quality, then the system’s blind spots — the “bound by” row of Exhibit 1. Yesterday’s fix became the next failure mode, which is why the binding question — what is the constraint now? — had to be re-asked at every step.
5
Fund the reframe; protect the rebuild
Retiring working code was the hardest discipline in the record: the GHL storefront ran from November until May before it was retired for the rebuilt product (Exhibit 2). Where incentives punish throwing away what already runs, the risk this record illustrates — once, not at population scale — is that contributors stay a phase too low, tending a system they could be replacing.

What isn’t proven

The hours and costs here are read from work logs, not audited books.

The leaks a May code review found were specified for repair, not yet shown fixed.

The economics rest on early, small-volume selling; they may not hold at scale — connection pools already saturated at 37 million rows.

Owned scraping carries anti-bot, terms-of-service, and regulatory exposure that licensed vendors absorb for their customers.

The operation’s judgment still lives in one head; the specs and skills mitigate, but succession is unproven.

Methodology & coverage. Reconstructed from 715,297 messages across four tools — Cursor, Codex, Claude Code, and Claude desktop — on the operator’s machine, Nov 2025–Jun 2026: 467 Claude desktop audit logs, 786 Codex rollout logs, 36 standalone Claude Code transcripts, and 631 Cursor conversations (715,297 bubbles from state.vscdb). “System-active hours” sum the gaps between logged events, capped at ten minutes each — idle time excluded, autonomous agent runtime included. Not covered: ChatGPT/DeepSeek/Perplexity histories, hosted-tool work (bolt.new, Supabase dashboards, GHL), and Cursor bubbles beyond each conversation’s first 15 user messages for classification. Figures are transcript telemetry, not audited financials.