I am currently building an ai story app called Inky. It is not a wrapper for a single LLM call. It is a multi-agent system designed to handle narrative arcs, character consistency, and world-building state.
Most people think building an ai story app is about finding the right prompt. It isn't. It is about engineering the feedback loops between agents. I have been working in public on this project for several months, and the lessons learned the hard way have shaped the architecture of my multi-product studio.
The Artifact: Why Inky Exists
Inky is a digital product designed to solve the problem of narrative drift. When you ask a standard LLM to write a story, it loses the plot—literally—around the 2,000-word mark. Characters change eye color, dead villains reappear, and the pacing collapses.
To solve this, I stopped looking at AI as an author and started looking at it as a team. In my studio, AI is the operating layer. For Inky, this means agentic engineering: a system where one agent outlines, another drafts, a third audits for consistency, and a fourth manages the long-term memory (state).
Moving Beyond the Prompt: Agentic Engineering
When you are building an ai story app, the prompt is the least interesting part of the stack. The real work is in the orchestration. I built a custom layer called VERA to handle this. VERA doesn't just send a string to an API; it manages a state machine.
The Orchestration Layer
In the Inky architecture, the process is broken down into discrete steps:
- The Architect Agent: Takes the user's seed idea and builds a structural outline. It defines the 'beats' of the story.
- The Lore Master: A dedicated agent that maintains a JSON-based 'World Bible.' If a character is established as left-handed in chapter one, the Lore Master ensures they don't throw a spear with their right hand in chapter ten.
- The Weaver: This is the drafting agent. It only sees the current beat and the relevant snippets of the World Bible.
- The Critic: An audit agent that compares the Weaver's output against the Architect's outline. If the beat was missed, the Critic triggers a retry.
This is agentic engineering in practice. It is not about one 'smart' model; it is about a system of specialized instruments working in concert.
The Stack: Choosing Instruments, Not Credentials
I don't care about being an expert in a specific framework. I care about what allows me to ship today. For Inky, the stack is built for speed and durability.
- Monorepo Architecture: I run a single monorepo for the entire studio. This allows me to share the VERA orchestration logic across multiple products.
- Claude API & Gemini: I use Claude for its nuance in prose and Gemini for its massive context window when I need to ingest entire world-building documents.
- Firebase & Supabase: I use these for real-time state management and auth. They are utilities, not identities.
- MCP Servers: I’ve integrated Model Context Protocol servers to allow my agents to read and write directly to the project's filesystem during the development phase.
I am an architect of systems, not an author of one stack. If a better tool for building an ai story app emerges tomorrow, I will swap it in. The system is the value, not the syntax.
Learned the Hard Way: Context and Consistency
Building this has not been a linear path. I learned the hard way that context windows are a trap. Just because a model can take 200k tokens doesn't mean it should.
When you cram an entire story into one context window, the model's attention thins. The middle of the story becomes a blur. I found that 'chunking' the narrative and using a RAG (Retrieval-Augmented Generation) approach for the World Bible produced significantly higher-quality prose.
Another lesson: Profit before revenue. It is easy to build a high-latency, high-cost AI app that looks impressive but loses money on every generation. I spent three weeks optimizing the token usage of the Critic agent because it was the biggest bottleneck in the unit economics. Shipping today means shipping something that is sustainable.
Operations Without a Team
I run this studio as a solo operator, but I don't work alone. AI is the team. While I am architecting the core logic of Inky, agents are handling the documentation, monitoring the error logs, and even drafting the initial technical briefs for new features.
This is the shift from being a developer to being an operator. I am not writing every line of code; I am directing the flow of information through a system I built. This allows me to maintain a multi-product studio without the overhead of a traditional headcount.
Shipping Today: The Path to Production
Inky is currently in a closed beta. We are testing the limits of the Lore Master agent and refining the latency of the Weaver. The goal isn't to 'disrupt' publishing—it's to build a tool that works for people who have stories to tell but lack the system to organize them.
If you are building an ai story app, stop focusing on the LLM and start focusing on the state. The magic isn't in the model; it's in the feedback loops.
I am happy to talk about the specifics of the VERA orchestration layer or the monorepo structure I use to keep these projects lean.
Work through this in a 1:1 strategy session through Total Ventures — totalventures.io/booking
Studio Notes
How I’m building the studio.
The operator’s log — systems, decisions, and what’s working.
Written by
Founder, Total Ventures
Solo-founder building a multi-brand product studio with AI agents. Writing about building, operating, and shipping.



