On this page
The Shift in Software Production
AI has collapsed the cost of building software. What used to require a funded team and a multi-month roadmap now takes one operator who has designed the right system. However, the cost that did not collapse is the cost of judgment, taste, and the discipline required to operate what you build.
I am currently building Inky, an AI storytelling app. It is a product within the Total Ventures portfolio, designed as a permanent-equity asset. It is not a side project or a temporary experiment. It is a digital property built to keep.
Building an AI story app in the current market requires a move away from the "wrapper" mentality. If your product is just a text box that sends a prompt to an inference provider, you do not own a business; you own a UI for someone else's model. To build something with durable value, you have to architect a system where the AI is the workforce, not just the feature.
The Architecture of an AI-Native Product
When building an AI story app, the architecture must be designed around state management and orchestration rather than just generation. Inky is built on a shared engine that allows me to run multiple properties from a single monorepo. The goal is to create a machine that executes the work while I allocate the capital and attention.
State Management Over Generation
The most common mistake I see is relying on the model to remember the story. Models drift. Context windows are finite. If you want a coherent narrative that spans chapters, you cannot leave the state in the prompt.
I learned the hard way that the narrative must be anchored in a relational database. Every character attribute, plot point, and world-building constraint is stored as structured data. The AI agents read from this state, generate the next branch of the story, and then write the updated state back to the database. The model is the engine, but the database is the map. This ensures that a character who is wearing a red cloak in chapter one isn't wearing a blue one in chapter four because the model forgot the initial context.
The Orchestration Layer
Inky uses a custom orchestration layer to manage the workforce. This is what I call agentic engineering. Instead of one massive prompt trying to do everything, I have specialized agents for specific tasks: one for narrative pacing, one for dialogue consistency, and one for world-state validation.
This layer acts as the operating system for the product. It handles the escalation paths. If an agent produces an output that violates the world-state—such as a character being in two places at once—the system catches the error and re-routes the task. This reduces the amount of manual oversight I have to provide, allowing the machine to operate autonomously.
