Skip to main content

The invisible engine: Reactor inside your own product

The idea: use Reactor as a headless, on-brand content brain that lives inside your own systems (your app, your agent, your CI, your CMS) and never publish through Reactor at all. Instead of Reactor being the place you go to make content, it becomes the invisible layer that guarantees any content your systems generate is on-brand and slop-free.

Everything in Reactor is exposed over the MCP server, authenticated by a workspace API key. That means "generate on-brand content" is just an API your code can call, with the entire brand engine (voice, positioning, audiences, rules, and the anti-slop machinery) applied on every call, automatically.

Raw LLM call vs. the invisible engine​

This is the whole pitch in one comparison. Both produce text; only one is defensible.

  Your app ──▶ raw LLM API ──▶ generic text
                                (slop: no voice, no context, no dedup, drifts to the model's mean)

  Your app ──▶ Reactor MCP ──▶ on-brand text
                                (your voice + positioning + audiences + writing rules,
                                 checked against what you've already produced)

When your systems call a raw model, every team and every feature reinvents "the prompt," and quality drifts. When they call the engine, brand and anti-slop are enforced in one place, so the release notes your CI writes, the in-app copy your product generates, and the replies your support agent drafts all sound like the same company.

What "content" means here​

Publishing is optional. The valuable move is often to get_content and consume the result in your own surface:

  • Product & marketing site: generate feature blurbs, changelog entries, and landing copy from your own build pipeline.
  • In-app: personalized onboarding messages, empty-states, or nudges, on-brand without a copywriter in the loop.
  • Support: draft macro responses in your voice for a human to approve.
  • Lifecycle email: generate the body, hand it to your own ESP or app to send.
  • Agents: give your internal agents a create_brief → generate_content → get_content tool so anything they write for customers inherits the brand.

Step 1: connect from your own service​

Mint a key in Settings → API keys and point any MCP-capable client or your own code at https://reactor.tools/api/mcp with Authorization: Bearer <key>. See Install the MCP for client configs (Claude Code, Codex, Cursor, custom).

The key scopes every call to your workspace, so the engine your code talks to is your engine.

Step 2: generate headlessly and consume the result​

The minimal loop your service runs:

1. create_brief          // topic + any context specific to this surface
   // topic: "Changelog entry: background jobs are now 3x faster"
   // brief_md: "Factual, understated, developer audience. One paragraph."
2. generate_content      // briefId
3. get_generation_status // Poll until done
4. get_content           // Take the markdown/JSON and render it wherever you want

No publish_now, no calendar, no channels. You took on-brand text and used it in your own product.

:::tip Ground each surface with a document For surfaces with their own context (a specific feature, a support policy), upload_document once so generation is grounded, or pass the specifics in brief_md. Grounding is what keeps generated in-app copy accurate as well as on-brand. :::

Step 3: the same anti-slop guarantees, invisibly​

Everything that keeps Reactor's own content from sounding like AI applies to these headless calls too, with nothing extra to wire up:

  • Your writing rules ride every generation, so your app's auto-written copy avoids the em-dash-and- "delve" tells by construction.
  • Voice, positioning, and audience are applied on every call: the model starts from your brand, not from a blank prompt.
  • The similarity guard keeps generated variants from repeating each other, so ten personalized onboarding messages read as ten messages, not one template with the name swapped.

That's the point of an invisible engine: the quality bar is enforced centrally, so every system that calls it clears the bar without each team having to become prompt engineers.

Step 4: keep the brain sharp​

Because it's one engine, improving it improves every surface at once. Tune it with the feedback loop. The release notes, in-app copy, and support drafts your systems generate all get better the moment you update_voice or sharpen your writing rules. One update, everywhere.

The payoff​

Reactor doesn't have to be a destination. As an invisible engine it turns "on-brand, non-generic content" into an API your whole stack can call, so brand consistency and anti-slop stop being a per-team discipline and become infrastructure. Your customers never see Reactor; they just notice your product sounds like it was written by people who care.

Back to scheduled generation, or wire up a client in Install the MCP.