[Strategy] Focus bet — 10 external users on ONE runtime agent before expanding

[serge-ivo]

[Strategy] Focus bet — 10 external users on ONE runtime agent before expanding

The data is unambiguous: 0 external users, $0.86 lifetime AI spend, and real usage on exactly one agent (Coder — the operator building the platform). The platform is all supply, no demand. Best-practice now is subtraction + focus, not more surface.

The bet

Pick one runtime-connected agent — the differentiated, defensible kind — and get 10 external users actually using it (not the operator).

• Candidates by signal: Coder (only agent with real usage) or Job Application Assistant (the browser flow that "actually worked").
• The ~18 commodity cloud chatbots have zero usage — the market of one already voted for the local-runtime agents.

Do

• Choose the single wedge agent + write down the ICP (who, what pain).
• Define the success metric (e.g. 10 non-operator users, ≥3 return in week 2) and a kill/park criterion for everything else.
• Everything not serving the wedge gets parked (unpublished / deprioritized), including the browser-generalization and open-creation epics — those unblock only if the wedge shows demand.

Acceptance

• One wedge agent chosen, ICP + metric + kill-criterion written.
• A parked list (agents + roadmap items deferred until the wedge validates).
• A way to see external (non-operator) usage in the admin portal.

This is the parent lens for the catalog audit and gates the browser epics below.

[serge-ivo]

The numbers in this issue are now stale, and one of them by ~47×. Flagging before anyone acts on #250, which asks for two-thirds of the board to be relabelled on this evidence.

Measured today against the live API (operator account, /v1/usage):

this issue says	actual
$0.86 lifetime AI spend	$40.44
real usage on exactly one agent	12 agents with ≥20 calls; 2702 calls total

Top by calls: Coder 739 · Repo Coder 367 · Coder Lead 152 · Facebook Friends 117 · Lead Outreach 66 · Lead Finder 45 · tmux Operator 20.

"0 external users" still looks true — I queried with the operator's own token, so all of the above is one account. So the strategic conclusion (all supply, no demand) may well stand. But two of the three facts it rests on don't, and the third isn't what changed.

What the new data actually says is more interesting than "one agent": the operator now runs a multi-agent workflow in daily use — a Coder/Repo Coder/Coder Lead hierarchy plus a lead-gen chain. That is different evidence for choosing a wedge than "Coder is the only thing with usage", and it argues for the hierarchy being the differentiated product rather than any single agent.

Two things worth doing here regardless of the direction chosen:

1. Refresh the numbers in this issue — it is cited as the parent lens for the catalog audit and gates the browser epics, so stale figures propagate.
2. The acceptance criterion "a way to see external (non-operator) usage" is the one that would settle this. /v1/usage is per-account; nothing distinguishes operator from external in aggregate. Until that exists, "0 external users" is an assumption, not a measurement.

[serge-ivo]

Measurement landed; the UI for it is #269.

GET /v1/admin/usage/external now answers this bet's metric directly (operator-vs-external split, per agent, with an explicit operatorUnknown state so it can never report a falsely encouraging number). First real call, 30 days:

EXTERNAL users: 0  |  calls: 0
OPERATOR  users: 1  |  calls: 2782  |  $40.92 (estimated)

Two corrections to the framing in this issue:

1. The "$0.86 lifetime spend" figure here is badly stale — measured spend is $40.92 over 30 days, ~47×. It should not be cited as evidence for anything.
2. Even $40.92 is a floor. It excludes the Coder Engine's own token spend entirely (Coding Engine spend is invisible in the usage ledger — the largest real cost isn't recorded #267) and over-prices cached tokens (Cache-read tokens are priced at the full input rate — overstates cost ~10x on the cached path #268). So the platform is more used than this issue assumes, and the usage is entirely the operator, which is the actual finding: the bet is unmet, and now falsifiable rather than assumed.