Skip to content
dacard.ai
The point · How it works

Eight beatsSix minutes end to end

Building got cheap. Deciding what to build, and knowing whether it landed, did not.

Eight claims in order. By the end you should be able to tell whether your own team is counting effort or counting outcomes, and what it would take to change that.

If you read one thing

Claim 06 is the one that changes a review the following Monday. Everything before it explains why it works, and everything after it shows the cost of skipping it.

Jump to claim 06
01What changedTwo weeks to an afternoon

The expensive part of software stopped being the writing.

An agent now does in an afternoon what took a competent team two weeks. I have done it myself and watched other teams do it. The part that did not get faster is the part where somebody looks at the result and decides whether it is right.

2 weeks an afternoonTime to a reviewable first version
Illustrative
2015Two weeks

Nine days of drafting, reading, and checking. One day of deciding.

2026An afternoon

The drafting collapsed. The deciding is exactly as long as it was.

Agent work, the part that got cheapHuman judgment, unchanged
One scale, ten working days. The gold block is the same width in both rows.
02What is scarceDeciding and knowing

Two things are scarce now: deciding, and knowing whether it worked.

When capacity was the constraint, prioritising was mostly triage. Now that almost anything can be built this week, the choice itself is the expensive act, and so is finding out whether the choice was right.

Abundant nowIllustrative
  • Writing the code
  • Reading the tickets
  • Drafting the options
  • Checking the rules

Struck through because these stopped being where the cost sits, not because they stopped mattering.

Scarce 1 of 2

Deciding what is worth building

When you can build almost anything this week, choosing becomes the expensive act.

Scarce 2 of 2

Knowing whether it worked

Shipping is visible by default. Landing is only visible if somebody sets out to see it.

Both scarce items are judgment, which is the one thing no agent is allowed to own.
03The loopFive steps

People decide and judge. Agents build. Five steps, repeating.

This is the whole operating model. It is not a methodology and it does not need a rollout. It needs one owner per step and the discipline to finish step five before starting step one again.

  1. 01Person

    Decide what is worth building

    A named person picks the bet and writes down what would make it a win.

  2. 02Agents

    Read everything that touches it

    Tickets, calls, deploys, and past attempts, pulled together in minutes.

  3. 03Agents

    Draft it, build it, check it

    Options written, code produced, rules and edge cases tested against.

  4. 04Person

    Approve it or send it back

    One owner signs off on business fit, design quality, and technical fit.

  5. 05Person

    Judge whether it landed

    Read the same way every time, so the answer means the same thing twice.

  6. Then step 01 again

    What you learn in step 05 is the only honest input to the next decision. Skip it and you are guessing, faster.

Three of the five steps have a person's name on them, and they are the first, the fourth, and the last.
04The boundaryOne name per call

Agents never decide. Every call has one owner with a name.

Agents are extremely good at producing defensible-looking work, which is exactly why the line has to be drawn explicitly. A recommendation is not a decision until a person puts their name on it.

Person
  • Business fit
  • Design quality
  • Technical fit
  • Final approval

Judgment. Never delegated, never automated.

The call
Agents
  • Read the context
  • Draft the options
  • Check the rules
  • Propose the next move

Volume. Fast, tireless, and never the owner.

Everything left of the rule has a name attached to it.

ThroughlineProdOps backlogIllustrative
Ranked by propensity to improveDrafted by the engine

Ordered by expected effect on how the team works, not by age or by who asked. Each one arrives already dry-run against real history, so the decision is a yes or a no rather than a research project.

  1. 01

    Require an outcome line in every changelog entry

    Propensity
    0.86
    What it changes

    Adds one required field to the release template and blocks publish when it is empty.

    Dry run

    Replayed against the last 90 entries. 79 would have passed untouched; 11 needed a single sentence.

    Awaiting DarrenLog decisionPush to Linear
  2. 02

    Kill the Thursday portfolio review, replace it with a written read

    Propensity
    0.71
    What it changes

    Removes a recurring twelve-person meeting and adds one written read due Wednesday.

    Dry run

    Six of the last eight sessions produced no recorded decision. Those six become the written read.

    Awaiting DarrenLog decisionPush to Linear
  3. 03

    Move the notification centre to Stalled and free the two engineers

    Propensity
    0.64
    What it changes

    Reclassifies one initiative and returns its headcount to the next cycle.

    Dry run

    Live for two quarters with no measurable change in any account. Nothing downstream depends on it.

    Awaiting DarrenLog decisionPush to Linear

The engine wrote, scoped, and dry-ran all three before anyone opened this screen. It cannot approve one, and that is the whole design.Illustrative

Three items, three minutes. The expensive part was never writing the ticket — it was deciding which ticket deserved to exist.
05The evidenceTwelve tools, one read

The work lives in a dozen tools. The answers live on one screen.

Nobody is going to consolidate their stack, and they should not have to. What has to be consolidated is the reading: one place where the same three questions get asked of every launch.

Twelve sources, one answerIllustrative
  • Tickets
  • Deploys
  • Analytics
  • Support
  • Calls
  • Billing
  • Docs
  • Experiments
  • Reviews
  • Surveys
  • Incidents
  • Roadmap
One screen
  • Did it land
  • Who owns the call
  • What to do next

Same three questions every week, asked the same way.

The tools are not the problem. Reading twelve of them twelve different ways is.
ThroughlineSourcesIllustrative
Connected sources
  • ChangelogPublic release notesFresh · 12m ago

    What actually shipped, when, and whether the entry names a customer outcome or only a mechanism

    • entries
    • ship_date
    • outcome_class
  • Docs & pricingPublic product surfaceFresh · 1h ago

    How many surfaces exist to learn, and which ones changed shape between releases

    • surface_count
    • pricing_change
  • Job postingsPublic org signalFresh · 6h ago

    Where headcount is actually being pointed, which is the most honest statement of priority a company publishes

    • role_mix
    • org_signal
  • Investor commentaryPublic earnings recordStale · 3d ago

    What leadership said the priorities were, in their own words, on the record

    • stated_priority
What the wiring emitsDerived, not stored
  • What they decided to buildentries grouped by surface + stated_priority
  • Which bets show they landedoutcome_class over trailing 2 quarters
  • Where effort and outcome splitrole_mix vs outcome_class by surface
  • What the next call probably isranked by gap x reversibility

Nothing is inferred from a source that is not listed here. When one goes stale it is marked, and the reads that lean on it inherit the mark rather than being quietly served as current.Illustrative

Four public sources, nine fields, four answers. The system is small on purpose: every field has to earn its place by feeding an answer.
06The changeCount what landed

Stop counting what shipped. Count what landed.

Effort is easy to count, so it becomes the report. Outcome is harder to count, so it becomes an anecdote. Swap which one you count and the conversation changes inside a week.

Landed, watch, or stalled. Three words, applied to everything, including the work you personally championed.

Last quarter, read one wayIllustrative
2
Landedchanged behaviour
2
Watchnot readable yet
2
Stalledno change, still funded
  • Onboarding revamp14 itemsNew teams reach their first invite in a day, not a weekLanded
  • Billing self-serve9 itemsPlan changes stopped arriving as support ticketsLanded
  • Search rebuild22 itemsUsed more, abandoned at the same rate. Two more weeks of readingWatch
  • Mobile parity31 itemsShipped in full. Nobody has changed what they do yetWatch
  • Notification centre18 itemsLive for a quarter. No measurable change in any accountStalled
  • Workspace roles12 itemsBuilt for an objection that no buyer actually raisedStalled
Every one of these shipped on time. Shipping was never the question.
ThroughlineDid it landIllustrative
Shipped, not landed

Illustrative model of Vercel, built from public information.GET /api/v1/landed

Both of these shipped. The verdict is about whether behaviour moved, which is a different question and the only one that pays.

  • Lift new-user activation

    activation rate
    Watch
    Baseline47%
    Target60%
    Landing read fromauthored

    The onboarding revamp is working: activation has climbed to 54% from 47% and is trending toward the 60% bar. The top growth lever, and it is moving in the right direction.

  • Keep spend predictable as agent usage scales

    Predictable spend
    Watch
    Baseline62%
    Target90%
    Landing read fromauthored

    Cost per agent workload is the lever; surprise usage bills are the failure mode.

Illustrative model of Vercel, built from public information. The same deterministic engine the web read uses (deriveLanding over the operating model). No model invents a number. Numbers are derived, not asserted.

A working console, password gated. Opened on request.
Baseline and target are what the engine states. Neither row carries a structured current value, so neither gets a bar — the note says where it stands, in the engine's words.All rows read from: authored
07What this isThesis and system

A working thesis on human-and-agent teams, and the system that runs it.

The argument and the instrument are the same project. One of them is written down and one of them is running, and each keeps the other honest.

The thesis

A working argument, not a finished one

Twenty pages on what changes when building is cheap and judgment is not. Written to be disagreed with.

The system

The same argument, running on a real company

Throughline asks the four board questions against one company’s public record, the same way every week.

08The cost of not doing itSpend against landed

The alternative is guessing faster.

Agent tooling makes a team quicker at producing work. On its own it makes them quicker at producing the wrong work, and the spend line keeps climbing either way.

Spend against landed

The two lines used to move together. They stopped.

Illustrative
Spend on agent toolingLaunches that changed behaviour
The gap is the problem
The shape I keep seeing: spend on agent tooling against the share of launches that changed behaviour.
One next step

Now watch it run on a real company.

Throughline points this operating model at one company's public record and asks the four questions a board asks. The console itself is password gated, and the homepage beat shows exactly what it produces.

See ThroughlineNothing to buy, no account to create