SGT-2026 — AI Brand Visibility SERGEANT

Technical Architecture

How the production system is structured. Prepared for the dev team discussion.

System Overview

The production system is split across two platforms. Content lives in Drupal on sergeant.agency. The Quick Check engine, database, and internal tools run on Cloudflare Workers at the edge.

Drupal / Metanet
sergeant.agency
Landing page, content, SEO, blog, multilingual. Marketing team edits directly in CMS.
Cloudflare Workers
Quick Check API
AI queries, scoring, email gate, D1 database, KV cache, rate limiting. Edge-fast, ~$0.03/check.
Cloudflare Workers
Admin + Email
Internal dashboard (leads, checks, audit requests). Cron worker for score re-checks. Mailgun for notifications.

How Drupal and Cloudflare Connect

The Drupal landing page embeds the Quick Check form (HTML + JS). On submit, the browser makes a cross-origin fetch() to the CF Workers API. All processing happens on Cloudflare. Results are rendered client-side.

User-Facing Flow

sergeant.agency/ai-brand-visibility
User enters URL
POST api.sergeant.agency/check
JSON response
Results rendered on page

What Lives Where

Drupal sergeant.agency

  • Landing page content and layout
  • Quick Check form HTML + JS (embedded)
  • Blog articles (pillar content)
  • Audit request form (or link to CF-hosted form)
  • SEO, meta tags, multilingual (DE/FR/EN)
  • Navigation, footer, brand integration

Cloudflare api subdomain

  • POST /api/check Quick Check engine
  • POST /api/email Email capture + lead storage
  • POST /api/audit-request Audit form submissions
  • D1 database (checks, leads, audit_requests)
  • KV cache (rate limits, result cache 24h TTL)
  • Cron trigger for score re-checks + email alerts

CORS Configuration

The CF Worker already includes Access-Control-Allow-Origin: * for all API routes. For production, restrict this to https://www.sergeant.agency and the admin domain.

Drupal Integration

The Quick Check needs to be embedded into a Drupal page. Two approaches:

Recommended
Embed as Custom Block
Create a Drupal custom block with the Quick Check HTML + JS. The CSS can be scoped or loaded as a separate stylesheet. The JS makes API calls to the CF endpoint. No Drupal backend involvement for the check itself.
Alternative
iframe Embed
Host the Quick Check UI on CF Pages as a standalone page. Embed via iframe on the Drupal page. Simpler integration but less control over styling and worse SEO. Not recommended for the primary landing page.

What the Dev Team Needs to Build in Drupal

Admin Dashboard

Internal tool for managing leads and monitoring Quick Check usage. Runs as a separate CF Pages app with basic auth.

Views

Checks
All Quick Checks: brand, URL, score, industry, timestamp. Filter by date, score range. Export CSV.
Leads
Email captures from the gate: email, associated check, score, brand. Filter by date. Export for CRM/Mailchimp.
Audit Requests
Full form submissions: contact details, company, brand, score, competitors, interests. Status tracking (new, contacted, converted).

Tech Stack

Static HTML + vanilla JS (same approach as the project dashboard). Reads from D1 via a secured API endpoint on the CF Worker. Protected with a simple token or Cloudflare Access.

Automated Email (Score Change Alerts)

Users who enter their email at the gate receive an automated re-check notification when their score changes.

How It Works

Cron Trigger (daily)
Query leads due for re-check
Re-run Quick Check
Compare old vs. new score
Send email if changed

Implementation

Email Content

Score Dropped
"Your AI Brand Visibility Score dropped from 42 to 35. AI systems are now less likely to recommend [Brand]. See what changed and how to fix it." CTA: Request Audit.
Score Stable / Improved
"Your score is still 42. Your competitors may be moving ahead. Want to see how you compare?" CTA: Request Audit. Even stable scores create urgency.

Open Decisions for Dev Team

To Decide
Quick Check Backend
The prototype runs on CF Workers. Dev team to evaluate whether this stays or moves to a different stack:
  • CF Workers (current): Edge-fast, proven, ~$0.03/check. D1 + KV included. No server management. Limitation: no native cron UI, no built-in auth.
  • Next.js (Vercel or Metanet): Full framework, SSR, API routes, middleware. Better DX for complex features. More overhead for what is essentially an API + static page.
  • Hono on CF Workers: Lightweight framework on the same CF infrastructure. Adds routing, middleware, auth patterns without leaving the edge. Good middle ground.
  • FastAPI / Python (Metanet): If the team prefers Python. Better AI/ML library ecosystem. But adds server management and latency vs. edge.
To Decide
Audit Form Location
Option A: Audit request form lives in Drupal (native form, goes into CRM). Option B: Stays on CF (current), data synced to CRM via webhook. Option A is cleaner if Drupal already handles form submissions.
To Decide
Admin Auth
Cloudflare Access (SSO, zero-trust, free for small teams) vs. simple shared token in URL. CF Access is more secure but requires setup.
Decided
Landing Page in Drupal
Content lives in the existing CMS on sergeant.agency. Marketing team manages text, images, SEO. No separate hosting.
Decided
Email Service: Mailgun
Already in use at SGT. Transactional emails for score change alerts and audit follow-ups. Works with CF Workers and any other backend.
Proposal
API Subdomain: ai-check.sergeant.agency
Clean, descriptive, separate from the content domain. Needs CNAME DNS record pointing to CF Pages. Current prototype runs on ai-branding.sergeant.agency (can be kept for the dashboard/prototype).

Migration Path: Prototype to Production

Phase 1: Drupal Landing Page

  • Build landing page template in Drupal
  • Port Quick Check form HTML + JS + CSS as custom block
  • Point API calls to current CF endpoint
  • Test cross-origin integration
  • Restrict CORS to sergeant.agency

Phase 2: Admin Dashboard

  • Build CF Pages app with basic auth (or CF Access)
  • Read-only views for checks, leads, audit requests
  • CSV export
  • Status tracking for audit requests

Phase 3: Email Automation

  • Configure Mailgun for transactional emails
  • Build cron worker for 7-day re-checks
  • Design email template (score changed / stable)
  • Add recheck_sent and recheck_score columns to D1
  • Test with 5-10 internal leads before going live