MBM
An AI-powered child support and storytelling platform. Structured prompt architecture that holds narrative coherence, emotional safety, and age-appropriate responses across every session. 18 weeks.
What We Delivered
The Situation
The demo looked good. A child selects a mood. Chooses a story theme. The AI generates. Then around page three, something shifts. The story forgets where it was heading. A character introduced in the opening appears with a different name. The emotional thread quietly unravels. In a consumer app, that sounds like a UX problem. In a product built for children navigating their feelings, it is a safety failure you can hear in the silence when a child stops trusting the story.
-
Story drift across generation steps
Stories that began with clear theme and character logic would quietly lose coherence over multiple generation steps. The AI generated disconnected content, not inappropriate content. But a child who feels the story losing its thread stops believing in what comes next.
-
Ignored session parameters
A child who selected a short story received a long one. A child who chose an adventurous tone received something sedate. The AI acknowledged inputs and proceeded to ignore them. Inconsistently.
-
Tone mismatch in emotional chat
The chat assistant, receiving inputs from a child expressing difficulty, would sometimes respond accurately and warmly, sometimes in a way that felt clinically detached. That inconsistency is something a child senses before they can name it.
-
Image misalignment
Generated visuals did not consistently reflect the current story state. Illustrating scenes that had passed, characters introduced differently, or settings bearing only a loose relationship to the narrative.
-
Context loss in the AI layer
The early architecture treated each generation step as largely independent. As the context window filled, original parameters were outweighed by generated content.
The gap between "the AI produces plausible output" and "the AI produces reliably correct output" is exactly where the difficulty lives. The solution was not a better content filter. It was a different architecture.
The Approach
Phase 1
Diagnostic: Where Context Gets Lost
The first question in the technical conversation: "How is the AI currently receiving context about the child's session, and at which point does that context get lost?" That question diagnosed the problem before the solution existed.
Context attention analysisThe model was not forgetting parameters. It was being outweighed by generated content. The parameters from the first request no longer carried enough weight against the third chapter. You could see it happening. The original instructions fading like a voice drowned out in a crowd.
Architecture decisionThe fix was not better parameters. It was restructuring how context travelled across the entire session so the model's attention was continuously directed back to what mattered.
With the root cause identified, the team could build the structured prompt architecture that would eliminate drift, not just reduce it.Phase 2
Structured Prompt Architecture
Empyreal implemented a prompt architecture separating three distinct phases of the MBM experience, each with its own context management logic.
Layer 1: Emotional support chatDedicated system prompt establishing the assistant's persona, emotional register, and safety boundaries. Isolated from story generation to prevent logic bleed between modes. When a child tells the assistant they feel sad, the response needs to land with warmth every single time.
Layer 2: Story planningBefore any story text is generated, the system creates a structured plan: characters, themes, narrative arc, key beats, emotional throughline. This plan travels with every subsequent generation call. The plan is the anchor. Everything else moves around it.
Layer 3: Story generationEach generation step receives both the story so far and the persistent plan. The prompt architecture foregrounds the plan's parameters at every call. When plan and generated content conflict, the plan wins.
Image alignment fixImage generation calls receive the current story plan state, not just current chapter text. The dragon from chapter one looks the same in chapter four. A child who sees that consistency feels it as trust.
The architecture eliminated drift structurally. The next challenge was ensuring the safety layer matched the same standard of reliability.Phase 3
Child Safety Architecture
The safety architecture was built to a standard beyond content filtering. Content-level safety used OpenAI's moderation capabilities. Behavioural safety was the harder and more important problem.
Sensitive input handlingThe system does not attempt to handle things it is not equipped to handle. It acknowledges. It validates. It redirects warmly toward trusted adults. It does not attempt to be a therapist. That boundary sounds simple. Holding it reliably across thousands of unpredictable inputs is not.
Edge case testingExtensive prompt testing against the kinds of inputs real children provide. Not clean test cases, but the unexpected phrasings and sideways inputs that arrive when a child is trying to say something they do not have words for.
Behavioural guardrailsExplicit response logic for sensitive inputs built into the system prompt architecture. Lines drawn between responses the system must always provide with care and inputs it must never attempt to handle.
Phase 4
Flutter App and Backend Build
Flutter for native mobile experience. Node.js backend serving as the orchestrator of context state, not simply a relay between app and API. MongoDB for session data, conversation histories, and persistent plan objects.
Flutter child-facing UIMood selection, story theme journey, and emotional chat interface designed to feel warm, considered, and age-appropriate. A child opening this app should feel welcomed before they tap a single button.
Node.js orchestration layerThe backend holds the story plan, tracks session parameters, and ensures every generation call is assembled correctly. That orchestration layer is where the architectural solution lives.
MongoDB session managementUser sessions, conversation histories, story content, and persistent plan objects managed through a document model that allows the same record to carry all states through its lifecycle.
The Numbers
The structured prompt architecture eliminated story drift, maintained parameter fidelity across sessions, and delivered the emotional safety a child-facing product demands. The AI works reliably, not just in demos.
Mohit's Take
"The hardest part of this build was not technical. It was the safety architecture. There are responses the system must never provide and inputs it must always handle with care. The line between those categories is not always sharp. Building the architecture that navigates it reliably, not just in testing, not just most of the time, but reliably, required the most careful work and the most honest conversation with the client about what was achievable and what was not. We tested against inputs no clean test suite would generate. Because children do not speak in test cases."
— Mohit Ramani, Founder & Lead Architect, Empyreal Infotech
Tech Stack
The toolchain behind the MBM platform.
Start a Conversation About Your Product
You are building a product where AI interacts with vulnerable users. You know the demo works. What you may not know is whether the architecture will hold when the inputs stop being predictable and the stakes of getting it wrong are measured in trust, not metrics.
A discovery call with Empyreal is thirty minutes. You describe the product. Empyreal listens, asks the questions that reveal the safety and reliability decisions you have not made yet, and gives you an honest read on what it would take to build it correctly.