[Catalog] Audit every published agent — keep / fix / unpublish

[serge-ivo]

[Catalog] Audit every published agent — keep / fix / unpublish

Tracking issue for a data-driven catalog cleanup. A live pull (2026-08-01) showed 22 published agents, all first-party (creator: operator), 0 external creators, 0 external users, lifetime AI spend $0.86 / 69 calls over 4 days, with real usage concentrated on one agent (Coder, 47 calls — the operator dogfooding). The catalog also contains smoke-test fixtures and agents whose descriptions promise capabilities they don't have.

Do

Produce a table for every published agent: slug · subscribers · 30d calls · store_type · declared capabilities (surfaces/runtime/workflow) · description-matches-capabilities? · verdict. Verdicts: keep (works + used), fix (works, needs description/cleanup), unpublish (test/dupe/vaporware).

Known findings to action (children)

• Smoke tests in the live store → unpublish (#c2)
• Description ≠ capability (Creator OS, QA Automation, job-application-assistant) → fix + add lint (#c3)
• Duplicate/dogfood agents + instances → collapse (#c4)

Acceptance

• One audit doc/table covering all published agents with the columns above.
• Every agent has a keep/fix/unpublish decision.
• The three child issues are filed and linked.

Evidence: GET /v1/admin/agents + list_agents + usage_summary (2026-08-01).

Children

• [Catalog] Unpublish smoke-test agents from the live store #65 Unpublish smoke tests
• [Catalog] Fix description-vs-capability integrity + add a claims lint #66 Description-vs-capability + lint
• [Catalog] Collapse duplicate + dogfood agents and instances #67 Collapse dupes/dogfood

[serge-ivo]

Catalog audit — complete. Public catalog 29 → 13.

Live pull 2026-08-06 (GET /v1/agents, /v1/admin/agents, /v1/admin/instances, GET /v1/usage?days=30). Every agent in the store is first-party; coder is owned by the proagentstore seed account, all 37 others by the operator. Still 0 external creators; the only non-operator instance rows are the operator's own second identities (sivochkin@gmail.com, GitHub serge-ivo).

The bar applied: would a first-time visitor think this is a real product? An agent stays if it has a real description, a capability that actually exists, and a plausible use case.

KEEP — 13

slug	subs	30d calls	store_type	declared capabilities	desc ≈ caps?	why it stays
coder	2	739	agent	(seeded flagship)	yes	The flagship. All real usage concentrates here.
coder-repo	4	291	agent	surfaces:[coding] runtime:coding workflow:CODING_SESSION + 6 tools	yes	Most-subscribed agent; 4 live instances.
coder-lead	1	65	agent	6 delegation/github tools	yes	Real cross-repo supervisor, in use.
facebook-friend-confirmer	1	117	agent	runtime:browser workflow:BROWSER_TASK	yes	Real browser workflow, real usage.
small-business-website-lead-finder	1	45	agent	— (standalone worker repo)	yes	Real usage; first link of the lead chain.
lead-outreach-tj6qrr	1	66 (pipeline)	agent	instance pipelines	yes	Real pipeline usage; second link of the chain. Slug flagged below.
tmux-operator	1	20	agent	surfaces:[tmux] runtime:coding + 6 terminal_* tools	yes	Canonical terminal agent — see the dedup note.
local-repo-chat	1	4	agent	runtime:coding + 4 repo_* tools	yes	Complete, declared, distinct from repo-chat (local checkout vs GitHub).
repo-chat	1	1	agent	surfaces:[repo] + 3 declared tools	yes	The reference "built the creator way" agent (migration 0050).
doc-chat	1	1	agent	base chat + files + RAG	yes	Works on platform primitives; one instance holds 4 files / 5 vectors / 25 messages.
language-buddy	1	0	agent	settingsSchema (migration 0041)	yes	Complete product; the seeded settingsSchema + voice-language reference.
job-application-assistant	2	0	agent	surfaces:[apply] runtime:browser workflow:JOB_APPLY	no — see #66	Real pipeline. Description leaks internal vocabulary.
site-builder	0	0	agent	2 pipelines + settingsSchema (migration 0057)	yes	Newest first-party agent, fully declarative. 0 subs because it's new, not because it's fake.

UNPUBLISH → draft — 16 (done, nothing deleted)

Every one is now visibility:"draft". Drafting only gates POST /v1/instances/:agentId/subscribe; existing instances, chat and runs are untouched (verified — no other route reads agents.visibility). Fully reversible, and the rows survive, which matters because migrations 0033/0059/0072 use SELECT owner_id FROM agents WHERE slug='data-analyst' as their operator-account anchor.

Self-declared test fixtures (3) — the description literally begins "Test agent for…". Published 2026-08-05, before the #65 guard; the guard's whole-word test marker catches all three, so they cannot come back accidentally.

• terminal-operator, iterm-operator, kitty-operator

Vaporware — config is {}, worker_name null, cron_schedule null, 0 instances, 0 usage (11). Each description promises a capability that does not exist anywhere in the platform for that agent:

• site-monitor — "every hour… webhook alerts": no cron, no webhook
• competitor-intel — "daily": no cron
• seo-auditor — "daily crawl": no cron
• content-pipeline — "daily": no cron
• support-escalator — "daily summary": no cron
• lead-qualifier — "receives leads via webhook": no webhook
• invoice-parser — store_type:tool, "POST invoice text": no endpoint, no worker
• data-analyst — "generates SQL, runs queries": no such capability
• email-drafter — no capability at all
• chatbot — lowercase generic name, scaffold description
• qa-automation — 0 instances, 0 usage, empty config, and it advertises ProAppStore apps, a sibling store, in the PAGS catalog

Vaporware with a dogfood instance (2) — drafted, instance left running:

• creator-os-agent — promises "scheduled news scans… per-platform rate limits with a retry queue… publishing through your own accounts"; config:{}, no runtime, no workflow, no cron, no connectors. 1 instance (23 msgs, 8 KB docs), 0 30d usage. Also has a creator-os twin already sitting in draft.
• meeting-notes — "Webhook receives transcripts… Daily digest cron"; none of it exists. Its 1 instance belongs to sivochkin@gmail.com — see the question below.

FIX (not unpublish) — for #66

• job-application-assistant — "Rented job application assistant… uses the approved local browser runner task job.apply_basic for basic resume-upload forms." That is internal task-type vocabulary on the storefront, and "Rented" reads as a placeholder. The agent works; the copy doesn't.

Prevention — shipped (cec87d8)

POST /v1/batch/bulk-visibility bypassed the #65 guard entirely — it was only wired onto PUT /v1/agents/:id, so anything the single-agent route refused could still be published in bulk from the same session. That is precisely how this cleanup would have undone itself. Now guarded per agent and refused as a batch, with the same allowTestAgent override; un-publishing is never blocked. 6 tests in workers/api/src/routes/batch.test.ts.

No further lint proposed: the #65 guard covers the fixture class, and lintAgentClaims (#66) already covers the description-vs-capability class.

Questions for the owner — NOT acted on

1. The four terminal operators. I kept tmux-operator (real product description, seeded by migration 0072, most usage) and drafted the three whose descriptions say "Test agent for the … backend". But the tools are the generic terminal_* set covering tmux/kitty/iTerm2, so the surviving agent is arguably mis-named — "Terminal Operator" with the generic copy is the better storefront entry. Renaming it means diverging from migration 0072's seed. Your call.
2. lead-outreach-tj6qrr. Genuine agent, scaffolded slug. PUT /v1/agents/:id does not accept slug, so renaming needs a migration — and it breaks the public URL /agents/lead-outreach-tj6qrr/. Left published as-is.
3. meeting-notes. Drafted as vaporware, but its one instance belongs to sivochkin@gmail.com. If that is not you, someone outside the operator account has a subscription to an agent that does nothing — worth a look either way.
4. site-builder at 0 subscribers. Kept on merit (newest, fully declarative, migration-seeded). Flagging it because it is the only survivor with no usage at all.

All three acceptance boxes are met: the table covers all 29 formerly-published agents, every one has a keep/fix/unpublish decision with a reason, and #65/#66/#67 are filed and linked. Leaving this tracking issue open — it's the parent of #66 (still open) and #67 (awaiting your ruling on the instance sets), and of the four questions above.

[serge-ivo]

Re-audit 2026-08-06 (later same day) — the audit above is done; here is what it got wrong

I did not redo the table above. I verified it against live state and re-ran the guard/lint over the catalog as it stands right now. The cleanup landed and mostly holds — but it introduced a live storefront regression, missed a newly-published agent, and its usage evidence is stale.

Evidence: GET https://api.proagentstore.online/v1/agents (14 rows), my_agents (38 rows), usage_summary(range:"all"), agent_analytics, vector_stats, and blockPublishReason/lintAgentClaims run over every published row.

---

1. The cleanup broke the storefront filters — 5 of 9 buttons now tell visitors the store is empty

This is the highest-value finding, and it is a direct consequence of drafting 16 agents.

store/index.html filters on an exact string match and falls through to the empty state:

if (currentType !== 'all') filtered = filtered.filter(a => (a.store_type || 'agent') === currentType);
if (currentCategory !== 'all') filtered = filtered.filter(a => a.category === currentCategory);
...
if (filtered.length === 0) { empty.style.display = ''; return; }

…and that empty state reads “Be the first to publish — No agents published yet.”

Live right now, against the 14 published agents:

filter button	published agents matched
Category → Chat	0
Category → Data	0
Category → Creative	0
Type → Workers	0
Type → Tools	0

Every chat/data/creative agent was one of the commodity rows drafted in this cleanup, so those three buttons went dead the moment it landed. Workers/Tools match 0 because all 14 published rows are store_type:'agent'.

So the first visitor this catalog was cleaned up for can click 5 of the 9 filter buttons and be told the store has nothing in it — and invited to be the first to publish — on a store with 14 agents. That is exactly the "don't embarrass the platform" failure the audit was for.

2. 9 of the 14 published agents are unreachable by any category filter

Same exact-match filter, against categories the hardcoded button row doesn't offer:

category	has a button?	agents
code	yes	coder-repo, coder-lead, coder
productivity	yes	doc-chat, job-application-assistant
developer-tools	no	repo-chat, local-repo-chat, mcp-client
Sales	no	site-builder, small-business-website-lead-finder
coding	no	tmux-operator
social	no	facebook-friend-confirmer
education	no	language-buddy
general	no	lead-outreach-tj6qrr

There are three different category vocabularies in the codebase and no shared constant:

• the store's filter row — 5 values (store/index.html)
• the creator-facing picker — 6 values, ["general","chat","code","data","creative","productivity"] (store/console/src/pages/AgentDetail.tsx:11) — note it offers general, which the store cannot filter
• the catalog as it actually exists — 8 values, 5 of which appear in neither list

Applied (migration 0084, pushed — the only change I made): the two that were genuinely wrong data rather than missing buttons.

• coding → code. Same concept, two spellings; code is what the store button, the console picker and the other three coding agents use. tmux-operator was the one coding agent missing from the "Code" filter purely because of the spelling.
• Sales → sales. The table's only capitalized category.

I deliberately did not re-label developer-tools / education / social / general. Those are good data; the button row is the bug, and degrading accurate categories to fit a stale hardcoded list would hide it.

Safety checked before writing it: category feeds only the storefront chip/filter and the fallback capability derivation in lib/agent-capabilities.ts:477, which is short-circuited (line 459) for any agent declaring a capabilities.surfaces array. tmux-operator declares surfaces:["tmux"], so its resolved capabilities are unchanged. The fallback's category rules are code and insurance; neither Sales nor sales matches, so the Sales agents are unaffected.

Recommended, not applied — store/index.html is outside the files I was scoped to: derive the category buttons from the loaded agents and hide any type/category button matching zero. ~10 lines, and it fixes both tables above permanently and makes every future catalog cleanup self-correcting instead of silently emptying the storefront. Worth doing before any external visitor arrives.

3. mcp-client is published and is not in the audit table

Created 2026-08-06 02:50, after the table above was written. Published, 2 subscribers, 16 calls. The KEEP table has 13 rows; the live catalog has 14. Verdict in the table below.

4. job-application-assistant is published and the #65 guard would block it today

I ran blockPublishReason over all 14 published agents. Exactly one hit, and it's the flagship apply agent:

description contains “Runs a safe fill-only test by default” → whole-word test marker

It survives only because it is already published — the guard fires on nextVisibility === 'published', and nothing has sent that since. Any attempt to re-publish it (after a draft, or via /v1/batch/bulk-visibility) now 400s without allowTestAgent:true.

This is a guard false positive, and it collapses neatly into the #66 copy fix already wanted for this same agent: rewriting “Runs a safe fill-only test by default and stops before Submit” as e.g. “Does a safe fill-only dry run by default and stops before Submit” removes the internal vocabulary and clears the guard in one edit. I did not touch published copy — owner's call.

lintAgentClaims over all 14 published: 0 violations.

5. The usage evidence in the issue body is stale by ~50×

#64 says “$0.86 / 69 calls over 4 days”, concentrated on one agent. Live usage_summary(range:"all"):

2,862 calls · ~$42.30 estimated · 20 subscriptions across 14 agents.

And it is no longer one agent — 11 of 14 have real usage:

agent	calls	est. cost
coder	739	$17.19
coder-repo	403	$7.74
coder-lead	174	$3.02
facebook-friend-confirmer	117	$3.43
lead-outreach-tj6qrr	111	$0.22
small-business-website-lead-finder	48	$1.47
tmux-operator	20	$0.20
mcp-client	16	$0.20
local-repo-chat	4	$0.05
repo-chat	1	$0.02
doc-chat	1	$0.02
language-buddy · job-application-assistant · site-builder	0	—

Still all the owner's own traffic — 0 external users — so the shop-window framing stands. But #67's premise that “the real functioning catalog is ~4–5 agents” no longer holds.

---

Verdict on the 14 published agents as of now

slug	subs	calls	category	icon	verdict
coder	2	739	code	💻	keep
coder-repo	5	403	code	⌨️	keep
coder-lead	1	174	code	🧭	keep
tmux-operator	1	20	coding → code	—	keep (category fixed in 0084; needs an icon)
local-repo-chat	1	4	developer-tools	📖	keep
repo-chat	1	1	developer-tools	🔍	keep
site-builder	0	0	sales	🏗️	keep — newest, fully declarative reference
doc-chat	1	1	productivity	—	keep (needs an icon)
language-buddy	1	0	education	—	keep (needs an icon)
small-business-website-lead-finder	1	48	sales	—	keep (needs an icon)
mcp-client	2	16	developer-tools	—	fix — unaudited; storefront copy is internal jargon (“the private instance”, “the MCP key slot”, “consent-gated MCP connector”); no icon
lead-outreach-tj6qrr	1	111	general	—	fix — scaffold slug in the public URL, scaffold category, no icon
job-application-assistant	2	0	productivity	—	fix — trips the #65 guard (§4) + the #66 copy issue; same one-line edit clears both
facebook-friend-confirmer	1	117	social	—	unpublish → draft (recommended) — see below

The one unpublish I'd add: facebook-friend-confirmer

The audit above kept it on usage alone (117 calls). Usage is the wrong test here — it's all the owner's own dogfooding, and the question this catalog has to answer is what a first visitor thinks.

It is a published, public storefront listing for an agent that automates a logged-in Facebook account — confirming friend requests and “optionally adds a few suggested friends” by driving the owner's real browser session. That is against Meta's platform terms, and it is the only social agent in the store. For a marketplace that wants to open to third-party creators, having that as a public catalog entry is a standing reputational and ToS exposure that no amount of dogfood traffic justifies.

Recommendation: set visibility:"draft". As this issue already established, drafting only gates POST /v1/instances/:agentId/subscribe — the owner's existing instance, its chats and its browser runs keep working untouched. Fully reversible. Not applied: unpublishing a working agent is the owner's call, not mine.

Cosmetic, but it is the first impression: 8 of 14 cards are the same tile

store/index.html renders const icon = a.icon || '⚡' on iconBg = a.icon_bg || '#7c3aed'. Eight published agents have icon:"", so a majority of the storefront grid is the identical purple ⚡ tile: mcp-client, tmux-operator, lead-outreach, facebook-friend-confirmer, small-business-website-lead-finder, doc-chat, language-buddy, job-application-assistant.

Cheap and reversible (PUT /v1/agents/:id {icon}), but it's eight aesthetic choices on the owner's live catalog, so I've listed it rather than picked emoji.

---

What I changed vs. recommended

Changed — 1 commit (fix(catalog): spell two categories the way the storefront filters them, migration 0084_normalize_catalog_categories.sql): two narrow, idempotent UPDATEs. No schema change, no capability change, no visibility change, nothing deleted. pnpm typecheck clean, 3713/3713 tests pass, biome unaffected (SQL is not linted; the 30 pre-existing errors are on main already).

Recommended, not applied: the storefront filter fix (§1–2), facebook-friend-confirmer → draft, the job-application-assistant copy edit (§4, also closes #66's item), the 8 missing icons, and lead-outreach-tj6qrr's slug/category.

Was the ticket still accurate? Partly. Its ask was already satisfied earlier today. Its evidence is stale by ~50× on spend and wrong on the “one agent has all the usage” premise. And its acceptance criteria are met only if you don't count mcp-client, which was published after the table was written — which is itself the argument for the derived-filter fix: a hand-maintained snapshot of a live catalog is stale the same day.

[serge-ivo]

Third audit pass — 2026-08-08. Catalog is 15 published. Read-only; I changed nothing.

Two audits already ran on 2026-08-06. This pass re-verifies both against live state, and it finds one class of defect neither of them looked for: an agent that works for its owner and is dead on arrival for anyone who subscribes to it. Two published agents are in that state.

All access through the configured MCP server per AGENTS.md — list_agents, my_agents, my_instances, agent_analytics, usage_summary(range:"all"), list_pipeline_runs, list_connections, list_errors. No REST, no DB, no writes. Repo cross-reference against main @ db8a2af.

What moved since 2026-08-06

• portal-watch is new and published (seeded migration 0087, created 2026-08-06 19:41). Neither prior table has it. 15 published, not 14.
• The storefront filter regression is fixed — b0d5486 replaced the hardcoded button rows with renderFilters() counting store_type/category off the live catalog. That was §1 of the second audit and it is closed. (I could not confirm the deployed HTML: https://proagentstore.online/ returns 403 to my fetch. The fix is in main's history and host deploys on push, so I am reporting it as fixed in source, not verified in production.)
• Nothing else recommended on 2026-08-06 was actioned. job-application-assistant still trips the guard, facebook-friend-confirmer is still published, the same 8 cards still have no icon, lead-outreach-tj6qrr still has its scaffold slug.
• Instances 25 → 27 active; subscriptions 21 across 15 published agents (+6 instances on drafted agents).

---

The three findings that matter

1. Two published agents hand a new subscriber an empty chat box

POST /:agentId/subscribe copies agents.config.pipelines into the new instance — defaultPipelinesFor() in workers/api/src/routes/instances.ts:71, and the comment there states the reason exactly:

For an agent whose whole behaviour IS its pipelines, those have to arrive with the subscription — loadPipeline reads the INSTANCE config, so without this a fresh subscriber gets an agent that can do nothing until they attach each pipeline by hand.

That is precisely the state of two published agents:

agent	agents.config	where the working pipeline actually lives
small-business-website-lead-finder	{}	instance 933ebec5…, pipeline lead_finder — 45 leads from Launceston on 2026-08-04, verified via list_pipeline_runs
lead-outreach-tj6qrr	{}	instance 3c09069a…, pipeline draft_outreach — 5 completed runs fed by the lead.created connection

Both work. Both work only for the owner's own instance, because the behaviour was attached to the instance by hand and never promoted to the agent row. Anyone who subscribes from the storefront today gets a plain chat agent with base tools and no pipeline, no leads collection, and no way to do the thing the card promises. site-builder is the control case and does it right — its config carries pipelines, and migration 0057 embeds both definitions.

It is worse than an oversight for the lead finder specifically: workers/api/src/lib/pipelines/lead-finder.json exists in the repo, is the epic #94 capstone, and is proven end-to-end in lead-finder.test.ts against the real runner. Its own README says so:

None of it touched the running lead-finder agent; the lead-finder class is now buildable with zero bespoke code.

So the reference definition is written, tested and version-controlled, and the published catalog row it describes carries nothing. draft_outreach is worse still — there is no reference JSON for it anywhere in the repo, so the second link of the lead chain exists only as live instance data: untested, unversioned, and lost if that instance is ever cancelled.

Fix: seed both into agents.config.pipelines by migration, the way 0057 does for site-builder, and extend seed-drift.test.ts to cover them (today it pins site-builder only). Export draft_outreach from instance 3c09069a… to workers/api/src/lib/pipelines/lead-outreach.json first — that is the only copy.

2. lead_finder crashes on any city big enough to matter, and the failure is invisible from the storefront

list_errors (source pipeline-run), all on instance 933ebec5…:

2026-08-03 08:08 pipeline "lead_finder" crashed: WorkflowInternalError: Step s3-flatten-1 output is too large. Maximum allowed size is 1MiB.
2026-08-03 06:49 pipeline "lead_finder" crashed: WorkflowInternalError: Step s4-map-1 output is too large. Maximum allowed size is 1MiB.
2026-08-03 06:32 pipeline "lead-finder" crashed: WorkflowInternalError: Step s3-map-1 output is too large. Maximum allowed size is 1MiB.
2026-08-03 06:25 step 0 (geocode) failed: No geocode result for "Sydney, NSW".

Every subsequent successful run is a small one — Hobart and Launceston at radius: 900, 83–116 places seen. The crashing step names (s3-flatten-1, s4-map-1) match the reference lead-finder.json shape exactly — geocode → fan_out → http_request → flatten → map → enrich → map → filter → dedupe_upsert, index 3 being flatten and index 4 map. There is no slice anywhere in that chain, so the payload carried between steps grows with the city and hits Cloudflare's 1MiB Workflow step limit. The slice primitive that caps exactly this ("the missing top N: cap a list before a per-item connector call so a long source isn't unbounded spend") already exists and is not used. (I read the reference JSON, not the live instance's copy — no read-only MCP tool returns an instance's pipeline definition. The step names make them the same shape; I did not diff them byte for byte.)

This is the single agent in the catalog whose card names a general capability ("Search by city and business type") that demonstrably fails on the first city a visitor would try.

Fix: add slice after flatten in lead-finder.json, bounded by a subscriber setting, and seed it per finding 1.

3. The catalog's own answer to "is anyone looking at this?" is structurally unavailable

agent_analytics returns funnel: {views, trials, subscribes}. Across every agent I checked — coder (739 calls, 2 subs), coder-repo (6 subs), portal-watch, site-builder, meeting-notes — views and trials are 0 without exception, while subscribes is correct.

• trials is dead by construction: nothing in workers/api/src ever writes event = 'trial_start'. The public trial route /v1/public/agents/:id/try writes no usage row at all.
• views is written by GET /v1/public/agents/:id (routes/public.ts:33) — but it binds user_id = '' into a column declared user_id TEXT NOT NULL REFERENCES users(id) (0001_init.sql:58), inside a waitUntil(...).catch(() => {}). If D1 enforces the foreign key, every view insert fails and is swallowed.

store/agents/detail.html:465 tries the public route first for every visitor including the owner, so a genuine zero would mean nobody — not even the owner, mid-audit — has opened an agent page. I lean strongly toward the FK, but I could not prove it: confirming requires a direct D1 query, which AGENTS.md forbids and which no read-only MCP tool exposes.

Either way the operational conclusion is the same and it is the important one: this audit cannot tell you whether anyone browses the store, and neither can you. Every "is anyone using it" judgement below rests on subscriptions and token usage, both of which are the owner's own traffic.

---

Verdicts — 15 published agents

Guard + lint were run over all 15 by replicating blockPublishReason (lib/test-agent-guard.ts) and lintAgentClaims (lib/agent-claims-lint.ts) verbatim against each agent's live description and declared capabilities. Result: 1 guard hit, 0 lint violations.

slug	subs	calls (all-time)	declared capabilities	guard	lint	verdict
coder-repo	6	552	coding / CODING_SESSION + 7 tools + surfaceOptions + settingsSchema	ok	ok	KEEP
coder-lead	1	255	no surfaces, 6 delegation/github tools	ok	ok	KEEP
tmux-operator	2	75	surfaces:[tmux], runtime:coding, 6 terminal_* tools	ok	ok	KEEP
local-repo-chat	1	4	runtime:coding + 4 repo_* tools	ok	ok	KEEP
repo-chat	1	1	surfaces:[repo] + 3 declared tools	ok	ok	KEEP
doc-chat	1	1	none — platform primitives	ok	ok	KEEP
language-buddy	1	0	settingsSchema (migration 0041)	ok	ok	KEEP
portal-watch	0	0	runtime:browser / BROWSER_TASK + browserTask.readOnly + settingsSchema	ok	ok	KEEP
site-builder	0	0	2 seeded pipelines + settingsSchema (migration 0057)	ok	ok	KEEP
mcp-client	2	16	mcp_list_tools + mcp_call_tool + settingsSchema	ok	ok	FIX
small-business-website-lead-finder	1	48	{}	ok	ok	FIX
lead-outreach-tj6qrr	1	111	{}	ok	ok	FIX
job-application-assistant	2	0	surfaces:[apply] / browser / JOB_APPLY	blocked	ok	FIX
coder	2	739	coding / CODING_SESSION, no tool allowlist	ok	ok	UNPUBLISH → draft
facebook-friend-confirmer	1	117	runtime:browser / BROWSER_TASK, tools:[]	ok	ok	UNPUBLISH → draft

KEEP 9 · FIX 4 · UNPUBLISH 2.

The nine KEEPs, briefly

coder-repo is the catalog's best entry and the busiest: 6 instances, one per repo, exactly the shape its card describes, with the fullest declaration in the store (tools + surfaceOptions + a 4-field settingsSchema including the merge-authority control from 0091). coder-lead sits over it and is genuinely used. tmux-operator picked up a second subscriber since the last audit ("Heartfull (tmux)") and its category spelling was fixed in 0084; its config still carries nothing but capabilities — no identity, no welcome message — which is why it reads thinner on the card than it behaves.

repo-chat and local-repo-chat are the read-only pair and are correctly distinct (GitHub API vs. your own checkout over the runner); both declare their tools properly and repo-chat remains the "built the creator way" reference. doc-chat and language-buddy are low-traffic but honest: they promise only what platform primitives already deliver, and lintAgentClaims agrees.

portal-watch is the strongest new entry and deserves saying so. It is the only agent in the catalog whose card states its own limits ("It can only ever look: the runtime blocks every Pay, Submit, Send, Delete and Confirm before the click reaches the page"), and the claim is backed in config — browserTask: {readOnly: true} — not just in prose. It is the model for how the rest of these should read.

site-builder keeps its place on merit at 0 subscribers: fully declarative, seeded, drift-tested. But note the consequence — with no instance, the third link of the lead chain has never run. list_connections on the lead finder shows exactly one edge, lead.created → draft_outreach. The site.live wiring documented as the chain's payoff does not exist in live data because there is nothing to wire it to.

The four FIXes

job-application-assistant — this is the one the guard stops. Its description contains "Runs a safe fill-only test by default", which testAgentMarker matches as a whole word, so blockPublishReason returns a 400 for any attempt to re-publish it; it survives only because it is already published and nothing has sent visibility:"published" since. This is the same one-line edit #66 already wants — "Does a safe fill-only dry run by default and stops before Submit" removes the internal vocabulary and clears the guard. Two further things, both new here: it has 0 calls all-time across 2 subscribers, so the flagship apply pipeline has not been exercised once since usage tracking began on 2026-07-14; and its model column is @cf/meta/llama-3.3-70b-instruct-fp8-fast while every other published agent is claude-sonnet-4-6. The model is harmless in practice — it is in TOOL_CAPABLE_MODELS, and runAgentAi hardcodes claude-sonnet-4-6 whenever a BYOK Anthropic key exists — but it is visible on the public card and it makes the flagship look like the one agent running a small open model.

small-business-website-lead-finder and lead-outreach-tj6qrr — findings 1 and 2 above. Additionally lead-outreach-tj6qrr still carries its scaffold slug in the public URL and category: "general", the only agent in the catalog with either.

mcp-client — works (16 calls, mcp_list_tools/mcp_call_tool succeeding on instance dfc1cf92…), but the storefront copy is written for someone who already knows the platform: "Configure its Streamable HTTP endpoint on the private instance, store its bearer token under the MCP key slot … through ProAgentStore's consent-gated MCP connector." Three internal terms in one sentence. Nothing to fix in the capability; rewrite the card.

The two UNPUBLISHes

coder → draft. This is the six-overlapping-coding-agents problem, and the repo has already made the call in code. workers/api/src/lib/first-party-agents.ts names it LEGACY_CODER and comments: "The legacy hardcoded Coder: declares no tool allowlist, so it keeps the drive tools." coder-repo supersedes it on every axis — 6 subscribers to its 2, a declared tool allowlist, surfaceOptions, a real settingsSchema — and coder-lead supplies the multi-repo case coder was covering by accident. It is also the only agent in the store attributed to a different creator (proagentstore, with no avatar), so the flagship card is the one that looks least like it belongs to anyone.

Drafting gates POST /:agentId/subscribe and nothing else, so both existing instances ("Coder", "Coder Home", 739 calls between them) keep working untouched, and it is one field to reverse. What this buys is the thing the catalog is actually for: a visitor sees five coding agents instead of six, and the first one is the one you should start with.

facebook-friend-confirmer → draft. The second audit recommended this and it was not actioned, so I am re-entering it with the evidence rather than dropping it. It is a public catalog listing for an agent that drives a logged-in Facebook session to confirm friend requests and "optionally adds a few suggested friends" — against Meta's platform terms, and the only social entry in the store. Its 117 calls are entirely the owner's own dogfooding, which is not a usage argument for a shop window. Drafting costs the owner nothing: the instance, its chats and its browser runs are untouched.

Cosmetic, and it is still the first thing a visitor sees

store/index.html renders const icon = a.icon || '⚡' on iconBg = a.icon_bg || '#7c3aed'. 8 of 15 published agents have icon: "" — mcp-client, tmux-operator, lead-outreach-tj6qrr, facebook-friend-confirmer, small-business-website-lead-finder, doc-chat, language-buddy, job-application-assistant — so a clear majority of the grid is the identical purple ⚡ tile. Unchanged since 2026-08-06. Eight PUT /v1/agents/:id {icon} calls; I have not picked the emoji because it is the owner's catalog.

One dead field, worth knowing about

agents.status is returned in the public GET /v1/agents payload for every agent. It is written once — 'inactive' at INSERT, in both create paths (routes/agents.ts:331, :668) — and nothing ever updates it. The only rows reading active are the ones a seed migration wrote that way, which is why the split falls exactly along seeded-vs-API-created and not along anything meaningful: 8 published agents currently advertise status: "inactive" in the store's own API response, including job-application-assistant and tmux-operator. Nothing in store/ renders it today, so this is latent rather than broken — but it is a public field that means nothing, and the next thing to render it will render a lie.

---

Overlaps with #67 — actionable from this same evidence

27 active instances. Nothing recommended on 2026-08-06 was actioned, and one new near-duplicate has appeared.

instance	id	evidence	recommendation
ProAgentStore MCP client	a9ee6079…	1 call all-time (usage_summary). Sibling MCP client (dfc1cf92…) has 4 and is the live one. Its failed mcp_list_tools and empty content were established on 2026-08-06 above; I re-verified only that it still exists with 1 call.	cancel
Codex MCP Browser Test	7867ed7e…	Still active. Absent from usage_summary entirely — 0 calls all-time. Its self-describing marker content is quoted in the 2026-08-06 comment; I did not re-read it.	cancel
Google Drive Doc Chat Test	3d51aceb…	Same — still active, 0 calls all-time, contents established above.	cancel
Terminal Operator · iTerm2 Operator · kitty Operator	da39100b… · 8d21ea1a… · 59cc5144…	3 calls each, all-time, on agents bdae7a27… / d40dbdf6… / 01905f59…. Created, smoke-tested once, never used since. All three agents already drafted.	cancel all three (owner's call — loses 3 exchanges each)
Creator OS	b619b3da…	8 hand-authored knowledge docs (established 2026-08-06). Do not cancel — re-flagging because the agent's draft status makes it look disposable and it is not.	keep + export the docs
Coder + Coder Home	cd489be0… · 12ebf1f0…	Deliberate per-machine instances, ~50 msgs each. Unaffected by drafting the agent.	keep
Heartfull + Heartfull (tmux)	f8ddc272… (coder-repo) · cda75e28… (tmux-operator)	New since the last audit — the same repo now driven by two different agents. Not accidental duplication, but it is the accretion pattern this issue tracks.	owner's call
coder-repo × 6	FAS · FWS · FGS · Heartfull · PAS Coder · Chess coder	One per repo is the agent's intended shape. "Chess coder" is new.	keep all

Still unresolved from 2026-08-06: meeting-notes has subscribers: 1 and that instance is not among the owner's 27 — someone outside the operator account holds a subscription to a drafted config:{} agent, with 0 chats and 0 executions. I could not identify them: that needs /v1/admin/*, which is behind the Cloudflare Access edge and which AGENTS.md puts out of bounds. Not touched.

Also worth a separate issue: pump_test, a leftover test pipeline, is attached to the live lead-finder instance and appears in its run history (3 runs). Harmless, but it will be copied into every subscriber's instance the moment finding 1 is fixed by promoting that instance's pipelines wholesale. Promote lead_finder only.

---

Correction to the usage figures on this issue

usage_summary(range:"all") today: 3,347 calls, costMicros 889,238,209 — but only chargedCostMicros 3,771,185 (~$3.77) is money anyone was actually charged. The ~$889 headline is notional list-price arithmetic, and $842 of it is a single Claude Code engine (claude-opus-5[1m], 113.8M cache-read tokens, payer unknown) running on a subscription. The second audit's "$42.30 estimated" was the same notional figure before that engine's rows landed; quoting either as spend overstates it by two orders of magnitude. 11 of 15 published agents have real usage; all of it is still the owner's own.