[Catalog] Collapse duplicate + dogfood agents and instances

[serge-ivo]

[Catalog] Collapse duplicate + dogfood agents and instances

The "20+ agents" count is inflated by dupes and dogfood clutter; the real functioning catalog is ~4–5 agents.

Observed (live 2026-08-01)

• Duplicate instances: "Coder" + "Coder 2", "Doc Chat" + "Doc Chat 2" + "Fridges" (doc-chat renamed).
• Commodity cloud agents with 0 subscribers, 0 usage: data-analyst, seo-auditor, invoice-parser, email-drafter, site-monitor, lead-qualifier, content-pipeline, competitor-intel, support-escalator, chatbot, meeting-notes.

Do

• Merge/remove duplicate dogfood instances.
• Decide per zero-usage commodity agent: unpublish (recommended, per the focus posture) or keep as a reference example — but don't leave 10 unused agents padding the store.
• Keep the demonstrated-value agents visible (Coder, Repo Chat, Job-Apply, Doc Chat, Language Buddy).

Acceptance

• No duplicate dogfood instances remain.
• Every still-published agent has a stated reason to be there (used, or an intentional reference example).

Part of the catalog audit. Aligns with the focus bet.

[serge-ivo]

Duplicate + dogfood collapse — agents done, instances mostly owner-call.

Live state 2026-08-06. Full per-agent audit table is on #64.

Commodity zero-usage agents → all unpublished (11 + 2)

Every one named in this issue is now visibility:"draft". Verified against config (all {}), worker_name (null), cron_schedule (null), /v1/admin/agents instance counts (0) and GET /v1/usage?days=30 (0 calls):

data-analyst · seo-auditor · invoice-parser · email-drafter · site-monitor · lead-qualifier · content-pipeline · competitor-intel · support-escalator · chatbot · meeting-notes

Plus two this issue didn't list but that fail the same test — real description, no capability behind it:
qa-automation (also advertises ProAppStore, a sibling store, inside the PAGS catalog) and creator-os-agent.

None kept as a "reference example": the two agents that genuinely serve that purpose already exist and work — repo-chat (declared-tools reference, migration 0050) and site-builder (declarative-pipelines reference, migration 0057).

Nothing deleted; draft only gates POST /:agentId/subscribe, so the two with dogfood instances (creator-os-agent, meeting-notes) keep working for their subscriber. The rows also have to survive because migrations 0033/0059/0072 anchor on SELECT owner_id FROM agents WHERE slug='data-analyst'.

Public catalog: 29 → 13. Every survivor has a stated reason on #64.

Duplicate instances — the picture moved since 2026-08-01

"Coder 2" and the original "Doc Chat" are already gone. What's actually there now:

pair	verdict
doc-chat → "Fridges" + "Doc Chat 2"	"Doc Chat 2" cancelled. Provably empty: 0 messages, 0 files, 0 KB docs, 0 vectors, 0 usage. "Fridges" is the real one (25 msgs, 4 files, 5 vectors) and is canonical.
coder → "Coder" + "Coder Home"	Left alone — your call. Not a duplicate in the accidental sense: 50 messages each, 133 calls on "Coder Home", and they look like deliberate per-machine instances. Merging would lose one side's history.
coder-repo → "FAS platform" / "FWS platform" / "FGS platform" / "Heartfull"	Not duplicates. One instance per repo is the intended shape of that agent.
codex-mcp-browser-test-20260611 → "Codex MCP Browser Test"; google-drive-doc-chat-test → "Google Drive Doc Chat Test"	Left alone — your call. Both agents were drafted by #65 so they're out of the catalog, but each instance holds real content (6 msgs + 2 KB docs; 5 msgs + 1 KB doc + 1 vector). Cancelling loses nothing, but it's your dogfood data — say the word and I'll cancel both.
the 4 *-operator instances	Left alone. The three test agents are drafted; the instances are harmless and hold the connector-consent grants.

The reason duplicates accumulated — fixed (cec87d8)

POST /v1/instances/:id/cancel is the only non-destructive way to retire an instance, but GET /v1/instances/my/instances returned canceled rows anyway — no status filter. So a cancelled instance kept showing in the console nav, kept being offered to MCP's findInstanceForAgent, and kept being registered by pags up. Cancelling cancelled nothing you could see, which is exactly why the clutter built up rather than being cleaned as it appeared.

Now excluded by default, with ?includeCanceled=1 so a retired instance is never stranded (re-subscribing mints a new instance rather than reviving the old one, so the escape hatch matters). Tests in instances.integration.test.ts.

Side note found while doing this: /cancel flips agent_instances.status for the one instance but flips the subscriptions row for the whole (agent_id, user_id) pair — so cancelling one of two instances of the same agent staled the shared subscription row. Harmless today (nothing reads subscriptions; subscriber_count counts agent_instances), and re-subscribing flips it back, but it will bite if PAGS billing is ever switched on. Not fixed here — worth its own issue.

Acceptance

• No duplicate dogfood instances remain that are safe to remove — the one provably-empty duplicate is cancelled; the rest hold real content and are listed above for your decision.
• Every still-published agent has a stated reason to be there (table on [Catalog] Audit every published agent — keep / fix / unpublish #64).

Leaving this open until you rule on the four instance sets above (and on the terminal-operator naming question on #64).

[serge-ivo]

Re-audit 2026-08-06 (later same day) — instance-by-instance, with the data each one would lose

Verified against live my_instances (25 active), usage_summary(range:"all"), vector_stats, list_instance_knowledge, list_instance_files, instance_activity and list_instance_connector_grants. I changed nothing here — every item below is a recommendation, because all of it is either destructive or the owner's own data.

The agent half of this issue is genuinely done: all 13 commodity/vaporware agents are visibility:"draft", confirmed live. The instance half needs the detail below, and two of the prior conclusions are wrong.

---

Correction 1 — the two “holds real content, your call” fixtures hold the smoke test's own markers

The comment above left codex-mcp-browser-test-20260611 and google-drive-doc-chat-test alone because each “holds real content”. I read the content. It is the fixtures describing themselves:

Codex MCP Browser Test (7867ed7e…) — 0 vectors, 0 files, 2 KB docs:

“This is a live MCP instance-runtime smoke test. The private instance should retain this user-specific knowledge.”
“Private instance MCP persistence probe for codex-mcp-browser-test-20260611 … Marker: PAGS-MCP-RUNTIME-2026-06-11T09:59:51.264Z”

Google Drive Doc Chat Test (3d51aceb…) — 1 vector / 266 chars, 1 KB doc:

“Smoke test fact: the Google Drive Doc Chat Test instance was created through MCP on 2026-07-13.”

Also checked: list_instance_connector_grants(google_drive) on the Drive fixture returns grants: [] — it never held the Drive grant it was created to prove.

Verdict: cancel both. There is provably nothing to lose — the only content is a persistence marker whose purpose was to be read back once, in June and July respectively. Not applied (cancelling is destructive and it's your data), but this is as low-risk as it gets.

Correction 2 — the Creator OS instance is the opposite: it holds real authored work. Do not delete it.

The comment above lists creator-os-agent under “vaporware with a dogfood instance”. The agent is vaporware — fine, it's drafted. The instance (b619b3da…, “Creator OS”) holds 8 hand-written knowledge documents, 26 chunks, 8,681 chars, authored 2026-07-06. These are not scaffold text; they're a real operating manual:

• Owner voice and platform setup (Serge) — tone rules, per-platform setup
• Caption rules per platform · Always include URLs when suggesting content
• Content pipelines — the daily-scan/approval flow
• Rate limits and retry queue policy — “MAX 2 posting attempts per platform per post. NEVER a third…”
• Tool failure honesty — hard rule — “NEVER say something was ‘queued’, ‘saved’…”

Verdict: keep the instance. Flagging explicitly — cancelling it destroys authored content that exists nowhere else. Worth exporting the 8 docs regardless of what happens to the agent.

(Incidental: one of those docs points at https://creator-os-agent.proagentstore.online/suggestions. The agent row is config:{}, but something was at least intended to be deployed under that name — worth a look before writing the whole thing off as vaporware.)

---

Correction 3 — a new duplicate pair appeared after the audit was written

mcp-client was created 2026-08-06 02:50 and subscribed twice the same day. Neither is in the table above.

instance	id	evidence	verdict
“MCP client”	dfc1cf92…	8 activity events; mcp_list_tools + mcp_call_tool succeeding; the real one	keep
“ProAgentStore MCP client”	a9ee6079…	3 events total, its single mcp_list_tools failed, 0 KB docs, 0 files, 0 vectors	cancel (recommended)

This is the same accretion pattern the issue is about, recurring within hours of the cleanup — which is the argument for the ?includeCanceled fix above being necessary but not sufficient.

---

Full instance inventory — 25 active

group	count	verdict
coder-repo — FAS platform · FWS platform · FGS platform · Heartfull · PAS Coder	5	Keep all. One instance per repo is the agent's intended shape. Note this is 5 now, not the 4 in the table above — “PAS Coder” was added 2026-08-06.
coder — “Coder” + “Coder Home”	2	Keep — your call. ~50 msgs each, 133 calls on “Coder Home”; deliberate per-machine instances. Merging loses one side's history. See the product question below.
mcp-client — “MCP client” + “ProAgentStore MCP client”	2	Cancel a9ee6079… (empty, failed). Keep the other.
terminal operators — tmux · iTerm2 · kitty · Terminal	4	Your call. One agent four ways: identical 6 terminal_* tools; only tmux-operator is still published, the other 3 agents are drafted. Usage: tmux 20 calls, the other three 3 calls each — i.e. created, smoke-tested once, never used. Cancelling the 3 non-tmux instances loses 3 chat exchanges each and nothing else.
smoke fixtures — Codex MCP Browser Test · Google Drive Doc Chat Test	2	Cancel both (Correction 1).
Creator OS	1	Keep — do not delete (Correction 2).
singles — Coder Lead · Repo Chat · Cordouan Health · Fridges · Language Buddy · Job Application Assistant · Facebook Friends · Lead Outreach · Lead Finder	9	Keep all. One instance each, no duplication.

Net if you approve everything: 25 → 19 (or 25 → 16 including the three operator instances).

---

Owned by another account — reported, not touched

meeting-notes has 1 subscriber that is not you. Verified: agent_analytics("meeting-notes") → subscribers: 1, and the instance does not appear in your 25. So someone outside the operator account holds a subscription.

Two things worth knowing about it:

• It has 0 chats and 0 executions — the subscription has never been used.
• The agent is config:{} vaporware and is now drafted, so that subscriber holds a subscription to an agent that cannot do anything.

I could not confirm the sivochkin@gmail.com attribution independently — that requires /v1/admin/*, which is behind the Cloudflare Access edge and not reachable from here. I did not act on this instance in any way, and it should stay untouched until you confirm who owns it.

---

One product question this issue should probably absorb

coder (2 subs, 739 calls) and coder-repo (5 subs, 403 calls) are both published, both actively used, and coder-repo + coder-lead look like the intended successors to coder — coder-repo owns one repo and declares its capabilities properly, coder-lead supervises across repos, and coder-repo already has more subscribers. Meanwhile local-repo-chat and repo-chat split the read-only case the same way.

So the store currently shows a visitor six overlapping coding agents (coder, coder-repo, coder-lead, local-repo-chat, repo-chat, tmux-operator) with no signal about which one to start with. That's the real remaining “duplicate agents” problem — not the drafted commodity rows, which are already gone. It's a positioning decision, so it's yours; but it's the thing a first visitor to the catalog will actually trip over.

---

Was the ticket still accurate?

Mostly not. Its “Observed (live 2026-08-01)” list is superseded: “Coder 2” and “Doc Chat 2” are gone, all 11 named commodity agents are already drafted, and the premise that “the real functioning catalog is ~4–5 agents” is wrong — 11 of the 14 published agents now have real usage (usage_summary: 2,862 calls, ~$42.30, vs the $0.86/69 calls in #64's body).

Acceptance box 1 (“no duplicate dogfood instances remain”) cannot be ticked: a new mcp-client duplicate appeared hours after it was ticked. Acceptance box 2 is met — the per-agent reasons are on #64, refreshed there today.

Full per-agent verdicts, plus a live storefront regression this cleanup caused (5 of the 9 filter buttons now render “No agents published yet”), are in my companion comment on #64.

[serge-ivo]

Fourth pass — 2026-08-08, evening. A new duplicate appeared today, and this time the mechanism is fully evidenced.

Read-only. I cancelled nothing, renamed nothing, deleted nothing. Live: 28 active instances (was 27
in the third pass, 25 in the second). Evidence: MCP my_instances, usage_summary(range:"all"),
instance_messages, coding_repos_list, list_pipeline_runs, list_errors, plus one ls on the
owner's own disk.

The agent half of this issue has been done since 2026-08-06 and still holds: 13 commodity/vaporware
agents are visibility:"draft", verified live in my_agents (39 rows, 15 published). This comment is
about the instance half, which is the part that keeps regrowing.

---

1. The newest duplicate, and why it happened — Chess coder / Chess coder 2

Created three minutes and forty seconds apart, both on coder-repo, both named for the same repo:

	Chess coder	Chess coder 2
id	bfc76603-3616-4b03-8a9a-b0af35800a51	bd43f4de-ef35-4051-bdec-43f8571414a1
created	2026-08-08 03:54:34	2026-08-08 03:57:14
workdir	~/dev/stores/pas/**platform**/apps/chess-academy	~/dev/stores/pas/apps/chess-academy
cloneStatus	needs_attention	ready
githubRepo	—	proappstore-online/chess-academy (auto-detected)
messages	5 (03:55–03:56, then abandoned)	67 (03:57 → 06:37, still going)
calls, all-time	2	19

coding_repos_list on the first one carries its own diagnosis:

"cloneError": "The configured checkout /Users/serge-ivo/dev/stores/pas/platform/apps/chess-academy does not exist on the connected machine — it may have been moved, renamed or deleted."

Confirmed independently on disk: ~/dev/stores/pas/platform/apps/chess-academy does not exist;
~/dev/stores/pas/apps/chess-academy does.

So this is not accretion by carelessness. It is a typo in a path, and the recovery the product made
easiest was "subscribe again". That matters because coder-repo declares
surfaceOptions.coding.repos: "single" — one repo per instance — so a wrong path makes the whole
instance feel wrong, and a new instance feels like the fix.

The repair path does exist and is one field: updateRepo accepts workdir
(lib/coding-store.ts:181-225) and the console exposes it as "Folder on your machine" in
RepoSettingsModal.tsx:126-129. The repo row also already knows it is broken —
repo-status.ts:93 renders the state as "Path unusable". The two facts just never meet: the row
says the path is unusable and does not offer the modal that fixes it.

Worth its own small ticket, and it is the cheapest thing on this issue: when
cloneStatus === "needs_attention", make the "Path unusable" chip open RepoSettingsModal with the
cloneError shown above the folder field. That converts a re-subscribe into a two-second edit, and
it attacks the source of the clutter this issue keeps cleaning up rather than the clutter.

Verdicts: cancel bfc76603… (5 messages, all from the 90 seconds before it was abandoned; its
one repo row points at a path that does not exist). Keep bd43f4de… and rename it to "Chess
coder" — PUT /v1/instances/:id/name, non-destructive.

2. The coder pair: do NOT merge. The question is answerable now.

This has been "your call" on this issue since 2026-08-06 with no evidence attached. There is evidence
now, and it points one way.

	Coder cd489be0…	Coder Home 12ebf1f0…
created	2026-06-26	2026-07-15
repos	6	7
messages	95	100+ (page cap)
last message	2026-07-08	2026-08-03
calls, all-time	— (agent-scoped)	133

Repos, from coding_repos_list:

• cd489be0… — fms/platform · fgs/platform · fdocs/platform · pags/platform · apps/coffeerating · proappstore-online/chess-academy
• 12ebf1f0… — fws/platform · heartfull/platform · pags/platform · fgs/platform · apps/chess-academy · pas/platform · stores/fds

11 distinct repos across the two, overlapping on exactly two (pags/platform, fgs/platform).
These are not duplicates in any sense: they are two machines with different checkouts, and the repo
rows are the instance's own data.

A merge is destructive and there is no merge primitive. coding_repos rows are keyed
(instance_id, user_id); "merging" means re-creating six repo rows under the other instance and
throwing away 95 messages of history, by hand, with nothing to undo it. Recommendation: keep both,
merge nothing. If the goal is to retire coder (which #64 recommends drafting), the correct
sequence is to stand up one coder-repo instance per repo that still matters — coder-repo is
already at 7 subscribers doing exactly that — and leave these two alive as read-only history. Drafting
the agent does not touch them.

3. Full instance inventory — 28 active, with what each cancel would actually cost

instance	id	evidence, measured now	verdict
Chess coder	bfc76603…	5 msgs, 2 calls, repo path does not exist (§1)	cancel
Chess coder 2	bd43f4de…	67 msgs, 19 calls, ready, active today	keep + rename
coder-repo × 6 others	FAS · FWS · FGS · Heartfull · PAS Coder	one instance per repo is the agent's intended shape	keep all
Coder + Coder Home	cd489be0… · 12ebf1f0…	6 + 7 repos, 2 overlapping; 95 + 100 msgs (§2)	keep both — do not merge
ProAgentStore MCP client	a9ee6079…	3 msgs, 1 call all-time, its single mcp_list_tools failed. Sibling MCP client (dfc1cf92…) has 12 msgs, 4 calls, and working mcp_list_tools/mcp_call_tool against FreeAgentStore's MCP	cancel
MCP client	dfc1cf92…	the live one	keep
Codex MCP Browser Test	7867ed7e…	6 msgs, all 2026-06-11, 0 calls all-time; content is the fixture's own persistence marker	cancel
Google Drive Doc Chat Test	3d51aceb…	5 msgs, all 2026-07-13, 0 calls all-time; content is a smoke-test fact; holds no Drive grant	cancel
Terminal Operator · iTerm2 Operator · kitty Operator	da39100b… · 8d21ea1a… · 59cc5144…	3 msgs each, all within one minute on 2026-08-05, 3–4 calls each. All three agents are drafted.	cancel all three — but read the note below
tmux Operator	1a8486b5…	12 msgs, last 2026-08-05; still in use as a scratch instance — it is what today's 06:30 Drive/WorkDrive grant attempt was aimed at	keep
Heartfull (tmux)	cda75e28…	56 msgs, 2026-08-07; the #249 A/B instance	keep
Creator OS	b619b3da…	23 msgs, 8 hand-authored knowledge docs. Do not cancel — established on 2026-08-06, re-flagged because a drafted agent makes its instance look disposable	keep + export the docs
singles — Coder Lead · Repo Chat · Cordouan Health · Fridges · Language Buddy · Job Application Assistant · Facebook Friends · Lead Outreach Assistant · Small Business Website Lead Finder		one instance each, no duplication	keep all

Net if every cancel is approved: 28 → 22.

The note on the three operator instances. #402/#404 shipped today, and iterm-operator and
kitty-operator now carry capabilities.surfaceOptions.terminal.backends on their agent rows —
verified live. The ceiling lives on the agent, so cancelling these instances loses nothing of the
new feature, and terminal.test.ts asserts the constraint table against the tools' own JSON-Schema
enums. If you would rather keep one live fixture, keep iTerm2 Operator — it is the one whose ceiling
(backends: ["iterm2"]) differs most from the default. Either way the three chat exchanges are the
only loss.

4. Still unresolved, and it has not moved in two days

meeting-notes has subscribers: 1 and that instance is not among the owner's 28. Re-verified:
agent_analytics reports subscribers: 1, subscribes: 1, totalChats: 0. So an account outside
the operator's holds a subscription to a drafted config: {} agent that has never been chatted with.
Identifying them needs /v1/admin/*, which AGENTS.md puts out of bounds. Not touched, and it
should stay untouched until you say who it is.

5. Was the ticket still accurate?

No, and it has not been since 2026-08-06. Its "Observed (live 2026-08-01)" list is entirely
superseded — "Coder 2" and "Doc Chat 2" are gone, the 11 named commodity agents are drafted, and its
premise that "the real functioning catalog is ~4–5 agents" is wrong: 11 of 15 published agents have
real usage. Rewrite the body or close it in favour of a narrower successor — the durable question
here is not "which duplicates exist today" (that list is stale within hours; this is the third one) but
"what makes the console produce a duplicate instead of a repair", which §1 now answers with a specific,
measured mechanism.

Acceptance box 1 — "no duplicate dogfood instances remain" — cannot be ticked and, as written, never
will be. It was ticked on 2026-08-06 and a new duplicate appeared within hours; it was implicitly
true again on 2026-08-07 and a new duplicate appeared this morning. A criterion that a single
mis-typed path can falsify is not a criterion. Replace it with something checkable:

• The reason each surviving instance exists is recorded (this table, refreshed).
• A repo whose cloneStatus is needs_attention offers the folder edit that fixes it (§1).
• No instance with zero messages and zero all-time calls remains active.

Box 2 is met — per-agent reasons are on #64, refreshed there today.

---

Companion comment on #64 (fourth pass) has the agent-side verdicts, plus three findings that touch
this issue: config: {} now asserts "no connector tools" (#381, today), the lead finder's fixed
pipeline lives in a file nothing in production reads, and tmux-operator cannot declare the
targets: "single" binding #402 built for it.

[serge-ivo]

A concrete candidate for this issue: "Chess coder" bfc76603-3616-4b03-8a9a-b0af35800a51

Found while auditing the owner's Repo Coder instances. It is a two-minute mistake that has been on live surfaces for four days.

Measured, 2026-08-12:

• Created 2026-08-08 03:54:34. Last activity 03:56:25. Total working life: 1 minute 51 seconds.
• Superseded 2 minutes 40 seconds after creation by "Chess coder 2" bd43f4de-ef35-4051-bdec-43f8571414a1, created 2026-08-08 03:57:14 against the same repository — which is the instance that has been used ever since (last activity 2026-08-12 04:03:55).
• Its entire history is five message rows: two owner turns, one assistant reply, and a system row reading "The previous turn ('Try again') was interrupted before its reply was saved."
• GET /coding/sessions → {"sessions":[]}. It has never run a coding session.
• usage_summary(7d) → 2 calls, costMicros: 3.

What it still costs, which is why it is not merely untidy:

• Its one repo row (repo_a452fe0f-…, apps/chess-academy → ~/dev/stores/pas/platform/apps/chess-academy) is still being probed by the platform: cloneStatus: "needs_attention", cloneCheckedAt: 2026-08-12 04:16:42 — four days after the instance was abandoned — with cloneError: "The configured checkout … does not exist on the connected machine".
• It is registered on both of the owner's machines and appears twice in GET /v1/terminals/nodes, under RLs-MacBook-Air (connected: true, bound: true) and under Sergeys-Mac-mini.local.
• It occupies its own row in the Usage page's by-agent breakdown, labelled with its raw UUID.
• It is pinned to node "Mac" — a name that is now an alias of RLs-MacBook-Air, so the pin is one of the stale-name cases [bug] A machine's identity is os.hostname(), so one laptop is three machines — and a pin to a name it no longer uses answers every call with "run pags up" while pags up is running #379 exists to route around.

It is also the instance the platform's own history is written about. workers/api/migrations/0102_coder_repo_drop_repo_setting.sql:8-11:

"Chess coder's setting read ~/dev/stores/pas/platform/apps/chess-academy while its repo row read ~/dev/pas/platform/apps/chess-academy, untouched (updated_at two days stale)."

That is this instance, and that path is still what its repo row holds today.

Recommendation: delete it. It carries no history worth keeping (no sessions, one interrupted turn), its successor is live and healthy, and #520 explains why it cannot be repaired anyway — the repo setting it needs is no longer writable through any surface, so the wrong path it holds is permanent.

One caveat before deleting: #520 names FIS coder 5d14a2e1 as its acceptance test and cites this instance as the pre-migration counter-example that holds a wrong-but-present value. If it is deleted before #520 lands, that evidence goes with it — the state is recorded above and in #520's body, so this is a note rather than a blocker, but the two should be sequenced deliberately.

Filed here rather than as a new issue: it is one instance of the duplicate/dogfood cleanup this epic already owns, not a separate defect.