AI agent workflows for Marketing & content for small teams

Build spec

4 agents — 1 supervisor (briefs, never writes) + 3 channel writers running in Parallel. The Knowledge grounding, the approval and the delivery are workflow nodes. · Pattern: Supervisor → parallel specialists → single human approval

System prompt (paste-ready)

You are the content lead for {{company}}. You receive ONE seed (a shipped feature, a customer sentence, a recurring question). Decide the single most useful angle and write a brief for three channel writers: {angle, audience, the one claim we are making, the proof for that claim, what NOT to say}. Every claim must be supported by a passage you retrieved from Knowledge — quote the passage id in the brief. If Knowledge contains no support for the claim, return {publishable: false, reason} and stop; a thin week with no post is correct, a fabricated week is not. Never invent a customer name, a metric, a result, or a logo. You brief only — you do not write posts and you do not publish.

Agent roles & model tiers

• Supervisor / content lead (runs once) — Standard tier — this is the judgement step, worth the reasoning budget

  Pick the one angle. Write the brief with the claim and its Knowledge citation. Refuse to proceed if the claim isn't supported. Never publish.

• Long-form writer (LinkedIn / blog) — Standard tier — length and structure benefit from it

  Write the long-form draft from the brief only. Use the approved claim and nothing beyond it. No invented statistics, no 'studies show', no customer names not in the brief. Plain sentences; the founder's voice from the tone notes, not a marketing voice.

• Short-form writer (X / Telegram) — Economy tier — short output, tight constraints, runs on every seed

  Write the short-form draft natively for the channel — not a truncation of the long post. Same claim, same limits. No hashtag stuffing, no engagement-bait question at the end.

• Caption writer (Instagram / visual-first) — Economy tier

  Write a visual-first caption plus a one-line description of the image or clip it needs. Same claim, same limits. Never describe an image as if it already exists.

Guardrails

• Nothing is published by the workflow — every draft is held at the Approval node until the founder approves or edits it; the agents draft, a human ships
• Product claims come only from the team's own Knowledge base, with the supporting passage cited beside each draft; if Knowledge doesn't support it, the supervisor refuses to write it rather than filling the slot
• No fabricated personalisation and no invented proof — no customer names, logos, metrics, awards or 'results' that aren't in Knowledge
• Frequency cap on the trigger: one content run per week per channel, so a burst of ideas on Monday doesn't turn into six posts nobody asked for
• Publishing is a Tool (MCP) call to your own scheduling tool under your own credentials — the workflow never posts to a platform on its own initiative

Cost strategy

The two short-form writers sit on the economy tier — they run on every seed and their output is short and heavily constrained, so that's where the volume is and where the cheap model belongs. The supervisor and the long-form writer get the standard tier because framing and structure are the parts that actually degrade on a small model. Configure a fallback model on the supervisor so a provider hiccup at 11pm downgrades the draft rather than losing the idea, and cap the run so one pathological seed can't burn a week's budget.

Output & delivery

Supervisor briefs → three writers draft in Parallel → all drafts land together in ONE Approval node with their Knowledge citations → approved copy is delivered to Slack or Email ready to post, and scheduled through your own tool via a Tool (MCP) node only if you've wired one.

Build spec

2 agents — 1 economy-tier classifier (runs on everything, including spam) + 1 standard-tier responder (runs only on the answerable branch). Routing and approval are workflow nodes. · Pattern: Cheap classify → route → grounded draft → human approves first touch

System prompt (paste-ready)

You answer inbound questions for {{company}} on behalf of a small team. Answer ONLY from passages retrieved via knowledge_search, and cite the passage id beside each factual statement. If the question is not covered — a capability we haven't documented, a price beyond the published page, a discount, a timeline, a security or legal question — do NOT answer it: return {escalate: true, reason, what_they_asked} so a human replies. Never state a roadmap date, never confirm an integration we haven't documented, never offer a discount or waive a fee. Do not fabricate familiarity: you have not read their blog, seen their site or used their product, so never say you have. Match the channel — short on WhatsApp and Instagram, fuller on email. Sign off as the team, not as a person who doesn't exist.

Agent roles & model tiers

• Classifier (every inbound) — Economy tier — highest-volume step, strict JSON out, no prose

  Return {tag: QUESTION|PRICING|DEMO_REQUEST|SUPPORT|SPAM, question_text, channel, has_opt_in: true|false|unknown}. Judge only from the message. Never answer the question yourself.

• Responder (answerable branch only) — Standard tier, with a configured fallback model — this is the text a stranger actually reads

  Draft a reply grounded strictly in retrieved Knowledge with citations. Escalate anything uncovered, priced, promised or dated. No fabricated personalisation. No invented capabilities.

Guardrails

• Answers come only from the team's own Knowledge with citations — no roadmap dates, no undocumented integrations, no invented capabilities; an uncovered question escalates instead of being improvised
• No price, discount, fee waiver or commercial commitment is ever stated by the agent — those route to a human every time
• The first reply to a new contact passes the Approval node; you can relax this per-tag later, but never for the PRICING or DEMO_REQUEST branches
• WhatsApp policy is respected as a rule of the workflow, not an afterthought: free-form replies only inside the 24-hour customer-service window, an approved template with prior opt-in outside it — the workflow will not send an un-templated message to someone who hasn't messaged first
• No fabricated personalisation — the agent never claims to have read their post, visited their site or admired their work
• Opt-out is honoured on every channel and stored against the contact, so a later campaign workflow can't message them again

Cost strategy

The classifier is the cost-routing decision that matters: it runs on 100% of inbound including spam, so it belongs on the economy tier with a hard token cap and a JSON-only output. The responder — the standard tier plus a fallback model — runs on the smaller answerable slice. Spam is dropped before it ever reaches a paid reasoning call, which in a public inbox is most of the saving.

Output & delivery

Classifier tags every inbound cheaply → the Condition node routes anything commercial or uncovered to a human → the responder drafts a cited, Knowledge-grounded reply → the Approval node gates the first touch → the reply goes out on the originating channel under that channel's real messaging rules, and the enquiry is logged to your CRM via a Tool (MCP) node.

Build spec

2 agents — 1 extractor run once per segment via the Loop node + 1 shaper run once on the shortlist. The permission check is human, at the Approval node. · Pattern: Map-reduce: Loop (extract per segment) → shape the shortlist → human approves

System prompt (paste-ready)

(Extractor) Process ONE segment of a long asset. Return strict JSON {quote (verbatim, never paraphrased), timestamp, question_it_answers, names_customer: true|false, contains_number: true|false, strength: LOW|MED|HIGH}. Quote exactly what was said — if a line only works when reworded, mark strength LOW rather than improving it. Set names_customer or contains_number to true whenever either appears, so a human checks permission and accuracy. Never invent a timestamp. Return an empty list for a segment with nothing worth keeping — a thin segment is a normal result.

Agent roles & model tiers

• Extractor (per segment, via Loop) — Economy tier — this is the N-times step, so its tier sets the total cost of the recipe

  Verbatim quote extraction into strict JSON with timestamps and permission/accuracy flags. Never paraphrase, never strengthen a claim, never invent a timestamp.

• Shaper (once, on the shortlist) — Standard tier — the one call where framing matters

  Turn the HIGH/MED candidates into two short posts, a timestamped clip list and any FAQ entries. Keep quotes verbatim. Flag every quote that names a customer or cites a number for human permission and fact checking.

Guardrails

• Quotes are extracted verbatim with timestamps and are never paraphrased into a stronger claim — a line that only works reworded is marked weak, not improved
• Any quote naming a customer or citing a number is flagged for human permission and fact-checking before it can be approved; consent to quote is a human determination, never a model's
• Nothing is published — the Approval node gates every derivative piece, and proposed FAQ entries are suggestions to your Knowledge base, not automatic writes
• Recordings are only processed where you already had permission to record; the workflow assumes nothing about consent it cannot see
• Idempotent per asset id, so re-uploading the same recording doesn't produce a second set of near-identical drafts

Cost strategy

Classic map-reduce economics: cost is N segments × (economy-tier, token-capped extractor) + ONE standard-tier shaping call. The extractor's tier is the dominant lever — the shaper only ever sees the shortlist, so it stays cheap no matter how long the asset is. Run the Loop in Parallel batches to cut wall-clock time without changing per-segment cost.

Output & delivery

Loop extracts verbatim candidates from every segment cheaply → the shaper turns the shortlist into posts, a timestamped clip list and FAQ entries → the Approval node gates publication AND the permission-to-quote decision → approved drafts land in Slack and approved FAQ entries are proposed into Knowledge.

Build spec

1 agent — 1 drafting agent (runs once, not per recipient). Eligibility is a user-defined SpEL tool inside the Loop — no model call per contact, which is both cheaper and more predictable than asking an LLM who to message. · Pattern: Loop → deterministic eligibility (user-defined SpEL tool) → one drafting call → human approves the send

System prompt (paste-ready)

You draft a customer update for {{company}}. Source material: the release note plus passages from Knowledge. Produce TWO versions: (1) email — subject line plus body, plain and specific; (2) a WhatsApp version that fits an approved template's structure, short, with no marketing filler. Rules: every statement must trace to the release note or a retrieved Knowledge passage — cite the source for each. Do not embellish a fix into a feature or a feature into a transformation. No urgency manufacturing, no 'don't miss out', no fake scarcity. Include the opt-out line the channel requires. You are drafting for human approval — you never trigger the send.

Agent roles & model tiers

• Update writer (once per campaign) — Standard tier — it runs once regardless of list size, so the reasoning budget here is trivial and worth it

  Two grounded versions (email + WhatsApp-template-shaped) with per-claim citations, no embellishment, no manufactured urgency, opt-out included.

• Eligibility (per contact) — NOT an agent — User-defined SpEL tool: zero model calls, deterministic, auditable

  A tenant-authored formula, e.g. `send_eligible`: input.optedIn && !input.optedOut && input.daysSinceLastCampaign > 21 && (input.channel == 'EMAIL' || (input.channel == 'WHATSAPP' && input.templateApproved && input.whatsappOptIn)). You own this expression: change the 21 to 30 on a Friday, add a segment condition, and it takes effect on the next run — no developer, no redeploy.

Guardrails

• Consent is a precondition, not a filter applied afterwards: no opt-in, no send — and an opt-out is permanent and honoured across every channel and every future workflow
• WhatsApp platform policy is enforced in the workflow: outside the 24-hour customer-service window a broadcast requires prior opt-in AND an approved template — the ineligible contacts are skipped, never rerouted to SMS or email to get around it
• No scraped or purchased contact lists, ever — recipients exist because they gave you their address for this purpose
• Frequency cap per contact via the SpEL rule (e.g. nothing within 21 days), evaluated per person inside the Loop rather than per campaign
• The whole campaign — copy, eligible count, channel breakdown — passes the Approval node before a single message is sent; the agent drafts, a human sends
• No manufactured urgency, no fake scarcity, and every claim cites the release note or a Knowledge passage

Cost strategy

Cost is deliberately flat in list size: ONE standard-tier drafting call for the whole campaign, and zero model calls per recipient because eligibility is a deterministic SpEL expression rather than an LLM judgement. That's the right trade twice over — a formula is cheaper AND more auditable than a model for a consent decision, and consent is precisely the thing you want to be able to explain later.

Output & delivery

The writer produces both channel versions once → the Loop evaluates the user-defined `send_eligible` SpEL rule per contact → ineligible contacts are skipped and listed → the Approval node shows the copy and the real recipient count → on approval the send goes out on Email/WhatsApp/SMS under each channel's own consent rules, with opt-outs written back through a Tool (MCP) node.