> Short answer: an LLM marketing automation queue should separate intent detection, consent, cadence control, and human review before any message reaches a prospect. The goal is not to send more follow-ups; it is to send fewer, better-timed actions that match what the visitor actually did.
The Problem
Most teams wire blog analytics directly into a nurture sequence and call it automation. A reader opens a post about pricing, a webhook fires, and the system immediately pushes the same sales email used for every other visitor. That looks efficient on a dashboard, but it trains prospects to ignore the brand because the timing and message are disconnected from intent.
The harder problem is that LLMs make bad automation cheaper. If a model can generate ten follow-up emails in seconds, an undisciplined funnel can create ten times more noise. AIKit needs the opposite pattern: a queue that converts content signals into ranked, auditable, and rate-limited actions. The queue should decide when to wait, when to enrich context, when to ask for human approval, and when to trigger a lightweight customer-care touch.
The Solution
Build the funnel as a staged queue instead of a direct send pipeline. Each event becomes a task with a score, a reason, a cooldown window, and a next action. The LLM is used to classify intent and draft helpful copy, but deterministic rules decide whether the action is allowed. This keeps the system scalable without turning it into a spam engine.
A practical version has five stages: capture the event, enrich it with content context, classify the visitor intent, choose a safe action, and log the outcome. Every stage writes a small record that can be inspected later. If the model is wrong, the audit trail shows which signal or prompt caused the mistake.
Architecture Overview
The queue can run on a simple serverless stack. Cloudflare Workers receive events from the blog, D1 stores durable tasks, KV stores cooldown locks, and a scheduled worker processes a bounded number of tasks per run. The LLM only touches normalized summaries, not raw personal data, unless the visitor has explicitly opted in.
Text flow: blog event -> event normalizer -> D1 queue row -> intent classifier -> policy gate -> draft generator -> human review or approved send -> analytics table. That order matters. The policy gate sits after classification but before generation so the system can reject bad actions before spending tokens on them.
```sql
CREATE TABLE marketing_queue (
id TEXT PRIMARY KEY,
visitor_hash TEXT NOT NULL,
event_type TEXT NOT NULL,
content_slug TEXT NOT NULL,
intent TEXT,
score INTEGER DEFAULT 0,
status TEXT DEFAULT 'pending',
reason TEXT,
next_action TEXT,
created_at TEXT DEFAULT CURRENT_TIMESTAMP,
updated_at TEXT DEFAULT CURRENT_TIMESTAMP
);
```
Step 1: Capture Signals Without Overreacting
Start with conservative signals. A single page view should not trigger a sales sequence. Better inputs include repeat visits to related posts, downloads of a checklist, clicks on pricing CTAs, searches for implementation terms, or replies to a customer-care prompt. Each signal should map to a weak score, and the queue should require a threshold before any outbound action is considered.
Example scoring: a normal article view is 5 points, a second visit within seven days is 15, a pricing click is 35, and a lead-magnet download is 50. A send action may require 70 points plus consent. This makes the queue patient. It can still notice intent quickly, but it does not confuse curiosity with permission.
Step 2: Classify Intent With a Narrow Prompt
The classifier should return structured JSON, not prose. Give it the page title, excerpt, event type, and recent anonymous journey summary. Ask for an intent label such as learn, compare, implement, buy, support, or unsubscribe_risk. Also ask for a confidence score and a one-sentence reason.
```json
{
"intent": "implement",
"confidence": 0.82,
"reason": "Visitor read two workflow posts and downloaded the automation checklist.",
"recommended_action": "send_tutorial_followup"
}
```
The prompt should forbid unsupported claims. If the model cannot infer intent from the events, it must return learn with low confidence. This one rule prevents many aggressive automations because uncertain cases stay in education mode instead of being pushed into sales mode.
Step 3: Add Policy Gates
Policy gates are plain code. They check consent, cooldowns, account status, and channel limits. For example, do not send more than one nurture email in forty-eight hours, do not send sales copy to a visitor without opt-in, and do not create a sales task when the latest signal is a support article. These gates should be deterministic and easy to test.
```ts
function canSend(task, profile, locks) {
if (!profile.emailOptIn) return false;
if (locks.has(`cooldown:${profile.id}:email`)) return false;
if (task.intent === "unsubscribe_risk") return false;
if (task.score < 70) return false;
return true;
}
```
Step 4: Generate Helpful Actions
When a task passes policy, the LLM should draft a short, specific action. The best follow-up is usually not a hard sell. If someone read three posts about blog automation, send a setup checklist. If someone compared plugin architecture pages, suggest a technical walkthrough. If someone clicked pricing after reading a case study, offer a demo with context from that case study.
Keep the generated copy under 120 words and include the source reason in the queue row. Human reviewers can then see why the draft exists. For low-risk channels, the system can auto-send after review rules are proven. For high-intent sales actions, keep a human approval step until the false-positive rate is measured.
Results and Metrics
A healthy queue is measured by restraint as much as volume. Track queued events, approved actions, suppressed actions, human edits, unsubscribe rate, reply rate, demo bookings, and time from signal to helpful touch. A good first target is to suppress at least 60 percent of raw events, keep human edit distance below 25 percent, and maintain a reply rate that improves over the non-personalized baseline.
| Metric | Why it matters | Healthy signal |
|---|---|---|
| Suppression rate | Prevents spam | 60-85 percent |
| Approval rate | Shows useful classification | 20-40 percent |
| Reply rate | Measures relevance | Higher than batch email |
| Cooldown violations | Catches policy bugs | Zero |
| Human edit distance | Measures draft quality | Below 25 percent |
Key Takeaways
- Use LLMs to classify and draft, not to bypass consent or cadence rules.
- Store every marketing action as a queue record with score, reason, status, and next action.
- Put deterministic policy gates between model output and customer contact.
- Optimize for helpful timing and lower noise, not maximum send volume.
- Review suppression metrics because the actions you do not send are part of the customer experience.