Context-Aware AI: How RapidNative Remembers Your Project

If you've used a general-purpose AI chat assistant to build an app, you've met the same wall. The first screen looks great. The second screen references a type you defined on turn one, and the model has forgotten what it looked like. By turn ten, it's inventing fields, overwriting your database schema, and importing a navigation library you removed three turns ago.

Context-aware AI is the engineering answer to that failure mode. It's the difference between a chatbot that gives you a plausible snippet and a coding agent that can hold twenty files, a Postgres schema, a navigation graph, and your personal naming conventions in its head for a full session — and come back next week and pick up where it left off.

This post is a deep technical walkthrough of how RapidNative's context-aware AI works end to end: how we persist message history, how we rebuild the project's virtual file system on every turn, how the agent "sees" your live database schema, and how we spend our token budget so a 50-screen app doesn't exhaust the context window on turn five.

Context-aware AI holds entire project state across turns — Photo on Unsplash

What is context-aware AI, in one paragraph?

Context-aware AI is a coding agent that reconstructs the full state of your project — files, database schema, prior decisions, user preferences — before every single turn, so the language model can reason about your code and not a generic template. In a modern AI mobile app builder like RapidNative, this means persistent message history, a per-request virtual file system, live schema introspection, and token-aware compaction working together.

That is the 40-second answer. The rest of this post is what each of those words actually means in production.

Why most AI coding agents lose the thread

An LLM is stateless. Call it twice with the same prompt and you get the same answer; its "memory" is whatever text you cram into the next request. That is the entire mental model. Everything called "AI memory" is actually orchestration code around a stateless function call.

The naive version is: ship the user's latest message. The model has no idea your project exists.

The next step up is: ship the last N messages. This is what browser-based chat assistants do by default. It works for a joke and a limerick. It breaks the moment the LLM needs to know what User.ts looks like on turn 40 and the file definition scrolled out of the window on turn 12.

The step after that is RAG — retrieval augmented generation. Chunk the codebase, embed each chunk, retrieve top-k on each turn, paste the top chunks into the prompt. This is better. It is also wrong for a project you're actively building. RAG assumes a stable corpus you're querying. A project under active edit is a corpus that mutates every single turn, and semantic-nearest-neighbor retrieval has no idea which chunks are stale.

RapidNative's answer is different. We don't retrieve from a snapshot. We rebuild the project's live state into the agent's working set every turn, and we give the model shell-grade tools (ls, cat, grep, db_describe) so it can go find anything the standing context doesn't already cover. The LLM stays stateless. The orchestration layer around it is where the project lives.

The four-layer context architecture

Our context pipeline has four cooperating layers. Think of them in order of decreasing persistence.

The two "per request" layers are the key design decision. They mean every turn starts from the authoritative, on-disk truth of your project — not a cached guess, not a vector-index approximation. We'll go through each layer.

Context is reconstructed layer-by-layer on every turn — Photo on Unsplash

Layer 1: Persistent message history and compaction

Every message you ever send and every tool call the agent ever makes is written to a Postgres messages table. When you open a project, the editor layout fetches the complete history in parallel with files and project metadata — one query per concern, hydrated into Redux state, done before the first paint of the chat panel.

That part is the easy part. The hard part is what happens when the history grows.

A single modestly-sized project can accumulate 200+ turns of back-and-forth. Each turn might include a user message, a planning step, five to ten tool calls (each with full file contents in its result), and an assistant response. Even on a model with a 1M-token context window, you cannot naively feed that back in every request. You will go broke and you will blow past the cache.

Our compaction logic triggers once input tokens cross 50% of the model's context limit. A fast model (we use the same provider's planning tier) is handed the entire prior conversation and asked to produce a single compact message — one summary that preserves the five things that actually matter across turns:

• The screen inventory (what routes exist, what each one does)
• The database schema (tables, policies, keys)
• The navigation structure (tabs, stacks, modals)
• Bug fixes already made (so we don't re-introduce them)
• The user's stated preferences and unfinished work

The compact message is tagged with a thread_id that points at the uncompacted messages that preceded it. On the next generation, we read compact + anything newer instead of the entire history. The old messages stay in the database — they just don't ride into the model's context anymore.

This is cheaper than RAG. It's also smarter: a summary written by an LLM that just read the whole conversation knows which decisions were superseded by later ones. A vector index does not.

Layer 2: The virtual file system the agent reads every turn

Here is the part that catches most people building their first AI app builder: the LLM does not actually "remember" your files. It never has. On every turn, we build a fresh virtual file system, seed it with your project's current state, hand the agent a shell inside it, and the agent reads what it needs.

The VFS is a thin interface — list, read, write, delete, seed — with three implementations. One runs in Node for CLI testing, one runs in memory for unit tests, and one runs against the Lifo kernel VFS at /home/user/app for production. The agent code has no idea which implementation it's talking to. That isolation is why we can run the exact same production agent against a real directory from a Node script for debugging, with nothing but the storage adapter swapped out.

The seed sequence is strict. We load your stored project files from project_files first, then overlay the template files. The template never clobbers something you've written — that's the ordering invariant. If you deleted a file on turn 30, it stays deleted.

There's one more wrinkle. On a cold start of a legacy project with no persisted file rows yet, we replay the write operations from prior assistant messages to rebuild the VFS. That reconstruction only runs on cold start — after the first successful write, the database is authoritative. If you reverted a file manually, we won't resurrect it from history.

Once the VFS is seeded, the agent gets a bash tool. Not a sandboxed wrapper, not a scripted interface — bash. It can ls app/(tabs), cat lib/supabase.ts, grep -r "export default" components, pipe through sed, whatever it wants. We've written before about the virtual file system behind multi-file AI code generation — this is the piece of context-aware AI that most other builders stop short of. Giving the model a real shell is what turns "has memory" into "can go find anything in your codebase on demand."

The agent navigates your project with real shell tools — Photo on Unsplash

Layer 3: Live database schema awareness

Fullstack apps are where context awareness earns its keep. If the agent doesn't know your database shape, it will invent columns on screen generation, write RLS policies that reference nonexistent tables, and generate TypeScript types that don't compile. We learned this the hard way.

Our data layer is SQL-first. The project owns supabase/migrations/*.sql at the repo root. There is no JSON representation and no hand-authored TypeScript schema that could drift. Every migration is applied against an in-memory PGlite instance — real Postgres running in WebAssembly — before the file is written. If the SQL doesn't apply cleanly, if an RLS policy fails type-checking, if a column type is wrong, the migration never lands and the model sees the error as feedback for the next tool call.

The agent gets four read-only tools on top of this: db_tables enumerates the current tables, db_describe dumps one table's columns, policies, and indexes, db_sql runs read-only queries (including information schema), and db_migration_new applies and validates new SQL. On every turn, the system prompt also carries a one-line-per-table compact summary — users(3 cols, RLS: public), todos(5 cols, RLS: owner). That costs roughly four tokens per table, so a 20-table app still fits in under 100 tokens of standing context. The agent pulls full details only when it needs to touch a specific table.

The key design detail is that this isn't a stored description. It's introspection against the engine. Rename a column via a migration and the next db_describe call shows the new name. The schema view and the actual engine cannot drift because they are the same engine. The regenerated mobile/src/db/types.ts lands in the VFS so the frontend code and the agent's schema view both update in the same atomic turn.

This matters for context awareness because it closes the loop. The agent doesn't remember the schema — it reads it, every single turn, from the thing that will actually run.

Layer 4: Static system prompts and prefix caching

The system prompt holds the project's writing conventions, the full tool documentation, and the pre-loaded skill library. It's long — several thousand tokens — and it never changes within a session. That's intentional. Modern LLM providers charge dramatically less for cached prefix tokens, and the way to maximize cache hits is to keep the first chunk of every request byte-identical.

We have exactly two prompt variants per template: a first-message version with every skill pre-loaded (password reset flows, social login, payment integration, image uploads), and a follow-up version with only the core skills. The follow-up variant saves about 6K tokens on every subsequent turn. Beyond that, the prompt is a constant.

Everything that genuinely varies per project — the current schema summary, your prior messages, the file list — comes after the static prefix. The LLM reads the same first N tokens every time and the provider's cache does the heavy lifting. We've measured round-trip times at a fraction of what they'd be if we rebuilt the prompt from scratch each turn, and the compounding effect across hundreds of thousands of generations a week is substantial.

The planning pass that reads your existing project

Before the main agent runs, we fire a separate planning model. It's smaller, faster, and tuned to produce one structured output: a plan with sections for TABLES, SCREENS, LAYOUT, THEME, DESIGN, SEED, and DEFERRED work. On a first message, the plan says "create the app with this structure." On a follow-up, the plan says "modify the existing app per this diff, do not overwrite these screens."

That follow-up framing is the context-aware part. The planning model is given the current project state — the existing screens, the schema summary, the user's new ask — and its job is to produce a plan that respects what already exists. It explicitly names the screens the main agent is forbidden to overwrite. That alone eliminates a class of regression where follow-up prompts quietly rewrote work the user was happy with.

The planner's thinking tokens stream to the frontend in real time, so the user sees activity before any file writes start. More importantly, the plan itself gets injected into the main agent's system prompt as a binding directive, which keeps the agent anchored to the project it's inside rather than drifting toward a fresh-template default.

Context awareness turns one-shot generation into an iterative workflow — Photo on Unsplash

What this means for your workflow

Day to day, you don't think about any of this. You type add a settings screen with dark mode toggle and it works. You come back three days later, say the login button on the welcome screen should navigate to signup instead, and the agent knows which screen you mean and what the component is called.

The practical consequences of a context-aware AI are:

• Reference anything by name. "The onboarding screen," "that table we added yesterday," "the color we were using for primary" — the agent can resolve all of those because the VFS and the schema are available to it.
• No re-prompting your conventions. Preferences you've expressed earlier survive compaction and get summarized into the compact message. You don't repeat yourself.
• Edits don't regress. The planning model sees existing screens and marks them off-limits unless the user asks for changes.
• Follow-ups are cheap. The follow-up prompt variant and prefix caching mean a turn 50 generation is roughly as fast as turn 2.

If you're coming from one-shot code generators, this is the step change. RapidNative isn't a prompt-to-snippet tool with chat on top. It's a stateful agent with a four-layer context architecture that happens to expose itself as a chat interface. That architecture is why you can take a project from first prompt to the App Store and Google Play without rewriting the whole thing three times along the way.

Frequently asked questions

Does RapidNative use RAG for context?

No. RAG assumes a stable corpus you're querying, which a project under active construction isn't. Instead, we rebuild the virtual file system from authoritative storage on every turn and give the agent shell tools to navigate it. That gives us always-fresh retrieval and avoids the stale-chunk problem that embeddings-based retrieval has when files change constantly.

How does the model handle very long projects without blowing the context window?

Two mechanisms. First, we compact the conversation history once input tokens cross 50% of the model's limit — a summarizer condenses prior messages into a single compact message that preserves schema, screens, and unfinished work. Second, the agent only pulls full file contents and full schema details on demand through its tools; the standing context carries only a lightweight summary.

What's the difference between episodic and semantic memory in this architecture?

Episodic memory is the message history (what happened turn by turn), and we persist it in Postgres with optional compaction. Semantic memory — the stable knowledge the agent needs — lives in the static system prompt and the pre-loaded skills library. Procedural memory (how to do things) lives in the tools themselves. Separating them is what lets us cache the semantic layer aggressively while keeping the episodic layer flexible.

Is this specific to React Native and Expo?

The context architecture itself is template-agnostic, but each template (fullstack-supabase, nativewind-themed, fullstack-v2) ships its own system prompt and tool defaults. In practice RapidNative generates production-ready React Native and Expo code, so the context layer is tuned for that stack — but the pattern (persistent history + per-turn VFS + live schema + static prompt) generalizes to any coding agent.

Ready to try a context-aware AI mobile app builder? Start building your first app in natural language. 20 free credits, no credit card.