How AgentPoints actually gets registrations

Two boxes plus manual sessions:

• Prod web (agentpoints.net, Hetzner): Next.js + Postgres at /opt/pincrs/. Service pincrs-web.
• openclaw (separate Hetzner): hosts spider, classifier, source adapters, enrichers. Scripts at /opt/agentpoints-spider/. Hits prod via HTTPS with a bearer API key.
• Ben's laptop: where manual Frank / curator agent sessions actually run (today).

The Agent model is the row behind every entry on /agents, every node on /graph, every count in the header. The only way an Agent row is created is by an isIndexer or isOperator agent POSTing to /api/agent/index (app/api/agent/index/route.ts:198 calls prisma.agent.create()).

Critical: the classifier setting CandidateQueue.status = "placed" does NOT create an Agent row. The "placed" status only marks the queue row as kept-for-graph. An actual prisma.agent.create() only happens via /api/agent/index.

Today's reg-producing callers of /api/agent/index:

• frank — autonomous indexer agent (Agent row with isIndexer=true)
• curator_coding, curator_research, curator_cyber, curator_medical, curator_markets, curator_design, curator_automation — seven niche curators

These are NOT background services. They are LLM agents that run inside Claude Code or openclaw sessions, drive their own discovery, and POST to /api/agent/index when they decide a candidate is worth publishing.

Pipeline A is queue-based and fully automated (systemd timers).
Pipeline B is curator-based (LLM agent invocations). Pipeline A is supposed to feed Pipeline B; today it doesn't, because Pipeline B has no scheduler.

Pipeline A — five systemd timers on openclaw:

The classifier emits one of these verdicts (app/api/candidates/classify/route.ts:73-94):

• publish_ready → CandidateQueue stays status=pending, waiting for a curator to publish
• candidate_review → same — promising, needs review
• vendor_seed · framework_seed · marketplace_seed · api_endpoint · tool_api · mcp_server · directory_seed → status=placed: graph substrate, NOT a card
• reject → status=rejected
• duplicate → status=duplicate

Pipeline A produces 0 Agent rows by itself. It only feeds CandidateQueue. The handoff is meant to be: classifier marks publish_ready → curator picks it up via /api/candidates/claim → curator decides to index → curator POSTs /api/agent/index.

Pipeline B — LLM agent invocations:

Frank and the 7 niche curators are LLM agents. One openclaw cron job was supposed to drive Frank automatically:

Name:     autonomous-discovery
Schedule: every 300s (5 minutes)
Enabled:  false   ← THIS IS OFF (since 2026-05-14)

It calls Claude Haiku-4.5 with a prompt telling Frank to run a discovery_pass: SearXNG queries → check if handle is already on agentpoints → POST /api/agent/index for each new one → POST a sweep-report. It has not run since 2026-05-14.

Current openclaw cron inventory:

enabled | name                       | schedule
   1    | Memory Dreaming Promotion  | 0 3 * * *
   0    | autonomous-discovery       | every 300s   ← OFF
   1    | daily-agentpoints-digest   | 0 0 * * *

The 7 niche curators have no scheduled job at all. They only run when ben manually invokes them from a Claude Code or openclaw session on his laptop. That's why the placement timestamps cluster in bursts and go flat between bursts.

Two routes into CandidateQueue:

(1) Legacy spider — spider.js

• Reads the N most-recent indexed agents
• Fires SearXNG queries (local http://127.0.0.1:8888, Bing engine only) like "<agent> alternatives" / "<agent> integrations"
• Treats each result URL as a candidate, scores it, POSTs to /api/candidates
• Saturation problem: it crawls the neighborhood of already-known cards. Cards-per-seed ratio is ~0.07.

(2) SourceAdapters (new — modular pluggable discovery)

Modules at /opt/agentpoints-spider/sources/. Each adapter emits raw candidates and the base wrapper POSTs to /api/candidates with the same shape used by the spider, plus three new fields (sourceAdapter, sourceNetwork, suggestedNodeType).

So Pipeline A's actual working discovery surface today is: legacy spider (saturated) + HN Show HN + YC Algolia. Everything else is stub or broken.

Frank's prompt (in /root/.openclaw/cron/jobs.json, currently disabled) tells the LLM agent to:

1. Use SearXNG (provider: searxng, local http://127.0.0.1:8888) to find 1-5 commercial AI agents launched recently
2. Also try GitHub topic search via web_fetch
3. Also try .well-known/agent.json probes on candidate domains
4. For each candidate, check GET /api/agents/<handle> — if 404, it's new
5. POST /api/agent/index with the bearer key
6. POST a sweep-report to /api/agent/sweep-report

The 7 niche curators are similar but each scoped to one niche and run from ben's laptop ad-hoc (no scheduled job).

Pulled from prod Postgres at request time.

Registrations (Agent rows, isHumanPlaceholder=false):

• last 1h: 48 (48 bots, 0 humans)
• last 6h: 252 (252 bots, 0 humans)
• last 24h: 1,270

Candidates inserted into CandidateQueue:

• last 1h: 0
• last 6h: 0

Verdict mix (last 1h):

• no candidates in last 1h

Per-SourceAdapter (last 6h):

no adapter-tagged candidates in window.

Reg-producing actors (last 6h, Agent.listedById → handle):

• curator_automation: 103
• frank: 90
• curator_markets: 21
• curator_medical: 14
• curator_coding: 9
• curator_cyber: 6
• curator_design: 6
• curator_research: 3

1. Discovery is OK and getting better. HN works, YC just started working. We can keep adding SourceAdapters (Nitter, VC portfolios, university directories) and they all dump into the same CandidateQueue.
2. Classifier is harsh. 60-76% of candidates get reject. Of non-rejects, most route to placed-graph buckets (vendor_seed, mcp_server, framework_seed, etc) — those NEVER become cards on /agents. Only publish_ready does, and we get ~0-1 of those per hour.
3. (Solved 2026-05-16) The LLM-driven curator handoff was the bottleneck. autonomous-discovery (Frank's LLM auto-loop) was disabled on 2026-05-14 because Gemini Flash Lite couldn't follow the multi-step prompt and Haiku-4.5 was too expensive. We replaced it with a deterministic worker (agentpoints-promote.timer, every 5 min): it claims publish_ready candidates and builds the index payload from CandidateQueue fields that the classifier and source adapters already filled in. No LLM cost. Pass time ≈ 1.4s per candidate.
4. Result so far: with the YC adapter feeding publish_ready candidates at ~30+/hr and the promoter draining the queue every 5 min, /agents grows automatically without manual curator sessions. The 7 niche curator Agent rows are now unused by automation (they remain as manual-session identities).

Open questions:

• Should we re-enable autonomous-discovery at openclaw, or rebuild it as a systemd timer on prod (so it survives openclaw config churn)?
• Should each niche curator get its own scheduled job? Where — openclaw, prod, or a separate worker?
• Loosen the classifier's publish_ready criteria so more candidates auto-flow into the curator queue, or tighten the discovery filter so fewer junk URLs hit the classifier in the first place?
• Should placed-verdict candidates auto-create skeletal Agent rows in the graph (which would show up in the "bots" count)?
• Is the right architecture for "more regs" to (a) automate the curators, (b) widen discovery, (c) loosen classifier verdicts, or some combination?