IgniteEngine

One dial, 16 AI specialists (Sparks), infinite creative range. IgniteEngine turns Slack into a self-directing content studio, orchestrated by Woodpecker.

Comment

Inspiration

Most AI creative tools give you one shot — one prompt, one output, take it or leave it. We wanted something that felt more like a real production pipeline: a single concept that gets progressively developed by different specialists, the way an actual animation/VFX studio passes an idea from writer to art director to producer. Slack felt like the natural home for this — it's already where creative teams talk, so why not let the pipeline live there too?

What it does

IgniteEngine is a Slack-native creative production pipeline for animation/VFX concepts. At its core is Woodpecker, an orchestrator that chains together up to 16 specialist persona-agents called Sparks — each handling a different facet of production: story, dialogue, visual style, character design, color, pacing, genre, branding, marketing copy, casting, budget, and trend research.

An entropy dial (1–16) controls how deep the pipeline goes:

  • Entropy 1–4 (Core): Oak (script), Willow (style), Birch (dialogue), Cedar (critic)
  • Entropy 5–8 (Extended): + Maple (character), Elm (palette), Aspen (pacing), Rowan (genre)
  • Entropy 9–12 (Production): + Hazel (audience), Juniper (interactive story branching), Sandal (logo concept), Larch (taglines)
  • Entropy 13–16 (Specialist): + Alder (trend scout, MCP-connected), Mahogany (voice casting), Chestnut (budget estimate), Agar (wildcard twist)

Each Spark's output feeds forward as context into the next, so by the time you reach the critic or branding Sparks, they're reviewing the fully-developed concept — not just the raw idea you started with.

A 17th agent, Pinecone, isn't part of the creative chain at all — it's a hardcoded, unbypassable content safety check that runs after every single Spark output at every entropy level, returning only a SAFE/BLOCK verdict.

How we built it

  • Orchestration logic (Woodpecker): decides which Sparks to run based on the entropy value and chains their outputs as sequential context
  • 16 Spark personas: each implemented as its own prompt-engineered agent with a narrow, well-defined role
  • Slack-native UX: slash commands (/ignite, /ignite-agent) for triggering runs, interactive buttons for Juniper's choose-your-path story branching (A–E), and a 🔁 Reroll button on every Spark's output so you can regenerate one piece without rerunning the whole pipeline
  • First-time onboarding: a greeting workflow that fires on hi/hello/hey or via the Home tab, so new users get the full Spark roster without needing docs
  • Two-layer safety: a soft content-ceiling instruction prepended to all 16 Sparks' prompts, plus Pinecone as the hard, code-level backstop that can't be skipped by chain configuration
  • MCP groundwork: Alder (the trend-scout Spark) is designed as the MCP-connected agent for real-time trend search

Challenges we ran into

  • Context management across 16 chained agents — making sure each Spark's output stayed genuinely useful as input to the next, without the chain drifting off-topic or repeating itself as entropy increased
  • Balancing creative freedom with safety — designing a content ceiling that doesn't strangle creative output but still gives Pinecone a hard, reliable BLOCK condition
  • Making the interactive story mode (Juniper) a real pause/resume loop driven by actual Slack button clicks rather than faking multi-turn conversation
  • Sandbox setup — had to use the Empty template to avoid Slack's placeholder-user invite cap during testing

Accomplishments that we're proud of

  • Getting all 16 Sparks chained end-to-end through a single orchestrator, with each one genuinely building on the last instead of running in isolation
  • A real hard-coded safety layer (Pinecone) that can't be bypassed by chain configuration, alongside a softer prompt-level content ceiling
  • A genuinely interactive Slack experience — Juniper's branching story runs on real button clicks, and every Spark output is individually rerollable

What we learned

  • How much orchestration complexity comes from context management once you're chaining more than a handful of agents — later Sparks needed carefully scoped context, not the full raw history
  • The value of separating "soft" and "hard" safety layers rather than relying on prompt instructions alone
  • Slack's sandbox quirks (like the placeholder-user invite cap) that aren't obvious until you hit them

What's next for IgniteEngine

Wiring a live MCP server into Alder for real-time animation/VFX trend data, and expanding the Extended and Production tier Sparks based on which entropy levels get used most.

Built With

  • gpt-oss-20b
  • groq
  • mcp
  • python
  • slack-api
  • slack-block-kit
  • slack-bolt
  • slash-commands
Share this project:

Updates