Journey 2

Creating content.

Briefing the crew. Watching the three-agent pipeline run live over SSE. What ends up saved to the database.

Open the crew chat

The crew chat lives at /crew. You see a conversation list on the left, a message panel in the middle, and the input at the bottom. The four agents are represented by colored avatars (amber Strategist, violet Writer, cyan Editor, emerald Analyst).

The crew chat — empty state with suggested prompts

Send a brief

Type a brief like “Write a LinkedIn post announcing our Q3 launch.” Hit enter. The frontend opens an SSE stream (EventSource via fetch + getReader) to the backend, which routes the message through intent detection. Keywords like “write,” “draft,” or content types trigger the full pipeline; otherwise a single agent answers.

Watch the pipeline run

A pipeline stepper appears at the top: Strategy → Drafting → Review. The active agent’s avatar glows in its assigned color. Text streams character-by-character as each agent generates its response.

The crew chat showing the Strategist → Writer → Editor pipeline output

What each agent does:

Strategist (amber) — proposes 2–3 angles, each with a name, one-line description, and rationale.
Writer (violet) — drafts 3 variants of the content, one per angle. Each variant has a title, format, word count, body, and craft notes.
Editor (cyan) — scores each variant against the brand voice (0–100) and provides 2–3 feedback points.

Content gets saved automatically

At the end of the pipeline the orchestrator parses Writer’s output and Editor’s score, then writes a ContentItem + ContentVariant rows to Postgres (Neon in prod, SQLite in dev). A confirmation card with “Open in editor →” appears in the chat. The orchestrator never blocks on the save: even if persistence fails, the chat output stays in the message log.

Note —Each agent’s system prompt is a structured list of text blocks (base personality + cached org context). The org context block carries cache_control: ephemeral, so once the cached prefix exceeds 1024 tokens, subsequent calls in the same chat pay ~10% of the original input-token cost. This is the prompt-caching pattern described in the Builder’s Playbook.

Per-executive ghostwriting

If the brief includes “as Sarah” or “in Jane’s voice,” the orchestrator extracts the name with a regex, looks up the matching ExecutiveProfile in the org’s memory, and passes the profile to the Writer as a per-call kwarg (not instance state — that was a concurrency hazard, now fixed). The Writer’s system prompt gets an additional cached block with the exec’s bio, communication style, and sample quotes.

Honest limitations

Variant body parsing has a real bug. The Writer wraps each variant body in --- delimiters and the orchestrator regex-extracts them. When the model formats slightly differently, the parser sometimes captures the “Craft Notes” section instead of the body. Fix in roadmap: replace regex with a submit_variants tool that forces structured output.
The pipeline is sequential, not parallel. Strategist blocks Writer, Writer blocks Editor. End-to-end latency is the sum of all three calls. Parallel evaluation (e.g. Editor reviewing all 3 variants concurrently) is straightforward but not yet wired.
No real evaluator-optimizer loop. Editor’s feedback is currently read-only. The Writer doesn’t revise based on the score. A 2-iteration loop is on the roadmap (issue #5 in the lessons-learned deck).
Intent detection is keyword-based. Ambiguous briefs like “should I write about engagement” can be misrouted. An LLM-router (Haiku-based, ~$0.0002/call) replaces this in the roadmap.

Editing & approving →

Picking a variant, sending for review, the approval queue.