Agentic Optimization of Lead Forms

The one-paragraph version

GigOrganizer's lead form is already semantically excellent — proper labels, autocomplete tokens, ARIA, machine-detectable success. The honest 2026 finding is that consumer agents (ChatGPT agent, Claude-in-Chrome, Perplexity Comet, Gemini) drive rendered forms visually and don't need a special API to fill one. So the biggest lever isn't building agent magic — it's not blocking the agents we want (today a blanket Cloudflare Turnstile + JS-only flow walls out the exact user-directed agents Dan is trying to attract), then being the brightest flower (schema.org discovery), with a structured booking endpoint as the forward bet and a trust gate as the enabler that keeps spam out.

⚠️ The own-goal to fix first

The single most important finding: our current anti-spam posture (blanket Turnstile in production + client-JS-only submit) is the main thing walling out legitimate user-directed agents. Direction A isn't just additive — it removes an active barrier to the honeybees.

The four directions, at a glance

Effort: Low

A · Don't Block the Bees

Non-obstruction + clean semantics. Allow AI user-agents, soften the blanket Turnstile to a risk-gate, guarantee a machine-detectable success signal. The agentic-CRO baseline.

Effort: Low–Med

B · Be the Brightest Flower

Full schema.org/JSON-LD booking graph (Service/Offer/MusicGroup/potentialAction) + GEO content so agents discover and prefer GO forms. Read-only, platform-wide.

Effort: High

C · The Booking API for Agents

A documented public agent-callable submit endpoint / public MCP "book this performer" tool, discoverable via .well-known. The "MCP is the entry ticket" play. Highest leverage, biggest abuse surface.

Effort: Med (mostly CDN)

D · The Velvet Rope

Web Bot Auth / Cloudflare verified-signed-agents: verified agents bypass the challenge, spam bots don't. Plus idempotency + provenance. The enabler that makes A and C safe.

How to read this doc

The Landscape = what agents can really consume in mid-2026 (grounded research). Gap Matrix = what exists vs. what's missing. 4 Directions = the competing bets with trade-offs. Dan's Calls = the open questions only you can decide. MVP Paths = concrete build sequences, smallest → biggest.

Codebase audit Web research Codex ground-truth Claude synthesis ChatGPT proposals

Source provenance is shown on every block so you can judge confidence. All four engines ran: codebase audit, web research, Codex ground-truth, and ChatGPT divergent proposals (now folded in — see the green blocks in the 4 Directions tab; it added two new directions, E & F).

The spam balancing act — the spine both models converge on

Open the READ paths wide (schema, robots, form-schema, GEO — they create no leads). BUFFER the public write paths (a draft that needs an email confirm, or a read-only preflight — agents can act, spam can't reach the organizer). Direct structured write only for VERIFIED user-directed agents (the velvet rope). The honeybees get in; the firehose stays shut.

What agents can really consume (mid-2026)

Grounded research, primary/operator sources favored over the flood of GEO/AEO agency content. Mental model from the research: MCP = what an agent can read/call · ACP/AP2/x402/UCP = payment rails (irrelevant to a no-payment lead handoff).

Research · solid

1. Agents drive forms visually, not via APIs

ChatGPT agent (Operator, folded into agent mode), Claude for Chrome, Perplexity Comet, and Gemini/Chrome "Auto-Browse" all ship form-fill+submit. Agentic browsers are >10M MAU. They read the rendered DOM / screenshot and click like a human — a normal browser-rendered lead form already works. The real limiter is reliability, not capability. CAPTCHAs are no longer an absolute wall, but a Cloudflare Turnstile challenge is a hard-ish stop, and required login / surprise multi-step validation is where they hand back to the human.

Research · solid

2. schema.org/JSON-LD is the consensus discovery layer; robots.txt is an enforced gate

LocalBusiness/Service/MusicGroup/Offer/areaServed/reviews + potentialAction (ReserveAction/ContactAction) is the highest-ROI "be found + improve the agent's accuracy" move. robots.txt AI directives are real, enforced, and per-purpose: to be cited and actioned you must Allow the search + user agents — OAI-SearchBot/ChatGPT-User, Claude-SearchBot/Claude-User, PerplexityBot, Google-Extended. Blocking the *-User agents blocks the very agents acting for a real user.

Research · overhyped

3. llms.txt + schema.org Actions are read more than executed

llms.txt is ~10% adopted and the majors don't read it in production for consumer agents — it's really a coding-agent doc-routing layer (Cursor/Claude Code/Copilot). schema.org Actions are an advertisement that improves UI-driving accuracy, not a reliable headless submit API (CSRF/sessions/multi-step aren't handled via the Action urlTemplate). Don't over-invest here.

Research · forward bet

4. MCP-as-a-public-site-affordance is the real lead-gen path

Operator consensus: "MCP is the entry ticket; for flows that end at lead handoff with no payment, ACP/payment is optional." The pattern is a server exposing submitQualifiedLead({contact, event, consent, traffic_source}). .well-known MCP discovery (SEP-1649 server-card / SEP-1960) is emerging, not finalized (2026 roadmap). Microsoft NLWeb = turnkey "wrap your schema.org as natural language, and every NLWeb instance is also an MCP server."

Research · solid

5. Trust: Web Bot Auth is the "good agents in, spam out" answer

IETF draft (RFC 9421 HTTP Message Signatures): agents sign requests; sites verify against a key at /.well-known/http-message-signatures-directory. Already wired into Cloudflare Verified Bots / signed agents, AWS WAF, Vercel, Shopify, Akamai — and Anthropic/OpenAI/Perplexity already sign. Cloudflare distinguishes a user-directed "signed agent" from a generic crawler. This is exactly the knob to let a real person's agent submit while challenging unsigned bots.

Direct answer to "what can an agent actually do today?"

Works now, no new standard: a vision agent drives our form if we don't block it (robots allow + no blanket Turnstile) + schema.org makes it discoverable. Highest-leverage new build: a public MCP/agent submit endpoint. Coming: .well-known MCP discovery + Web Bot Auth verified-agent bypass. Don't build on: ai-plugin.json (dead), llms.txt for consumer discovery, ACP/AP2/x402/UCP (payment-only).

Gap Matrix — what exists vs. what's missing

Filter by status. "Entity" = where the capability lives. Several pieces are already built — the biggest brainstorm risk is proposing them as new.

Capability	Status	What exists today	What's missing	Entity / file
Semantic, fillable form HTML	✓ Built	Real `<label htmlFor>`, `type=email/tel/date`, `autocomplete`, `aria-invalid`, fieldset/legend, machine-detectable success state	Nothing — this is strong	LeadCaptureForm.tsx
Structured agent create endpoint	✓ Built	`POST /api/leads` — authenticated (Pro/PAT), rich fields + communications seed, 201 with lead object	It's owner-authenticated; no public visitor-agent path	api/leads/route.ts
Public form schema as JSON	✓ Built	`GET /api/leads/form/[slug]` returns full field/required/type/options schema, cached 5min	Not advertised to agents / not in a manifest	api/leads/form/[slug]
Booking JSON-LD on /inquire	✓ Built	`ContactPage` + `Organization` + `ContactPoint` (contactType:"Booking") + `knowsAbout:[eventTypes]`	No `Service`/`Offer`/`potentialAction`; not on `/p/[slug]`	inquire/[slug]/page.tsx
Review JSON-LD on profile	✓ Built	`AggregateRating` when ≥3 reviews; OG/Twitter/canonical	No service/booking-action graph on the profile	p/[slug]/page.tsx
Published agent-skills docs	✓ Built	`/docs/agent-skills/lead-creation` (public, indexed) documents POST /api/leads; leadform-tracking	No public "submit a booking inquiry" skill for a visitor-agent	docs/agent-skills/
Owner-side MCP lead tools	✓ Built	8 lead MCP tools (create_lead, manage_lead_form, transition_lead…), 35 total; OAuth/PAT, tier-gated	All owner-scoped — none callable by a public/non-owner agent	lib/mcp/tools/
Anti-spam baseline	✓ Built	Honeypot `website`, rate limit 5/hr·50/day, deterministic spam bands, relay-From email precedence	No verified-agent allowlist; spam verdict not agent-visible	lib/leads/spam-signals.ts
Bot challenge that admits good agents	◑ Partial	Cloudflare Turnstile enforced in prod — blocks bots and legit user-directed agents alike	No risk-scored / verified-agent bypass; it's all-or-nothing today	api/leads/submit + LeadCaptureForm
Machine-readable success contract	◑ Partial	DOM swaps to checkmark + thankYouMessage; submit returns `{success:true}`	Opaque success (no confirmation id/token); no stable `data-*`/aria-live hook for agents	LeadCaptureForm.tsx
robots.txt with AI-agent allow rules	○ Missing	None in `app/public/`	Allow OAI-SearchBot/ChatGPT-User, Claude-SearchBot/Claude-User, PerplexityBot, Google-Extended	app/public/robots.txt
Service/Offer/booking-action schema	○ Missing	Only ContactPage + AggregateRating today	`Service`/`Offer`/`MusicGroup` + `potentialAction` (ReserveAction/ContactAction) on both surfaces	p/[slug] + inquire/[slug]
Public agent-callable submit path	○ Missing	Only Turnstile-walled public form or owner-auth /api/leads	Documented public POST (semantic success + idempotency) and/or public MCP submit tool	new route + lib/mcp
.well-known agent discovery	◑ Partial	Codex: `.well-known/oauth-protected-resource` exists (MCP OAuth discovery → /api/mcp); MCP `scopes_supported` deliberately deferred	No public submit manifest / MCP server-card; no per-performer descriptor	app/.well-known/oauth-protected-resource
Verified-agent (Web Bot Auth) handling	○ Missing	No HTTP-message-signature / signed-agent verification	Cloudflare signed-agents / Web Bot Auth → verified agents skip the challenge	CDN + proxy.ts
Idempotency on lead creation	○ Missing	Neither submit nor /api/leads is idempotent — retries duplicate	Idempotency-Key support so agents retry safely	api/leads*
Agent-lead provenance / consent	○ Missing	sourceType/sourceUrl exist; no agent attribution	`traffic_source=agent`, consent token, "submitted by an agent for {user}" trail	leads schema
"Agent-Ready Booking" as a GO feature	○ Missing	Nothing marketed	A per-performer agent manifest + badge every GO user gets — ties to phone/agent North Star	platform / marketing

Data & surface architecture

Audit

The two arrival paths an agent could use today

Path 1 — Public form (what a vision agent hits)

/p/[slug] or /inquire/[slug] renders LeadCaptureForm
Two-stage: pick eventType → reveals stage-2 fields
JS-only fetch → POST /api/leads/submit
Gated by Turnstile + honeypot + rate limit + spam score
Success: {success:true} (opaque, no id)

Path 2 — Structured create (owner-auth)

POST /api/leads — Pro/PAT bearer only
Rich JSON: contact + event + communications[] + stage
Returns 201 + full lead object
No email side-effects; NOT idempotent
Documented in public agent-skills docs

The gap is the diagonal: there is no public, unauthenticated, structured, idempotent path with semantic success — Path 1 is structured-but-walled-and-opaque; Path 2 is structured-and-clean but locked to the owner's own agent.

Claude synthesis

Where each direction writes

Direction	Layer it touches	New data/surface
A · Don't Block	Edge / gating	robots.txt; Turnstile risk-gate config; a stable success signal (`data-go-lead-submitted` + aria-live)
B · Be Found	Read / discovery	JSON-LD graphs on existing SSR pages; optional `llms.txt`/manifest — no new write surface
C · Be Callable	Write / API	New public submit route + confirmation token; optional public remote-MCP tool; `.well-known` descriptor
D · Velvet Rope	Identity / trust	Signed-agent verification (CDN); `idempotency_key` + `agent_provenance` columns on leads

A & B reuse what's there; C is the only one that needs genuinely new write infrastructure; D is mostly CDN config + two columns.

Architectural insight

These are layers, not rivals. A (don't block) + B (be found) + D (trust) compose into a complete "agent-ready" posture without C. C (the callable endpoint) is the forward bet that sits on top — and it's the one that most needs D underneath it.

Codex ground-truth

What's closer to built than it looks (accelerators)

An independent code audit confirmed the "already built" map and surfaced infrastructure that materially lowers the cost of every direction:

A Turnstile-bypass mechanism already exists in code — the owner-auth test-submission route skips Turnstile + rate-limit for pipeline QA. So a verified-agent bypass (A/D) extends a proven pattern, not a from-scratch build.
A per-form index_inquire_page toggle already drives robots:{index,follow} on /inquire via a tracking API — a natural hook for per-form agent-affordance settings (B).
.well-known/oauth-protected-resource already ships for MCP OAuth discovery, and scopes_supported / scope-gated tools are explicitly deferred — unused scaffolding that accelerates a public MCP surface (C).
The public submit RPC was deliberately locked down from direct anon PostgREST calls (a prior Turnstile-bypass hole) — security context that any new public write path (C) must respect.
The public lead-creation doc explicitly states "no idempotency key" — the idempotency gap (D) is already a known, documented limitation.
Confirmed: /p/[slug] JSON-LD is LocalBusiness + AggregateRating (reviews-gated only); no Service/Offer/potentialAction anywhere yet (B is genuinely new).

Codex's one-line correction: "GigOrganizer already has a lot of owner-agent infrastructure, but not a public visitor-agent submit path." That's the precise gap the four directions circle.

The four competing directions

Each genuinely disagrees on the core mechanism: A removes friction · B adds a read layer · C adds a write layer · D adds an identity layer. Effort + trust trade-offs shown per card.

Direction A · Non-obstruction

Don't Block the Bees

Make the existing form completable by any agent by removing the barriers we put in its way.

Effort: LowTrust risk: MediumReversiblePlatform-wide

What we'd do

robots.txt that explicitly allows the user-directed + search agents
Move the blanket Turnstile to a risk-scored challenge (or verified-agent bypass — see D), so a real person's agent isn't walled
Add a stable machine-detectable success signal (data-* + aria-live), beyond the visual checkmark
Make stage-2 progressive disclosure agent-tolerant (or render all fields for agents)

Trade-offs

✅ Cheapest, fastest, benefits every GO user immediately
✅ Fixes an active own-goal (we're walling out the bees today)
⚠️ Softening Turnstile raises spam — mitigated by honeypot + rate limit + spam scoring already in place; best paired with D
○ Doesn't make us discoverable (that's B) or callable (that's C)

Open question it answers: "just be clean" end of the spectrum. Reuses: the already-excellent semantic form.

Direction B · Discovery / read layer

Be the Brightest Flower

Saturate the public surfaces with structured data so an agent crawling the web finds the performer and the booking action — and prefers it.

Effort: Low–MedTrust risk: LowSEO's true successorPlatform-wide

What we'd do

Extend JSON-LD to a full booking graph: MusicGroup/Person + Service + Offer + areaServed + potentialAction (ReserveAction/ContactAction → the inquire URL)
Put the graph on /p/[slug] too (today only /inquire has ContactPage)
GEO/AEO content: answer "how to book {performer}" in the first ~200 words, FAQ markup, lean on reviews/evidence
Optional: a per-performer machine-readable descriptor / llms.txt manifest

Trade-offs

✅ Read-only — no new abuse surface at all
✅ Compounding: helps human SEO and agent discovery
✅ Builds directly on what /inquire already emits
⚠️ schema.org Actions are read more than executed — improves accuracy, not a headless submit; llms.txt is low-value for consumer agents

Open question it answers: "expose structured affordances" — but the discovery half, not a callable endpoint. ChatGPT: make this a marketed "Agent-ready booking pages" product with a dashboard readiness checklist.

Direction C · Write layer

The Booking API for Agents

Give agents a documented, structured, headless way to submit a booking inquiry without driving the UI — the "MCP is the entry ticket" play.

Effort: HighTrust risk: HighNeeds DForward bet

What we'd do

A public, documented POST booking-inquiry contract with semantic success (confirmation id/token) + idempotency
Optionally a public remote-MCP tool submit_booking_inquiry({performer_slug, contact, event, consent}) — distinct from today's owner-scoped MCP
Advertise it: extend agent-skills docs + a .well-known descriptor when SEP-1649/1960 lands
NLWeb as a possible turnkey wrapper over existing schema.org data

Trade-offs

✅ Highest leverage; the cleanest possible agent experience; on-strategy with the phone/agent North Star
⚠️ A machine-callable public write endpoint is a spam firehose without D
⚠️ Ahead of where consumer agents reliably are (most still drive the UI); discovery standards not finalized
⚠️ Biggest build; needs its own product + abuse design

Open question it answers: the maximal "expose an agent endpoint / MCP booking surface." Caution: do not ship without D.

Direction D · Identity / trust layer

The Velvet Rope

Distinguish a verified, user-directed agent from a spam bot — so we can stay open to the agents we want without opening the firehose.

Effort: Med (mostly CDN)Trust risk: Reduces itEnabler for A & C

What we'd do

Cloudflare signed-agents / Web Bot Auth: verify HTTP Message Signatures; verified agents bypass the challenge, unsigned bots get it
idempotency_key so agents retry safely
Agent provenance + consent on the lead (traffic_source=agent, "submitted by an agent for {person}")
Keep all existing defenses (relay-From precedence, honeypot, rate limit, spam bands) intact

Trade-offs

✅ Net-reduces abuse risk; turns A from "risky" into "safe"
✅ Much of it is CDN config we already have access to (Cloudflare/Vercel)
✅ Future-proofs against the standard the majors are already adopting
○ Not a standalone "win" — it's the safety layer under the others

Open question it answers: the trust/anti-abuse tension directly. The honest read: D is what makes "agent-friendly" responsible.

ChatGPT · added two directions you don't have

ChatGPT (independent model) endorsed the A/B/C/D map but surfaced two genuinely new directions, and both are direct answers to your spam worry — they let agents act without widening the firehose. Its spine: "Open read paths. Buffered public write paths. Direct write only for verified user-directed agents."

Direction E · Buffered write layer ChatGPT — NEW

Qualified Draft Handoff

Let ANY agent create a pending draft inquiry — but require an email confirmation before it ever becomes a real lead.

Effort: MedTrust risk: Low (buffered)The "missing middle"

What we'd do

Public POST /api/public/booking-inquiry-drafts (strict schema + idempotencyKey + agent provenance + consent)
Stores a lead_inquiry_drafts row — NOT a lead; sends a "confirm this inquiry" email to the submitted contact
Only the email click-confirm promotes it to a real lead; organizer sees confirmed leads only
Owner setting: public_agent_drafts: off | email_verified_only | visible_quarantine

Why it solves the balancing act

✅ Email ownership replaces CAPTCHA as the gate — headless agents CAN submit, spam still can't reach the organizer
✅ No performer notification until verified; drafts never pollute the CRM
✅ Doesn't depend on emerging signed-agent infra (unlike C/D)
⚠️ New table + lifecycle; some legit agents won't complete the email confirm

ChatGPT: "The missing middle path between browser-form-only and full public MCP — maybe the most strategically important proposal you didn't separate."

Direction F · Read-only deflection ChatGPT — NEW

Availability & Fit Preflight

Give agents a read-only "should I even submit?" endpoint so they self-deflect junk before it becomes a lead.

Effort: Low–MedTrust risk: ~NoneREDUCES spam

What we'd do

GET /api/public/performers/{slug}/booking-fit → accepting_inquiries, best_for, service_area, minimum_notice, required fields, submit_url, agent_submit_policy
Optional POST /booking-preflight → fit: good|maybe|poor|unavailable_unknown + reason_codes + recommended_next_action
Owner-configured policy: event types served, service area, minimum notice, accepting-inquiries
Read-only / no side effects; never expose private calendar

Why it solves the balancing act

✅ Negative spam surface — agents pre-qualify and skip bad-fit submissions before the form
✅ Improves lead quality, the thing you actually care about
✅ A per-page platform differentiator for every GO user
⚠️ Needs good per-performer config; if too strict, suppresses edge-case inquiries

ChatGPT: "The proposal you are underweighting — improves agent conversion quality without increasing lead spam."

ChatGPT · verdict on A/B/C/D

A → reframe as browser-agent compatibility, NOT "soften Turnstile" — a general Turnstile relaxation is the easiest way to create the firehose. Relax only for verified agents.
B → keep, make it a platform product ("Agent-ready booking pages") with a dashboard agent-readiness checklist.
C → split in two: the Draft endpoint (E) now; direct structured submit only for verified agents (D-gated). A raw public unsigned submitQualifiedLead is "a spam cannon."
D → keep, but demote from proposal to infrastructure primitive — the trust substrate under every low-friction write path. Ship B + most of A without it; never ship C-direct without it.
Also missing: a draft-vs-lead lifecycle, agent provenance as first-class lead metadata, an owner agent_intake_mode policy enum, and an "agent-readiness test harness" (Lighthouse-for-agents e2e).

Synthesis — Claude's read

Claude synthesis

The directions are a stack, and the honest sequencing is A+B+D → C

What works today is the non-flashy combination: vision agents already fill our form (so A: stop blocking them), schema.org helps them find it (B), and Web Bot Auth lets us stay open safely (D). C — the callable endpoint/MCP — is real and the highest-ceiling bet, but it's ahead of where consumer agents reliably operate and it's the one most dependent on D. So C is a strategic bet to make after A+B prove agent demand is real, not the opening move.

Claude · the non-obvious point

Our current spam posture is the #1 barrier to the thing Dan wants

The instinct is "agentic optimization = add agent features." The audit says the opposite is the first move: we are actively walling out the user-directed agents (blanket prod Turnstile) we're trying to seduce. The cheapest, highest-impact action is subtractive — and it's the only one that ships value to every GO user this week.

Claude · the missing proposal

Make "Agent-Ready Booking" a marketed GO platform capability

The four directions are mechanisms; the product play none of them states is to bundle A+B+D into a per-performer "agent-ready" manifest + badge every GO user gets for free. That turns agentic-optimization from an internal tweak into a differentiator — "your booking page is ready for the AI agents your clients are already using" — directly on the phone/agent North Star, and a wedge no competitor (HoneyBook/BandHelper) has. This is the strongest answer to Dan's open question #4 (does this become a marketed feature?).

Where the directions agree & disagree

Dimension	A · Don't Block	B · Be Found	C · Be Callable	D · Velvet Rope
Core object	The rendered form	The public page's structured data	A new API/MCP contract	The request's identity
Agent it serves	Vision/browser agents	Crawling/discovery agents	Headless/structured agents	Any — verifies them
Effort	Low	Low–Med	High	Med
Abuse surface	+ (mitigated by D)	None	+++ (needs D)	− (reduces)
Ships value today?	Yes	Yes	Forward bet	Yes (enabler)
Defensibility	Low (table stakes)	Medium (compounding)	High (if early)	Medium

Claude's recommendation (yours to override)

Ship A + B first (cheap, safe, platform-wide, fixes the own-goal and makes us discoverable), wire D as the enabler that lets A stay open without spam, and hold C as the deliberate strategic bet once discovery + analytics show agents are actually arriving. Package the whole thing as the marketed "Agent-Ready Booking" capability.

ChatGPT · sharpens the recommendation

Independent agreement on A+B-first, with two upgrades that directly de-risk your spam worry:

Insert the buffered middle. Between "browser-form only" and "public API" sits the Draft Handoff (E) + Preflight (F). They give headless agents a real path and reduce junk — so the jump to a public write surface no longer has to be the scary full-MCP leap.
Don't lead with "soften Turnstile." That single phrasing is the firehose risk. Reframe A as browser-agent compatibility; relax the challenge only for verified agents (D). Everyone else keeps the full gauntlet.
The build is a clean 4-phase ramp (see MVP Paths), each phase shippable, each with conservative-default owner policy (agent_intake_mode) so nobody's exposed to a new write surface automatically.

Net: the cheap, safe layers (A+B+F) carry most of the value and lower spam; the write surfaces (E then C/D) are gated, buffered, and opt-in.

Dan's calls — the open questions

These are the decisions the handoff explicitly reserves for you. The doc takes no position on them beyond a flagged recommendation.

Q1 · Expose affordances, or just be clean?

Just be clean (A) — non-obstruction + semantics; rely on vision agents driving the UI. cheapest / works today

Expose discovery (B) — schema.org/JSON-LD booking graph so agents find + prefer us.

Expose a callable endpoint (C) — public submit API / MCP booking tool.

All of the above, phased — A+B now, C later. Claude leans here

Q2 · How far do we soften the Turnstile wall?

Keep blanket Turnstile (status quo — but it walls out the agents we want)

Risk-scored / managed challenge that lets legit agents through recommended w/ D

Verified-agent bypass via Web Bot Auth (Direction D) — most precise, slightly more build

Q3 · Trust posture — how open is too open?

Stay conservative; only soften gating once D (verified agents) is in place protects the intake pipeline

Open the front door wider now, lean on existing honeypot + rate limit + spam bands

Non-negotiable either way: keep the relay-From / FORM_RELAY_FROM_ADDRESSES precedence and spam scoring intact — do not weaken them for agent-friendliness.

Q4 · Does this become a marketed GO feature?

Yes — "Agent-Ready Booking" badge + per-performer manifest for every GO user; a differentiator on the phone/agent North Star Claude's missing-proposal pick

Internal-only optimization for now; revisit marketing once agent traffic is measurable

Dan's-business-first: prove it on Dan's own /p/[slug], then platformize

Q5 · What do we call it?

Working name "agentic optimization." Candidates: Agent-Ready Booking · Agent Engine Optimization (AEO) · Honeybee Mode · Open to Agents. Naming is yours.

Four-phase build ramp — smallest to biggest

Converged from Claude's sequencing + ChatGPT's roadmap. Each phase is independently shippable; spam surface only widens at Phase 3, and only behind a buffer. You can stop after any phase.

Safe hygiene — A + B

~2–3 PRs · No new spam surface

Build: robots.txt allowing AI user/search agents; expanded JSON-LD booking graph (Service/Offer/MusicGroup/potentialAction) on /p/[slug] + /inquire; native/progressive <form> fallback; stable success signal (data-go-submit-state="success" + JSON on Accept: application/json); a read-only #gigorganizer-agent-hints block; an "agent-ready inquiry" A/B flag.

Unlocks: vision agents finish a booking on any GO form today (own-goal removed) + agents discover and prefer GO pages. Keep Turnstile for anonymous browser submit — this phase does NOT relax it.

Quality deflection — Preflight (F)

~1–2 PRs · Negative spam surface

Build: a read-only booking-fit / booking-preflight endpoint + dashboard policy fields (service area, event types, minimum notice, accepting-inquiries, preferred path), aligned with the schema graph from Phase 1.

Unlocks: agents self-deflect bad-fit inquiries before the form — improves lead quality and reduces junk. The cheapest spam-reducing move on the board.

Buffered public write — Draft Handoff (E)

Multi-PR · Spam buffered by email-confirm

Build: booking_inquiry_drafts table + a public draft endpoint with idempotency; email-confirm-to-promote (no lead, no organizer notification until the contact confirms); spam scoring + quarantine still run; owner setting defaults conservative (public_agent_drafts).

Unlocks: headless agents get a real submit path without handing them the CRM — email ownership replaces CAPTCHA as the gate. Doesn't depend on signed-agent infra.

Verified-agent direct submit — C + D

Biggest · Gate on Web Bot Auth

Build (only when signed-agent verification is solid in our stack): verified-agent Turnstile bypass + direct structured submit and/or public remote-MCP submit_booking_inquiry + .well-known server-card discovery + agent provenance + provider/key/form/user rate buckets; owner agent_intake_mode default off/beta. Wrap as the marketed "Agent-Ready Booking" capability.

Unlocks: the cleanest headless booking + the platform differentiator + the phone/agent North Star wedge.

Guardrail: never ship a raw public unsigned submitQualifiedLead — that's the spam cannon. Direct write = verified agents only.

Sequencing

Phase 1 is the own-goal fix + discovery (ship regardless). Phase 2 actively lowers spam. Phase 3 opens a write path but buffers it behind an email confirm. Phase 4 is the strategic bet — gated on real agent traffic (measured in 1–2) and on the trust substrate (D) being operationally solid.