Inspiration
Fenoa started from a simple idea I kept coming back to:
What if a story did not have only one continuation?
A creator could write the setup, publish it, and someone else could take the same characters in a completely different direction.
Maybe one person continues the story normally.
Another changes one decision.
Someone else introduces a new character.
Another person takes Episode 2 and turns it into a completely different branch.
That sounded much more interesting to me than treating a story like one fixed document.
Most writing tools are still built around a fairly linear workflow. You write something, edit it, and eventually publish the final version. Even with AI, the interaction is usually still "ask for some text, copy the text, edit the text."
I wanted Fenoa to feel more like a living network of short fiction.
A creator can publish a short story or mini-drama, and the community can keep branching it into new versions without destroying the original.
While building that, another problem became obvious.
Once stories start branching, continuity gets difficult very quickly.
Who knows which secret?
Which characters trust each other?
What rules are still true?
Did something already happen in another episode?
What did the original creator say should never change?
That is why Fenoa also keeps structured story state underneath the writing.
The reader mostly sees the story.
But underneath it, Fenoa understands the characters, relationships, facts, rules, constraints, episodes, and branch history.
That structure also turned out to be a very natural fit for WebMCP.
What it does
Fenoa is a social platform for short fiction and remixable stories.
Creators can build a fictional setup, turn it into a short story or mini-drama, publish it, and let other people create their own branches from it.
The simplest way to think about it is:
Create a story → publish it → remix it → branch it again.
A Fenoa world can contain:
- a premise
- genre and tone
- characters
- relationships
- important facts
- secrets
- rules
- story constraints
- locations
- a story spark
A creator can write all of this manually.
There is also a built-in Creative Partner that can help develop the idea. For example, a creator can start with a rough concept and ask the Creative Partner to help build characters, motivations, relationships, tensions, and rules.
The important part is that the AI output does not stay trapped inside a chat message.
When the creator chooses to apply it, Fenoa turns the useful parts into real structured story data that can still be edited manually.
Creators can also generate artwork for their story and publish it.
Once published, another person can start a remix.
A remix is a new branch of the story. It inherits the original context, but it can develop in its own direction.
For example:
- continue the original story
- change an important event
- introduce a new character
- switch point of view
- create a darker or funnier version
- turn one moment into a larger mini-series
- remix an existing remix
The original story is never overwritten.
Each branch keeps its own creative direction, episodes, branch-specific characters, rules, constraints, and lineage.
Short stories and mini-dramas
I did not want Fenoa to become a long-form novel editor.
The format is intentionally closer to short fiction and episodic mini-dramas.
A branch can contain a small sequence of episodes, each focused on one clear development in the story.
That makes remixing much more approachable.
Someone does not need to read a 100,000-word novel before contributing something.
They can understand the setup, read a few short episodes, and take the story somewhere new.
I think this also fits the way people already consume creative content online.
Shorter stories are easier to discover, easier to share, and much easier to remix.
The Creative Partner
Fenoa has a built-in Creative Partner for both world creation and remix development.
It is meant to feel more like a collaborator than an automatic "write everything for me" button.
A creator can ask it to:
- suggest possibilities
- challenge an idea
- connect existing story elements
- resolve continuity problems
- build structured story content
For example, during the demo I start with a fairly simple comedy idea.
The Creative Partner helps turn that into actual characters, motivations, relationships, world rules, and story material.
Later, inside a remix, it can also help create episodes around a new direction.
The creator can then open those episodes and change them manually.
That combination was important to me.
AI can move the story forward, but the human never loses control of the work.
Remix Studio
Remix Studio is where a branch becomes its own story.
It brings together three things:
- The episodes being written
- The Creative Partner
- The current story context
The story context matters because a remix is not just another blank prompt.
It inherits information from the story it came from.
That can include:
- characters
- relationships
- facts
- story rules
- constraints
- branch-specific changes
- episode history
A creator can also add decisions that should remain true inside the branch.
For example, a character might not be allowed to know a certain secret yet, or a specific fact may need to remain true throughout the story.
Those decisions become part of the branch state instead of living only inside someone's memory or prompt history.
Why WebMCP matters in Fenoa
This is probably the part of the project I found most interesting technically.
Fenoa already had a structured representation of the story.
WebMCP gave me a way to expose that meaning directly to browser agents.
Without something like WebMCP, an agent interacting with a creative app would often have to inspect the page, understand the UI, find the correct buttons, and infer what the visible text means.
That is possible, but it is a very indirect way of working with the product.
In Fenoa, the page can expose semantic tools instead.
The current WebMCP tools are:
| Tool | What it does |
|---|---|
get_branch_state |
Reads the current remix and its story state |
get_episode |
Reads one episode together with its version and relevant constraints |
update_episode |
Updates an existing episode |
move_episode |
Changes episode order |
add_branch_character |
Adds a character specifically to the current remix |
set_story_constraint |
Adds a constraint that the story should respect |
update_branch_rule |
Adds, changes, or removes a branch-specific rule |
Publishing is intentionally not exposed as an agent action.
That remains a human decision.
A shared story state
The part I cared about most was making sure WebMCP was not a completely separate automation layer.
Fenoa has three different ways a story can change:
- the human editor
- the built-in Creative Partner
- a WebMCP client
All three work on the same underlying story state.
For example, a person can edit Episode 1 manually and add a story constraint.
A WebMCP client can then read the branch and see that latest state.
It can read Episode 2, including its current version and relevant constraints.
It can then update Episode 2.
The Remix Studio reflects the change because the WebMCP action is modifying the same real branch that the human is working on.
There is no separate copy of the story created just for the agent.
That was one of the main architectural goals of the project.
How we built it
Fenoa is built with Next.js, React, and TypeScript.
Firebase is used for:
- authentication
- Firestore
- realtime data
- Cloud Storage
- production hosting
Firestore realtime listeners are especially useful inside Remix Studio because changes can appear without requiring the user to manually reload the story.
The Creative Partner uses OpenAI's Responses API.
I use structured outputs and validation before applying AI-generated changes.
I did not want the model to have direct freedom to write arbitrary data into Firestore.
The AI suggests or builds structured changes, and those changes still go through Fenoa's normal domain logic.
World artwork is generated separately with Gemini and stored in Cloud Storage.
For native WebMCP, the tools are registered directly on the page with:
document.modelContext.registerTool(...)
There is no separate MCP server acting as a substitute for WebMCP.
The tools are part of the browser experience itself.
Architecture decisions
One decision I made early was that WebMCP should not get a privileged shortcut directly into the database.
The human interface and WebMCP actions both use the same application/domain operations.
That means validation still applies regardless of whether the change came from a human or an agent.
Episode updates also use version checking.
For example, a WebMCP client reads Episode 2 at version 3.
If the human changes that episode before the client writes its update, the stored episode might now be version 4.
The old update can then be rejected instead of silently overwriting the newer human work.
This became especially important once I started thinking of Fenoa as a shared human-agent workspace rather than just an AI story generator.
Challenges we ran into
The hardest part was not generating stories.
Story generation itself is relatively easy now.
The difficult part was making multiple ways of editing the same story behave consistently.
A creator can change something manually.
The Creative Partner can apply a structured change.
A WebMCP client can also change the branch.
All of those paths need to agree about:
- current versions
- validation
- inherited story information
- branch-only changes
- constraints
- what should and should not be editable
WebMCP itself also took some debugging.
The browser needed the correct native WebMCP testing setup before document.modelContext was available.
I also had to verify that the production page was actually registering tools correctly and that those tools were reading the real persisted branch, rather than just returning some local representation.
Another challenge was figuring out what not to expose.
It would have been easy to create a generic tool that lets an agent write anything.
I intentionally avoided that.
The tools are fairly narrow and semantic.
An agent can update an episode or add a branch character, but it does not get unrestricted access to the database.
Publishing also stays human-only.
The UI was another challenge.
Earlier versions exposed too much information at once and started feeling more like a technical dashboard.
Fenoa has quite a lot happening underneath, but the product should still feel like a place for stories.
I spent a good amount of time simplifying the experience and keeping the technical complexity behind the scenes.
Accomplishments that we're proud of
The thing I am most proud of is that the WebMCP demo is connected to the real product.
The production Fenoa page registers native WebMCP tools.
Those tools can be discovered from the browser.
They can read the current persisted remix.
They can read an existing episode.
They can perform a version-checked update.
That change then appears back inside the live Remix Studio.
It is not a mocked console response.
I am also happy with the remix model.
The original story stays untouched while every branch can develop its own identity.
A remix can introduce characters, change rules, create new episodes, or eventually become the starting point for another remix.
The other part I am proud of is the structured story model itself.
AI-generated characters and story ideas do not disappear once the chat is over.
They become part of the same editable system that the creator and future remix authors continue working with.
What we learned
The biggest thing I learned from this project is that giving an agent access to a website and giving an agent understanding of a website are very different things.
An agent can potentially click around almost any interface.
But if the website can directly tell the agent:
"This is the current branch."
"This is Episode 2."
"This is the version you are editing."
"These are the constraints that matter."
"This is the safe operation for changing the episode."
then the interaction becomes much cleaner.
That is what made WebMCP interesting to me.
I also learned that structured AI output is much more useful when it becomes durable product state.
Generating four fictional characters is easy.
What becomes interesting is when those four characters now exist in a system where relationships, secrets, episodes, constraints, humans, and agents all refer to the same characters later.
Another lesson was to keep the user-facing idea simple.
Fenoa has quite a lot of technical machinery underneath it, but the reason someone would actually use it is much simpler:
They found a story they liked and thought,
"What if it happened differently?"
What's next for Fenoa
The first thing I would like to improve is discovery.
If Fenoa grows, I want opening the app to feel like exploring a constantly branching library of short fiction and mini-dramas.
You might find a story you like, see its most popular remix, then notice that someone created an even stranger branch from Episode 2.
I also want to make story lineage much more visual.
A successful story could eventually look like a tree:
- original story
- continuation
- alternate ending
- comedy remix
- darker remix
- new-character branch
- remix of that remix
I think seeing how an idea evolved could become part of the experience itself.
Another direction is deeper agent collaboration.
For example, different agents could eventually specialize in different tasks:
- continuity checking
- character consistency
- alternate plot exploration
- pacing
- branch comparison
But they would still operate on the same structured story state and respect the same creator decisions.
Longer term, the idea I want to keep exploring is simple:
Stories should not always have one final version.
They can become things people build on together.
Log in or sign up for Devpost to join the conversation.