What Poppy is
Per the live Pure Dictionary (adopted by Mike, 2026-06-27): Poppy is the spoken name and persona of PURE's AI — Claude, reached through the functions/v1/chat Edge Function.
Poppy is the voice; Pure Chat.ai is the room
The surface name stays Pure Chat.ai. Poppy is the persona that speaks inside it and inside the Tech Panel Operator. "Pure" echo + a warm human name = adoption.
Agentic tool-use over live data
She answers grounded in real PURE data (listings, dictionary, board, deals, memory, crons), can run a live web search, and can propose gated writes (file a ticket, run a cron) behind a human approval card.
One-line truth
Poppy v1 is a single-model, read-mostly, conversational agent with a tight, safe tool loop and two gated write actions. She is the same Poppy for everyone — not yet shaped by who you are, what hat you wear, or which brokerage you're in. That personalization is the heart of v2.
The brain — supabase/functions/chat
Poppy's brain is one Deno Edge Function (currently v26) holding the ANTHROPIC_API_KEY server-side. It runs an Anthropic tool-use loop, grounds reads in live RPCs, and turns writes into approval cards. It never executes a write itself.
Request reply, step by step
Inbound
UI posts {messages[], images[], system}. Last 20 messages kept; images attach to the most recent user turn (vision-capable).
System prompt assembled
Caller system text + hard brand rule (never use emoji) + a tool manifest describing reads, gated writes, and web search.
First model call
Sends the 6 read tools + 2 write tools + Anthropic web_search. If a model/version rejects web search, it retries once without it (resilience).
Agentic loop (≤5 rounds)
While the model asks for tools: reads execute immediately against Supabase RPCs and feed results back; writes do not run — they become approval cards and the model is told to say "pending your approval."
Response shape
Returns { reply, ticket, approvals[] }. reply = text; ticket = optional parsed ```ticket``` block; approvals = gated cards the UI renders.
What's genuinely strong in v1
Server-held key (never exposed), reads-free / writes-gated by construction, vision input, native web search, a bounded loop that can't run away, and a clean three-field contract the front-ends already understand. This is a solid spine to build on — v2 extends it, it doesn't replace it.
Her live toolbelt
Exactly what Poppy can reach right now from chat. Six reads run instantly; two writes are gated; web search is native.
| Tool | Kind | Backing RPC | What it does |
|---|---|---|---|
| search_listings | read | mcp_search_listings | Search live MLS listings by city / area / keywords. Source: NTREIS via RETS only (North Texas). Full feed definition + live health below. |
| lookup_term | read | mcp_dict_lookup | Define a PURE canon term + where it lives. |
| list_tickets | read | mcp_board_list | List board work items by status / lane. |
| lookup_deal | read | mcp_deal_read | Read a transaction / deal by id or address + checklist. |
| get_memory | read | mcp_memory_get | Read agent memory (a key, or list keys). |
| list_crons | read | mcp_cron_list_chat | List cron jobs + schedule + 24h success/fail + failure streak. |
| web_search | web | Anthropic native | Current external/world info, up to 5 uses per reply. |
| add_ticket | gated write | mcp_board_dispatch | Propose a new board ticket approval card runs only on approve. |
| run_cron | gated write | mcp_cron_run_now | Propose running a cron now approval card runs only on approve. |
Listings data feed — NTREIS via RETS
Every search_listings result comes from one source: the NTREIS RETS feed (North Texas Real Estate Information Systems). No other MLS, no national aggregator. A tiny secondary zoho set (1,893 internal rows) exists but is not a consumer MLS source. Geography is therefore NTREIS's North Texas footprint — not nationwide.
NTREIS · RETS ingest
Green when the RETS sync is ≤ 2h old · Amber 2–6h · Red > 6h or any ingest error (RETS auth fail, row-count drop, schema drift). On Amber/Red Poppy flags the feed and escalates to Shattique (CTO) for immediate remedy — in-app notify + Pure Send, CC Mike, with the last good sync time and error detail.
The headline gap
Poppy's chat brain exposes 8 of the platform's 87 MCP tools. The fleet can already create+route leads, push calendars, read CDAs, mint share links, send comms, read the People Graph, run deploys, and more — but Poppy can't call most of it yet. Closing this gap (safely, per-hat) is v2 Pillar 1.
The wider fleet Poppy doesn't use yet
The MCP control plane catalogs 87 tools across 7 servers (76 enabled). Reads are free; risky writes are approval-gated. v2 Poppy's job is to reach these — filtered by the user's hat, org level and subscription.
| Server | Live / total | Representative tools | Status |
|---|---|---|---|
| pure-mcp core ops gateway | ~57 / 60 | board.* · memory.* · qa.log · intake.submit · deal.read · dict.* · lead.create · person.read/link · calendar.push · run.next · autopilot · cron.* · improve.* · watch.* · brand.* · rls.audit | live |
| pure-comms email / SMS / notify | 6 / 8 | email.send · sms.send · comms.notify · comms.log · deal.share · share.verify · comms.email/sms | live + planned |
| pure-money clearing / books / CDA | 5 / 8 | cda.read · books.entry · release.cut/list · deploy.rollback · money.clearing/cda/books | live + planned |
| pure-connect external connectors | 2 / 5 | referral.read · alert.read · fub.leads · matterport.models · maps.geocode | mostly planned |
| pure-mls RESO / syndication | 1 / 3 | listing.check · mls.validate · mls.syndicate | planned |
| pure-deploy Netlify publish | 1 / 2 | release.publish critical · release.revert | live (gated) |
Risk tiers in the catalog: low reads run free · medium/high writes are approval-gated · critical (deploy, money post, syndicate) demand superadmin + offline-code. v2 inherits these tiers verbatim — Poppy never gets a capability the catalog says a hat shouldn't have.
Surfaces Poppy speaks through
pure-chat.html — Pure Chat.ai
The production conversational client on acquisto.biz. History + vision + persona + ticket drafting; calls the chat fn, falls back to window.claude then a local reply. Version-tracked as pure-chat v1 (status live) in pure_versions.
pure-chat-v2.html — best-in-class shell
staged Mike-approved superset: Actions/Board/Share/Models/Research tabs, inline preview cards, approval card UX, slash commands (/board /ticket /find /define /remember /web), tool-activity transparency chips, citations, screen-recorder. Awaiting Code to wire the tools[]/citations[]/web contract, then it replaces v1.
UI rule (Mike): Poppy's v2 interface is built in this R&D lane. v1 (pure-chat.html) keeps its current UI untouched and is upgraded only at deploy — a version swap in pure_versions promotes v2 to live and supersedes v1. No live UI changes until then.
ai-roleplay.html — Roleplay Trainer
Practice-with-Poppy: scripted real-estate scenarios for agents. v4 scope folds this in as "practice with Poppy" alongside proactive digests.
Tech Panel Operator — pure-tech-admin.html
The admin-side Poppy surface. Same brain, operator framing; per-user capability matrix (view/operator/tickets/lanemail/content/cron + guarded deploy/access/keys/destroy).
Grounding: dictionary, memory & the surface registry
Poppy's answers are anchored to three living sources of truth, all in the live DB.
Pure Dictionary
219 terms · 32 categories (Product 30, Marketplace 29, Transaction 19, Org 16, …). Single source of truth; PureGuard enforces it on every field. Poppy reads it via lookup_term.
pure_memory
216 keys — canon, standing rules, plans (v2v5), infra, routines, personas. Poppy reads via get_memory; broadcast keeps every session fresh within ~1 min.
pure_surfaces
The canonical registry of every PURE surface Poppy can discover / describe / open / act on — slug, route, slash command, quick prompt, intent routing, data-entry doctrine. Coverage monitor keeps it honest.
Plus the board (tickets/work), deals (transactions + checklists), and listings (1.49M MLS rows, ~hourly fresh) as live operational context.
Memory & live propagation
No Poppy session ever runs on stale canon. The broadcast rule guarantees new memory reaches every live chat within ~60 seconds and every new session on boot.
trg_memory_pulse
An AFTER INSERT/UPDATE trigger on pure_memory bumps pure_memory_pulse (version, last_key, updated_at).
60-second poll
Pure Chat + agents poll the pulse every ~60s; if the version rose since boot they re-fetch changed keys and show a subtle "Memories updated — synced" note.
pure-memory-broadcast cron
Runs every minute to keep the pulse + digest fresh (the maintenance beat behind the instant trigger).
>1h idle force-check
On window focus after >1h idle, a session forces a pulse check + memory reload before its next action.
Permissions & the approval model
The governing doctrine: reads are free; writes, deploys and external calls are gated. Poppy — like every PURE agent, including Claude itself — must request permission before any write.
"Allow Poppy to use <Tool>?"
Shows the exact tool slug + JSON args + a scope badge (Project / Org / Platform = blast radius). Buttons: Deny (1) · Always allow (2) · Allow once (3, Ctrl+Enter default).
Grants are revocable + logged
"Always allow" persists per principal + tool + scope (today localStorage; server-side target = pure_access_rules / grants + audit_log). Revocable anytime in Command Center. Every gated run writes an audit row.
How v1 enforces it
In the chat fn, gated tools (add_ticket, run_cron) literally cannot execute — they only emit an approval object. The model is instructed to never claim a gated action is done. This is the right backbone; v2 widens the toolset behind the same gate and moves grants server-side.
The autonomous layer — 34 active crons
Poppy doesn't run alone. A heartbeat of 34 pg_cron jobs keeps the platform alive, fresh and self-checking. Machine work routes to the job queue (pure_mcp_jobs), not the human board.
- pure-health-probe · 5 min
- pure-cron-health · 5 min
- pure-watchdogs · 10 min
- pure_cache_refresh · 20 s
- cron-efficiency-snapshot · daily
- pure-autopilot · 10 min
- pure-autopilot-expire · 15 min
- pure-improve-dispatch · hourly
- pure-improve-weekly / retune
- pure-project-reap · daily
- pure-comms-drain · 1 min
- pure-relay-flush · 1 min
- pure-memory-broadcast · 1 min
- pure-nightly-memory · daily
- pure-morning-leads · daily
- pure-nightly-mls · daily 07:00
- content-spider · daily
- pure-weekly-referral · Mon
- pure-coverage-scan · daily 03:00
- rls-watchdog · daily 02:00
- pure-design-audit weekly
- brand-emoji-sweep · Mon
- brand-gate-upcoming · Mon
- pure-icon-nightly / weekly
- pure-brand-digest · daily
- pure-masterplan-refresh · daily
- pure-guide-refresh · daily
- pure-merger-digest · daily
- trustseal_anchor_daily
- coming-soons-fill · 15 min
Today these crons run beside Poppy. v2's auto-run pillar lets Poppy read their health, explain failures, and (gated) act on them — she already has list_crons read + run_cron gated; the fleet adds cron.detail/runs/pause/edit/health.
Model routing & spend
v1 runs one model for everything (Sonnet, env-overridable). The board already stamps a per-ticket model (Haiku/Sonnet/Opus) and estimated rates exist — but there's no live per-task router yet. That's v2 Pillar 2.
Caps are advisory now; they hard-stop once MCP routes the calls. Alert at 90%. Rates are estimates until real metering lands with the router.
Identity, hats & org levels
The org spine that v2 personalization rides on already exists in canon — Poppy v1 just doesn't read it per-user yet.
Platform › MLS › Association › Brokerage › Client & Party
One MLS sits above 14 associations; a brokerage (e.g. Acquisto Real Estate) contains Agents, Teams and ISAs as roles, not levels. Clients & parties link into a deal by grant.
auth.uid() + hats from pure_permissions
A single person wears multiple hats; authorization = RLS on auth.uid() + hats. Canon roles: agent, designated_broker, isa, transaction_coordinator, client, association_admin, mls_admin, superadmin, vendor.
The v2 unlock
"One Poppy, many gated instances" — identity × hats × org level × brokerage workspace (pure_chat_workspaces) × per-user poppy_memory. Tools, data and voice computed live from pure_permissions + pure_subscriptions, updating as the user's status changes. The wiring is all here; v2 connects it to Poppy.
Honest gaps the v2 mandate
A baseline is only useful if it's honest about limits. Here's what v1 can't do — each line is a v2 work item, not a criticism.
| v1 today | Gap | v2 direction |
|---|---|---|
| Same Poppy for everyone | No identity / hat / org awareness in chat | Per-user gated instances from pure_permissions + subscriptions |
| 8 of 87 tools exposed | Can't create leads, push calendars, read CDAs, send comms, etc. | Hat-scoped access to the full fleet behind the same approval gate |
| One model (Sonnet) | No per-task / modality routing or live metering | Best-model-per-task router + hard caps + self-tuning |
| Reactive only | Waits to be asked; no proactivity | Proactive digests, critical-date & drift alerts, practice nudges |
| Single-turn answers | No multi-step autonomy on real work | Poppy runner over pure_mcp_jobs + verifier-in-loop + gated deploy |
| Shared memory only | No per-user / per-deal memory | poppy_memory keyed to auth.uid + deal, RLS-scoped |
| Text + vision in | No voice | Optional voice in/out per subscription |
| localStorage grants | Approval grants not yet server-side | Server-side grants + audit in pure_access_rules |
Next deliverable from this session
With v1 fully mapped, the next artifact is the v2 Poppy Capability Map + Architecture — turning these eight gaps into a build plan (per-user instance model, fleet access matrix by hat, the model router, the proactivity engine, the runner, and voice), coordinated with the v3/v4 session over the board and Lane Mail. v1 Poppy's v4 ship is untouched — v2 is parallel R&D.