Multi-Persona Social Launch (starter blueprint)

Slug: multi-persona-social-launch Type: agent_blueprint Source: code-defined; appears in every tenant's agent_blueprint://list automatically. Fork via agents.fork_blueprint to customize. Outputs: the array of content_piece ids created (one per persona) + a synthesis envelope with posting order and strongest-draft pick.

Agent-driven multi-persona social drop on a single topic + channel + campaign. An agent reads this recipe and walks it to draft and (optionally) publish a social post per persona in your team's directory, each in their own voice, grounded against substrate + external research + your campaign's verified customer quotes. Designed for product launches, announcements, and beat-driven moments where the agent is the approver and no editorial calendar is needed.

When to use it

• A product launch with multiple voices going live in a coordinated window (CEO, CTO, GTM lead, growth, founding engineers).
• An announcement that needs simultaneous posts from several teammates, each in their own voice.
• A campaign moment (Black Friday, partnership reveal, feature launch) on either LinkedIn or X/Twitter.
• Any flow where the agent itself is the approver and you don't want a phantom editorial calendar in the loop.

Don't use it for: monthly editorial cadences (use plan-and-draft-window instead, which is built around a planner + per-piece review).

Reading this blueprint

Per the agent blueprint substrate contract: this is a recipe the calling LLM reads and walks step-by-step. On the MCP tool surface there is no run-blueprint tool: the connected agent IS the runner. (A separate headless SDK runner can drive a saved blueprint unattended for platform-initiated runs such as schedule/event/webhook triggers, replay, and backtests — see docs/blueprint-runner-sdk.md — but it does not change how you read-and-walk this recipe.) Each step description names the primitive to invoke and the data flowing through.

A blueprint is read-and-walk. MCP-connected agents READ the recipe via agent_blueprint://list (or agent_blueprint://<id>, or the blueprints coarse tool get), walk the step graph, and call the named primitives directly. On the MCP tool surface the platform does not execute the recipe for you — you walk it. (For unattended/scheduled/backtest runs the headless SDK runner walks a saved blueprint server-side instead; see docs/blueprint-runner-sdk.md.) This starter is the canonical reference for the read-and-walk path.

What it produces

Per persona in the supplied directory:

• One content_piece artifact with the channel's appropriate format (LinkedIn short-take, LinkedIn long-form, single tweet, or numbered X thread).
• The piece's content_json.draft_markdown carries the full body (or full thread as one string with explicit 1/, 2/, ... numbering).
• metadata.variant_key = the persona key, metadata.campaign_tags includes multi-persona-social-launch.
• One or more content_grounding children per piece with verbatim customer quotes the draft cited.

Then a synthesis envelope:

• posting_order — recommended sequence across a 2-hour drop window with minutes_after_drop per persona.
• strongest_draft — the single best draft with a 1-line rationale.
• weak_drafts — any persona whose draft is materially weaker than the others, so the team can decide to skip.
• piece_ids — the N created piece ids in directory order.

Required tenant context

The blueprint needs two context entries before you can run it:

Persona directory

A context_entry enumerating the personas that should each get a draft. Recommended type prefix: persona_directory or launch.<slug>.persona_directory. Body shape:

{
  "personas": [
    {
      "key": "ceo",
      "display_name": "Pat Founder",
      "role": "CEO",
      "author_id": "<author_profile uuid>",
      "manifest_entry_id": "<context_entry uuid>"
    },
    ...
  ]
}

Each manifest_entry_id points at a per-persona voice manifest (its own context_entry) carrying the voice fingerprint, recurring phrases, signature move, and optionally a prompt-pack array.

Campaign config

A context_entry typed campaign.<slug>.config (or any type — the blueprint reads it via id). Body shape:

{
  "campaign_name": "Alice launch",
  "campaign_slug": "alice",
  "tone_tagline": "...",
  "counter_positioning": "...",
  "non_negotiables": ["NEVER say X", "Always Y", ...],
  "narrative_pillars": [...],
  "shared_anchor_quotes": [
    { "text": "...", "speaker": "...", "company": "...", "source": "..." }
  ],
  "verified_customers": ["Acme Co", "Globex Inc", ...]
}

The non_negotiables array is enforced verbatim in every draft. The verified_customers array is the only source of customer names the drafter can invent — anything else must come from substrate or external evidence.

Inputs

How it runs

Top-level steps:

1. load_directory — read the persona directory context_entry.
2. warm_topic_cache — one external_search.execute(action=enrich_topic) call on the topic so per-persona drafts hit warm cache (~30s saved per persona on the external_search arm).
3. fanout — parallel loop over personas, gathering per-persona context (voice manifest, campaign config, substrate clusters) in parallel.
4. draft_per_persona — parallel loop, one llm step per persona authoring the post in voice, channel-aware (LinkedIn 300/800-1500 words; X 280 chars or 3-7 numbered tweets).
5. create_pieces — sequential loop, one artifacts.create per persona materializing the content_piece. Body is populated in the create call with status: drafting so the piece never lingers in placeholder.
6. attach_all_citations — nested parallel loop attaching content_grounding children per citation.
7. transition_to_ready — sequential loop, artifacts.update per piece flipping drafting → ready with metadata.review_status: approved.
8. publish_check — branch on final_status: if ready, skip publishing; if published (default), sequential loop transitioning ready → published.
9. synthesize — llm step ranking posting order and picking the strongest draft.

Channel rules

The drafter's prompt encodes per-channel budgets so the LLM picks the right format automatically:

• LinkedIn: short-take under 300 words, long-form 800-1500 words, comment under 400 chars. Format is chosen from the persona's prompt-pack hint or by the LLM if no pack matches.
• Twitter / X: single tweet under 280 chars, OR a thread of 3-7 numbered tweets (1/, 2/, ... n/) each under 280 chars. Carousels and long-form convert into threads. The draft_markdown output is the full thread as one string with explicit numbering — the team copies and posts each numbered tweet manually (no auto-poster).

Validators that travel with content_piece writes

The two cross-cutting validators apply here (see draft_piece.md for full detail):

1. draftBodyRequired — pieces past placeholder must carry a body. This blueprint goes straight to drafting in the create_pieces step with the body already populated, so the rule is satisfied without an intermediate placeholder.
2. calendarPlanGate (OPT-IN) — this blueprint never opts in. Pieces are unparented and the gate stays off. Editorial flows that want batch approval should use plan-and-draft-window instead.

Important caveat

final_status: published writes status: published on each Amdahl content_piece artifact. It does NOT auto-post to LinkedIn or X. Pieces land in Amdahl marked as published; your team still copies the body out and posts manually. If you need a real LinkedIn / X publisher integration, that's a separate hook — file a request and we'll wire it.

Reference implementation

This starter generalizes the multi-persona pattern that powered the 11x Alice launch. The original tenant-fork blueprints (3 chained recipes that did the same thing per-tenant) are now collapsed into this single platform starter. Any tenant with a persona directory + campaign config can drive a coordinated drop without forking — just read the recipe and walk it with the four required inputs.