Building an AI Story App: Systems and Lessons from Inky

I am shipping Inky today. It is a storytelling application built on a multi-agent architecture. This is not a wrapper around a single prompt; it is a system designed to handle narrative consistency, character state, and world-building across long-form sessions.

When you are building an ai story app, the challenge isn't getting the LLM to write. The challenge is getting the LLM to remember that the protagonist lost their sword three chapters ago. Most people try to solve this with a larger context window. I learned the hard way that context is a blunt instrument. You need a system.

The Architecture of a Narrative Engine

Inky runs within my studio's monorepo. I treat AI as the operating layer, not just a feature. The architecture relies on what I call agentic engineering—a series of specialized agents that handle specific domains of the story.

Instead of one massive call to Claude or Gemini, the system breaks the request down:

1. The Archivist: Manages the long-term memory and state. It queries a vector database for relevant lore and character facts.

1. The Architect: Outlines the structural beats of the scene based on the user's input and the current narrative arc.

1. The Author: Generates the prose, constrained by the Architect's structure and the Archivist's facts.

1. The Critic: Reviews the output for hallucinations or contradictions before it ever reaches the user.

This modularity allows me to swap models based on the task. I use Claude 3.5 Sonnet for the Author agent because of its nuance in prose, while Gemini 1.5 Pro handles the Archivist role due to its massive context handling during the initial ingestion of world bibles.

Why a Monorepo Matters for Solo Operators

I run a multi-product studio. I do not have a team of engineers. I have a system of agents and a single codebase that houses every product I ship. Building an ai story app inside this monorepo means Inky shares the same authentication, billing, and deployment logic as my other tools.

This reduces the surface area of what I have to manage. When I update the VERA orchestration layer—the custom agent system I built—every product in the studio gets smarter. I am not building one-off apps; I am building an integrated ecosystem.

Agentic Engineering Over Prompt Engineering

Prompt engineering is a temporary skill. Agentic engineering is a structural one. When building an ai story app, you quickly realize that a single prompt cannot handle the complexity of a branching narrative.

I built VERA to handle the hand-offs between agents. If the Critic agent finds a contradiction—say, a character who died appearing in a tavern—it triggers a recursive loop. The Architect must revise the scene, and the Author must rewrite it. This happens in the background, invisible to the user, ensuring that what is shipped to the screen is coherent.

This approach requires a shift in how you think about code. You are no longer writing deterministic functions; you are designing feedback loops. You are an architect of systems, not an author of one stack.

Lessons Learned the Hard Way

Building in public means being honest about what broke. Early in the development of Inky, I relied too heavily on the LLM to manage its own state. I assumed that if I told the model the character's inventory, it would keep track of it.

It didn't.

I learned the hard way that LLMs are prone to "state drift." After a few thousand tokens, the model starts to prioritize the most recent instructions over the foundational ones.

To fix this, I moved the state management out of the LLM and into a structured SQL database. Now, the agents query the database for the current state, use it to generate the narrative, and then send a command to update the database. The LLM is the engine, but the database is the steering wheel.

The Money Layer: Profit Before Hype

I build for durability. Inky is designed to be profit-first. This means monitoring token usage with the same intensity that a traditional SaaS monitors server costs.

By using smaller, specialized models for the Critic and Archivist agents, I reduced the cost per story generation by 40%. I am not interested in burning VC cash to find a product-market fit. I am interested in building a sustainable business that supports my family and my craft.

Working in Public

I am sharing the progress of Inky because the process is the product. The lessons I learn while building an ai story app apply to every other agentic system I deploy. Whether it is a logistics tool or a music production assistant, the patterns of memory, state, and orchestration remain the same.

I am not a fan of the hype cycle. I don't care about the latest leaderboard unless it changes how I ship today. I care about the artifact. I care about the commit. I care about the system that works when I am not sitting at the keyboard.

If you are building something similar or want to look under the hood of the VERA orchestration layer, I am happy to talk.

Next Steps

You can follow the development of Inky and the rest of the studio's products through the Builder's Playbook. It is where I document the specific implementations of these agentic systems.

Full implementation in The Builder's Playbook — justintsugranes.dev/resources/builders-playbook