Google's AI Writing Tool Fabula Demoed at CHI 2026, but It's Been Around for Over Half a Year

The CHI 2026 Demo

On April 15, 2026, the official Google Research X account posted:

Meet Fabula: an interactive AI writing tool helping authors structure & refine stories. Co-designed with 42 expert writers, the demo showcases how convergent iteration supports creativity.

At the Google booth during CHI 2026 (ACM Conference on Human Factors in Computing Systems) in Barcelona,
Piotr Mirowski demoed “Fabula: a Narrative Storytelling Sidekick” starting at 10:30.

At first glance it looks like a new announcement, but Fabula didn’t just appear for the first time here.

It’s Been Around for Over Half a Year

Here’s the public timeline for Fabula.

Date	Event
May 17, 2025	At the Open Research Day at Battersea Arts Centre in London, Google DeepMind’s Piotr Mirowski demonstrated LLM-assisted creative writing. Presented in the context of a collaborative project with playwright Natalia Korczakowska
Around Sep 2025	Mirowski posted “Introducing Fabula” on LinkedIn, officially unveiling the prototype. Early access recruitment for the research prototype began
Around Dec 2025	Another LinkedIn post, “Announcing early access to Fabula,” broadened the early access invitation
Apr 15, 2026	Presented as an interactive demo at the Google booth at CHI 2026
May 13, 2026 (scheduled)	A writing workshop using Fabula planned at Anglia Ruskin University in the UK

In other words, by the time Google posted “Meet Fabula,“
about 7 months had passed since the initial announcement and about 4 months since the early access rollout.
The CHI 2026 appearance was a demo at an academic conference, not a general availability (GA) launch.

What Is Fabula

Fabula is an AI writing tool for fiction writers developed by Google DeepMind.
Built on the Gemini model, it primarily targets screenwriters and playwrights.

Feature	Details
Co-designed with 42 professional writers	Screenwriters, playwrights, TV producers, and narratology experts participated
Story structure based on classical narratology	Manages stories through a hierarchy of scenes and beats (the smallest unit of a scene)
Multi-level editing	Regenerate and revise at varying granularity, from the entire script down to individual story plan elements
Support for diverse writing styles	Workflows adapted to improvisational, architectural, and hybrid creative processes

Fabula isn’t a tool that auto-generates finished stories.
It’s a “narratology sidekick” that supports writers as they explore, structure, and refine their narratives.

Lineage from Dramatron

Fabula isn’t Google DeepMind’s first AI creative writing tool.
Its predecessor is Dramatron.

Dramatron’s arXiv preprint was published in 2022 and it was formally presented at CHI 2023.
The paper title: “Co-Writing Screenplays and Theatre Scripts with Language Models: An Evaluation by Industry Professionals.”
Led by Piotr Mirowski and Kory Mathewson, it was evaluated through collaborative writing with 15 film and theater professionals.

Dramatron’s key technique was “prompt chaining” —
generating title, characters, story beats, locations, and dialogue in sequence,
passing each stage’s output as context for the next to maintain consistency across long-form scripts.

graph TD
    A[Logline<br/>One-line summary] --> B[Title generation]
    A --> C[Character setup]
    C --> D[Story beats<br/>Scene skeleton]
    D --> E[Location descriptions]
    E --> F[Dialogue generation]
    
    style A fill:#4a90d9,color:#fff
    style F fill:#e67e22,color:#fff

Fabula inherits Dramatron’s design philosophy while evolving in several ways.

	Dramatron	Fabula
Base model	LLMs of the era	Gemini
Scope	Screenplays and plays	Fiction in general
Design participants	15	42
Approach	Prompt chaining	Convergent Iteration
Design philosophy	Generative AI	Formative AI
Presented at	CHI 2023	CHI 2026

Convergent Iteration and Formative AI

A key emphasis in Fabula’s design is convergent iteration.

Traditional generative AI tools centered on a divergent flow: put in a prompt, get output.
Fabula prioritizes the process of writers repeatedly narrowing down and revising AI output.
From the overall story plan down to scene-level beats,
writers iteratively regenerate, select, and discard across different hierarchical levels to “converge” on a work.

The other keyword is formative AI.
While generative AI focuses on “AI creates,“
formative AI takes the stance of “AI helps shape human creation.”
For Fabula, this means not outputting a finished product,
but functioning as a tool for writers to discover their own stories.

CHI (the premier HCI conference) is a venue for discussing human-AI interaction design,
making it a fitting stage for drawing this distinction.

Not GA

As of April 2026, Fabula remains at the research prototype stage.
Early access is invite-only, with no announcements about general availability or productization.

Google Research’s “Meet Fabula” post was announcing a booth demo at an academic conference,
not a product launch.
On the CHI 2026 program, it was registered under the “Interactive Demo” track,
not as a peer-reviewed full paper.

On the Google creative AI front, Flow is available at the product level for image and video generation,
but in the text creation space, Fabula remains in the research phase.
A workshop at ARU is coming up in May, and development continues within the research community,
but there are no signs of it being added to Google Labs or productized.

What Does It Actually Do

“Supporting the creative process” sounds vague —
hard to see how it differs from asking ChatGPT to “write me a story.”
Mirowski himself stated clearly on LinkedIn:

Fabula is not a story generator — it is a tool to empower a writer as they go through the creative process of exploring their story

“Not a story generator.”
So what does it actually do?

Two-Layer Structure: Story Plan and Script

Fabula manages stories across two layers.

Layer	Content
Story Plan	A structured outline composed of scenes and beats (the smallest unit of development within a scene). Character settings and narrative arcs are also included here
Script	The actual text based on the story plan. Dialogue, stage directions, descriptions, etc.

When you ask ChatGPT or Gemini to “write a novel,“
you get flat text in a single block.
Context window limitations make it hard to maintain consistency across long-form works.

Fabula persistently maintains the “skeleton” of a story plan,
so the overall coherence is preserved even when individual scenes or beats are modified.
Nick Lowe’s classical narrative theory (The Classical Plot and the Invention of Western Narrative)
forms the basis of this structural design.

Regeneration at Different Granularities

Fabula’s core capability is regenerating and editing at different levels of the story.

graph TD
    A[Overall story arc] --> B[Scene structure]
    B --> C[Individual scene beats]
    C --> D[Script<br/>Dialogue and descriptions]
    
    A -.->|Regenerate| A
    B -.->|Regenerate| B
    C -.->|Regenerate| C
    D -.->|Regenerate| D
    
    style A fill:#4a90d9,color:#fff
    style D fill:#e67e22,color:#fff

Want to change just the ending of a scene?
Regenerate only that scene’s beats while keeping the surrounding scenes intact.
Changed a character’s backstory?
Selectively regenerate only the affected beats and script sections.

Trying to do the same in ChatGPT means
re-pasting the full text into the prompt with every change,
or manually checking consistency.

The Convergent Iteration Flow in Practice

Here’s what convergent iteration looks like as a concrete workflow.

graph LR
    A[Idea input] --> B[AI: Present multiple<br/>plan candidates]
    B --> C[Writer: Select<br/>and request edits]
    C --> D[AI: Regenerate<br/>revised version]
    D --> E{Satisfied?}
    E -->|No| C
    E -->|Yes| F[Move to next layer]
    
    style A fill:#27ae60,color:#fff
    style F fill:#e67e22,color:#fff

1. The writer inputs a logline (one-line story summary) or idea
2. Fabula generates multiple story plan candidates
3. The writer selects preferred elements and requests modifications
4. Fabula generates a new version reflecting the changes
5. This cycle repeats until the writer is satisfied
6. Once the story plan is solid, move to the script layer and repeat the same cycle

In contrast to the typical generative AI “divergent” flow (prompt -> output -> different prompt -> different output),
this converges on a single work through repeated selection and revision.

Comparison with ChatGPT / Gemini

	ChatGPT / Gemini direct use	Fabula
Story structure management	None (flat text)	Hierarchical scene and beat structure
Partial editing	Must specify in prompt each time	Can regenerate specific layers only
Consistency maintenance	Depends on context window	Story plan is always referenced
Writer style support	None	Improvisational, architectural, hybrid
Data handling	May be used for model training	Non-training under Vertex AI governance

Fabula is a dedicated structural editor with narratology theory built in.
Writers delegate structure, development, and consistency management to AI within their writing process.

That said, no UI screenshots or demo videos have been publicly released.
The actual user experience is known only to invite-only early access users.
The most concrete example we have is playwright Natalia Korczakowska using Fabula
during preparation for her Warsaw production (September 2025 premiere, “AlphaGo_Lee. Theory of Sacrifice”).

---

What struck me going through all this is that
you could build something close to this architecture yourself.

The two-layer structure of story plan and script,
regeneration at each layer with convergent iteration —
at its core, this is a pipeline that passes structured context to an LLM for partial regeneration.
Dramatron’s prompt chaining is exactly that:
the sequence of generating logline -> characters -> beats -> dialogue
can be reproduced by chaining API calls.

Fabula’s evolved “convergent iteration” also boils down to
building a UI that runs a candidate presentation -> user selection -> differential regeneration loop,
with model API calls and context management on the backend.
The narratology-based scene/beat hierarchy
can be expressed in JSON or YAML and included in the system message prompt.

The problem is on the model side.
Fabula is built on Gemini,
but Gemini’s content filters don’t play well with fiction writing.
There are reports of safety filters blocking generation
when stories deal with violence or dark themes.
For a tool targeting professional writers,
not being able to write battle scenes or depictions of inner conflict is a dealbreaker.

The mechanics of LLM safety filters and how different providers approach them are covered in
a separate article,
but Gemini sits on the stricter end among commercial cloud LLMs.
How much of a problem this poses for a creative writing tool
depends on how much Fabula internally relaxes those filters,
which isn’t discernible from public information.

If you build your own, you get to choose the base model.
Claude handles violent fiction descriptions better than Gemini,
and local LLMs let you control filters entirely.
Borrowing just the idea of a “structured narrative editor”
and picking the model yourself is the more practical path.

Building Your Own

Fabula’s core breaks down into story plan persistence, layer-by-layer partial regeneration,
and a candidate presentation -> selection -> regeneration loop UI.
All achievable with existing LLM APIs and frontend frameworks.

Overall Architecture

graph TD
    UI[Frontend<br/>Next.js / Astro etc.] --> API[API Server<br/>Node.js / Python]
    API --> LLM[LLM Provider<br/>Claude / GPT / Gemini / Local]
    API --> DB[Story DB<br/>SQLite / PostgreSQL]
    DB --> SP[Story Plan<br/>Scene and beat structure]
    DB --> SC[Script<br/>Dialogue and descriptions]
    DB --> CH[Character settings]
    DB --> HIS[Generation history<br/>Candidates and selection log]

    UI -->|Selection and edit requests| API
    API -->|Return multiple candidates| UI

    style UI fill:#27ae60,color:#fff
    style LLM fill:#4a90d9,color:#fff
    style DB fill:#e67e22,color:#fff

The key point is placing a story plan database between you and the LLM,
rather than hitting the LLM directly.
Every LLM request includes the relevant portion of the story plan as context,
so even scene-level regeneration doesn’t break overall coherence.

Keep generation history around,
and you can implement branch-like operations:
“go back to the candidate from three iterations ago and fork from there.”

Story Plan Data Model

Story plans are expressed in JSON or YAML.
Here’s an example of the scene-and-beat hierarchical structure.

{
  "title": "Work Title",
  "logline": "One-line summary",
  "characters": [
    {
      "name": "Protagonist",
      "role": "protagonist",
      "description": "Personality and background",
      "arc": "Direction of change"
    }
  ],
  "scenes": [
    {
      "id": "scene-1",
      "title": "Opening",
      "setting": "Place and time",
      "beats": [
        {
          "id": "beat-1-1",
          "type": "action",
          "content": "What happens",
          "characters": ["Protagonist"],
          "locked": false
        },
        {
          "id": "beat-1-2",
          "type": "dialogue",
          "content": "Gist of conversation",
          "characters": ["Protagonist", "Other"],
          "locked": true
        }
      ]
    }
  ]
}

Beats with locked: true are excluded from regeneration.
Writers fix the parts they like,
and only the rest gets regenerated by the AI.
This is the mechanism that makes convergent iteration’s “convergence” work.

Partial Regeneration Pipeline

Here’s the flow when regenerating a specific scene.

graph TD
    A[User: Want to<br/>regenerate Scene 3] --> B[API fetches target scene<br/>and adjacent scenes]
    B --> C[Attach character settings<br/>and logline]
    C --> D[Convert locked beats<br/>to constraints]
    D --> E[Send prompt<br/>to LLM API]
    E --> F[Generate 3 candidates<br/>varying temperature]
    F --> G[Present candidates to user]
    G --> H{Accept?}
    H -->|Select and revise| I[Add edit instructions and resend]
    I --> E
    H -->|Accept| J[Update story plan]
    J --> K[Check consistency<br/>of subsequent scenes]

    style A fill:#27ae60,color:#fff
    style J fill:#e67e22,color:#fff

Information to include in the prompt:

• Logline and overall arc
• Settings for characters involved
• Final beat of the previous scene (contextual continuity)
• Opening beat of the next scene (landing point constraint)
• Content of locked beats (elements that must not change)
• User’s edit instructions

With this much context,
the LLM can return coherent output
even without seeing the entire scene.
Context window size becomes a problem
when passing an entire novel at once,
but scene-level regeneration fits within a few thousand tokens.

Base Model Selection

Unlike Fabula, building your own means choosing your base model freely.
Here’s a comparison of model characteristics for fiction writing.

Model	Filter tolerance	Long-form quality	Context length	Cost
Claude Opus / Sonnet	High. Handles violence and dark themes in fiction contexts	Known for natural prose. Strong in Japanese too	200K tokens	API token billing
GPT-4o / Codex	Moderate. Adjustable via system prompt	Top-tier for English	128K tokens	API token billing
Gemini Pro / Ultra	Strict. Hard to relax safety filters	Good long-form consistency	1M-2M tokens	API token billing
Local LLM (Llama etc.)	No restrictions. Filters can be removed entirely	Depends on model size	Model dependent	GPU electricity only

In fiction writing,
“not getting blocked by filters” becomes the top priority in some situations.
Battle scenes, crime depictions, psychologically dark themes —
when story-essential elements get rejected by the model, work grinds to a halt.

Claude (Anthropic)
tends to handle violent depictions when it’s clear the context is fiction.
Writing “This is an assistant for novel writing” in the system prompt
gets most fiction expressions through.

OpenAI’s GPT-4o and Codex
offer relatively wide adjustment range through system prompt role settings.
Using the Responses API,
you could delegate story state management to the API side,
potentially eliminating some of the need for your own DB management.

Gemini has an overwhelming context window length advantage,
but faces a handicap in fiction writing freedom.
The fact that Fabula runs on Gemini suggests
Google has likely tuned the filters internally,
but whether external API users get the same benefit is unclear.

Local LLMs have zero filter constraints.
Running 7B-70B models like Llama 3 or Mistral
through ollama or similar,
you won’t be bothered by model response restrictions.
However, output quality scales with parameter count,
so long-form consistency and character voice differentiation
may fall short of cloud API models.

Minimum Viable Implementation

If you’re actually building this, the minimum stack looks roughly like this.

graph LR
    A[Minimum stack] --> B[Frontend<br/>React / Svelte]
    A --> C[Backend<br/>Express / FastAPI]
    A --> D[DB<br/>SQLite]
    A --> E[LLM<br/>Claude API]

    B --> F[Feature 1<br/>Story plan<br/>editor]
    B --> G[Feature 2<br/>Candidate<br/>comparison view]
    B --> H[Feature 3<br/>Script<br/>preview]

    style A fill:#4a90d9,color:#fff

Prompt engineering is the heart of this system.
Embedding narratology knowledge into prompts
is the equivalent of Fabula’s “co-design with 42 writers.”
Define scene structure templates
and beat type classifications (action / dialogue / revelation / conflict etc.)
in the system prompt,
constraining the model to output according to that structure.

Switching models isn’t hard either.
Each provider’s API has a different request format,
but wrappers like LiteLLM or Vercel AI SDK
absorb provider differences.
You could even route by scene type —
dark scenes to Claude,
long consistency checks to Gemini’s massive context —
as a viable strategy.

Fabula is interesting as a research prototype,
but with no GA and no way to use it,
building a tool with the same design philosophy locally is faster.
All the pieces are already there.