# RecordGod AI assistant — honest assessment & plan (2026-06-24)

OpenRouter key stored in the vault (`openrouter_api_key` + `openrouter_model`), reachable like every other
credential. This doc is the "durry and a short black" think: what's genuinely dope, what's hype, what breaks
things, and how to build it so it only helps.

## The one-paragraph honest take

The LLM is a **commodity** — anyone can call OpenRouter. The moat is that RecordGod can **ground** the model in
proprietary, structured, *vectorised* data: the full Discogs mirror, the live cross-store market intelligence in
DealGod (pgvector lives there, reached via the DealGod API — **RecordGod-db itself has no pgvector**), real sales
and stock. A WooCommerce plugin with a chatbot is a toy; "talk to your shop, and it answers with *your* numbers and
*the market's* numbers, then drafts the copy/newsletter/price for you to approve" is a product. **So the sell isn't
"AI" — it's "AI that can't lie to you because it's reading the database, and can't break anything because it can
only propose."**

## The non-negotiable architecture: tools, not free SQL

The exciting line — "it can run actual Postgres queries for the exact info it needs" — is right in spirit and a
foot-gun in the literal. The safe, equally-powerful pattern is a **tool-calling agent**: the model picks from a set
of vetted, parameterised functions; *our* code runs the query. The model never sees a raw `psql` prompt.

- **Phase 1 — fixed read tools (safest, ~90% of the value).** `stock_query`, `release_lookup`,
  `market_value`(DealGod API), `semantic_search`(DealGod pgvector API), `sales_summary`, `customer_wants`,
  `catalog_health`. The model composes them; results are real rows, so it summarises rather than hallucinates.
- **Phase 2 — constrained text-to-SQL for power questions.** Only against a **read-only role**, over a curated set
  of **VIEWS** (not raw tables), with the generated SQL parsed (reject anything not a single `SELECT`), a forced
  `LIMIT`, and a `statement_timeout`. Even then, the fixed tools answer most real questions more reliably.
- **Never — free SQL execution.** One `UPDATE`/`DELETE`/`DROP` from a hallucination or an injected instruction and
  the shop is down. Not happening.

## Writes: propose, never commit

RecordGod is *already* the right shape for this — intake **stages**, publish is a separate non-destructive step.
The AI just becomes another stager/proposer. Every write-flavoured capability lands in a **review queue** a human
approves; nothing the agent does is live without a click.

- `propose_price(sku, price, reason)` → a `proposals` row → human applies.
- `propose_intake(...)` → `staged` inventory (already non-destructive).
- `draft_newsletter` / `draft_product_copy` / `draft_wantlist_emails` → text only, human sends.

## The dope things, honestly rated

**Tier A — genuine value, low risk, ship first:**
1. **Ask-your-data.** "DnB 12-inches under $10 not sold in 90 days?" → tools → a table. Huge for a shop owner.
   Semantic angle (DealGod pgvector): "records with a *vibe* like this one," not just keyword.
2. **Product copy / hype spiels.** Feed the model the *real* artist/label/year/tracklist/condition + DealGod
   rarity → a punchy description or social caption, grounded in facts. The killer low-risk content win.
3. **Newsletters.** "New techno arrivals + 3 staff picks" → query new stock → draft HTML → human reviews → send via
   the existing mailer. Draft-only.
4. **Stock-hygiene assistant.** Surface Heal-sweep gaps, flag below-market/mispriced items (DealGod median), find
   dupes. Read + propose.
5. **Intake helper.** "Box of these" → describe → semantic search the Discogs mirror → propose matches → human
   confirms → stage. Pairs with the intake we built.

**Tier B — valuable, needs the propose-gate:**
6. **Auto-pricing suggestions** (propose, not apply) using DealGod cross-store median × condition.
7. **Wantlist matching** — "these 4 customers want what just arrived" → draft the notify emails.

**Tier C — flashy, lower ROI / higher risk:**
8. **Autonomous "site maintenance"** = write access. Honest answer: don't. Keep it propose + human-apply. Full
   autonomy is exactly where it breaks shit.
9. **Free text-to-SQL on master.** Great demo, real foot-gun; covered better by fixed tools + Phase-2 read-only views.

## Guardrails (so it only helps)

| Risk | Guardrail |
|---|---|
| Destructive writes | Agent gets a **read-only DB role**; all writes are **propose → human apply** |
| Bad/expensive SQL (Phase 2) | read-only role · curated VIEWS only · parse-and-reject non-SELECT · forced LIMIT · `statement_timeout` |
| Tool abuse | hard **allowlist** of tools; no shell, no file write, no arbitrary HTTP |
| Hallucination | answers are **grounded** in returned rows; "AI draft — review" label on all output |
| Prompt injection (notes, customer msgs, web text are untrusted) | untrusted text can't trigger a write — the human gate absorbs it |
| Cost creep | per-call **cost + token log** (`ai_log`), daily **budget cap**, cheap models for bulk |
| PII leakage | customer tools return **de-identified** data unless a task needs more (matches DealGod privacy posture) |
| Over-trust | every agent action is **logged and reversible**; proposals show their reasoning + source rows |

## Model routing (OpenRouter's real advantage)

Route per task, don't pick one model:
- **Bulk / tool-calling / SQL reasoning** → DeepSeek V3 or Gemini 2.5 Flash (fast, dirt cheap, plenty smart).
- **Nuanced copy / newsletters** → Gemini Flash or a mid model; hype spiels don't need a frontier model.
- **Hard multi-step analysis** → route up to a stronger model (incl. Claude via OpenRouter) for that call only.
Store a default in `openrouter_model`; let specific tools override.

## Build phases

- **Phase 0 (done):** Connect page stores `openrouter_api_key` + `openrouter_model`; test button shows usage.
- **Phase 1:** `app/ai_routes.py` agent loop + the 7 read tools + `draft_*` tools. One `/admin` "Ask RecordGod"
  panel (chat box → grounded answer + the tool trace). `ai_log` table (prompt, tools, tokens, cost, user, ts).
  Everything read/draft. **This is the demo that sells.**
- **Phase 2:** `proposals` review queue + propose tools (price/intake/wantlist). Constrained text-to-SQL over
  read-only VIEWS for power users.
- **Phase 3:** Scheduled agent jobs (weekly newsletter draft, daily mispriced-stock report) — still draft/propose.

## Honest bottom line

Worth building, and a real differentiator — **because of the data, not the model.** Start with read + draft
(Phase 1): all upside, no blast radius, and it's the version you can put in a sales demo. Add propose-and-apply
only behind the review queue. Keep the agent read-only and human-gated and it can't break the shop — it can only
make it faster to run. Links: [[openrouter-llm-backend]], [[recordgod-engine]], [[recordgod-intake-three-source]].