Fundamentals · Read 8 min

The six levels of context in AI: the ladder that decides whether your assistant remembers or improvises

There is no single way to "give context" to a model. There is a ladder with six rungs, from a loose prompt to a vector database. Here I show you which one you need and why climbing too high also has a price.

When people say "you have to give the AI context," they talk as if it were a single thing. It is not. Managing context is a ladder with six rungs, and each one solves a different problem: from pasting a file into the chat to training a dedicated model. Climbing one rung too high costs money and complexity. Falling short makes your assistant improvise. Here I show you the full ladder, so you know exactly which rung to stop on.

The short answer, for those in a hurry: most people and teams live happily between level 1 and level 4. You only reach vector databases or dedicated models when the volume of information stops fitting inside the model's head. And it almost never pays to start at the top.

01 · the rungThe six levels, at a glance

Before we get into the detail, take in the whole ladder. Each rung does not replace the previous one: it embraces it. A good level 5 system still uses prompts (level 1) underneath.

Figure 1 · the context ladder
1 · A prompt or file 2 · Projects with several files 3 · Agents, subagents and skills 4 · Vaults and summary headers 5 · Vector databases (embeddings) 6 · Fine-tuning / dedicated model volume and cost ▲
Each rung adds capability, but also cost and complexity. The healthy rule: climb only when the rung below can no longer keep up.

02 · the groundLevel 1: one prompt, one file

The starting point is pasting information directly into the conversation: a long prompt, or an attached file. Here is a rule almost no one tells you: format matters. A plain text or Markdown (.md) file is ideal, because the model reads it as is, clean. A PDF, a Word doc or a photo add noise: the text has to be extracted, and along the way come optical character recognition (OCR) errors, badly ordered columns, broken tables. You are feeding the model with dirt still stuck on.

The other limit of level 1 shows up as the conversation grows. Many people believe "the model forgets" or "gets tired." That is not it. The model does not lose its base weights, that huge network of knowledge it was trained with stays intact. What degrades are the instructions you placed in the context: as the conversation stretches out, those directions get diluted among thousands of new words.

The model does not forget what it knows. What gets diluted is what you just told it.

There is even a phenomenon with its own name: lost in the middle. Models pay more attention to what is at the beginning and the end of the context, and less to what sits in the center [1]. So a key piece of data buried halfway through a long document can go unnoticed, even though it is technically "inside" the window.

Practical trick

If something is critical, put it at the beginning or the end of your message, not in the middle of a huge block. And whenever you can, hand over the source as clean Markdown instead of a scanned PDF. You save the model a decoding job in which mistakes get made.

03 · the projectLevels 2 and 3: chats born trained and agents that get instantiated

Level 2 appears when you go from a loose chat to a project. Tools like Claude Projects or ChatGPT projects let you load several files and a fixed set of instructions, so that every new chat is born already trained with that material. You do not have to paste the context again each time: it lives in the project and travels with every conversation you open inside it.

Level 3 raises the stakes: these are AIs that no longer just converse, but that write code for and instantiate others. Enter agents (an assistant with a mission and tools), subagents (agents that another agent launches for specific tasks) and skills (reusable packages of instructions and capabilities). Here context stops being a pasted file and becomes an architecture: who knows what, who delegates to whom. And, note this, all of this is still done with Markdown: .md files are the common language used to describe agents and skills.

04 · the clutterLevel 4: when 20 files fill your window

An uncomfortable moment arrives. You have, say, twenty files with no clear structure, and together they fill the context window. The model drowns: too much information competing for its attention, and once again the "lost in the middle" problem. Cramming it all in at once stops working.

The level 4 solution is not more memory, it is better organization. Three key pieces:

Skills and vaults. Instead of always loading everything, you group knowledge into modules that activate when they are needed. The vault is the storeroom; the skill is the instruction that knows when to open it.

Summary headers per file. On top of each document you place a short summary of what it contains. That way the model can read only the headers, decide which files are useful, and open in depth only those. This is what is called progressive disclosure: showing the minimum first, and going deeper only on demand.

It is not about the model reading more. It is about it reading just enough, in just the right order.

Figure 2 · progressive disclosure
Without structure 20 files opened at once → window full With summary headers Reads 20 short summaries Opens only 3 in depth Progressive disclosure keeps the window light: the model goes deep only where it is worth it.
A summary header per file turns twenty heavy documents into a light index that the model can scan before deciding what to read in full.

05 · external memoryLevel 5: vector databases, no magic and no SQL

When the information is so much that it does not even fit in indexes and summaries, it is taken out of the context and stored outside, in a vector database. This is the heart of what they call RAG (retrieval-augmented generation). Let us go step by step, because confusing explanations abound here.

First comes chunking: splitting the documents into manageable pieces (paragraphs, sections). Then, for each piece an embedding is computed: a list of numbers that represents its meaning. Texts that say similar things have embeddings that are close in that numerical space, even if they use different words.

When you ask a question, your question is also turned into an embedding, and the system looks for the pieces whose vectors resemble it most. That comparison is done by similarity: typically cosine similarity (the angle between two vectors) or a nearest neighbors search. Let us clear up a common misunderstanding: this is not "SQL plus equations" in the literal sense of a traditional database. It is a search by semantic resemblance, not by exact matching of fields.

A useful technical nuance: those vectors are not always stored raw. They are compressed, with quantization techniques (storing the numbers with less precision) or dimensionality reduction (using fewer numbers per vector). You lose a touch of fidelity in exchange for the search being much faster and cheaper at scale.

The idea in one sentence

A vector database is an external memory that retrieves by meaning. Instead of feeding the model all the documents, you hand it only the three or four pieces that most resemble the question. The window stays light and the answer rests on real sources.

06 · your own modelLevel 6: fine-tuning, and why it is almost never the first step

The last rung is fine-tuning: continuing to train a model with your own data to get a dedicated one. It sounds like the definitive solution, but a nuance that saves a lot of money is in order: fine-tuning adjusts behavior more than it injects knowledge. It works to fix a tone, a format, a response style or a very specific task. It is not the best path for "loading in" fresh or changing data, because every time the information changes you would have to retrain.

For knowledge that changes, RAG first. Fine-tuning is for shaping how it answers, not what it knows.

That is why the practical recommendation, almost a mantra in the industry, is RAG before fine-tune: if your problem is that the model needs data it did not have, a vector database (level 5) usually solves it better, cheaper and without retraining. Fine-tuning comes in when what fails is behavior, not knowledge.

07 · the ceilingThe frontier: enlarging the window yields less and less

And why not simply make giant context windows and put everything inside? Because that is where the field's real frontier lies, and it is not free. Optimizing an AI system is a balance among three things: serving (delivering answers fast and to many users), the window size and the available compute. All three pull in opposite directions.

And enlarging the window has diminishing returns. Doubling the context does not double the quality: the compute cost grows fast, and the old problems reappear (lost in the middle, dilution of instructions). That is why the answer to "I need more context" is almost never "a bigger window," but "better context management": the ladder we have just walked through.

08 · in practiceWhere Qirava fits on the ladder

All of this is not lab theory: it is exactly the problem faced by anyone who wants their AI to remember their work. Qirava is designed to accompany that ladder in an orderly way, without abrupt jumps. It starts where you start, with the vault (level 4): a place where your knowledge lives organized, with summary headers so the AI reads just enough. As that knowledge grows, the natural path is to add finer summaries and, when the volume calls for it, take the step to vector retrieval (level 5).

It does not promise you a dedicated model or level 6 magic from day one, because almost no one needs it at the start and promising it would be selling you smoke. It promises you something more useful: climbing the ladder one rung at a time, when it is truly needed, without overpaying for complexity you are not going to use. That is, in the end, the only healthy way to give context to an AI.

Sources

  1. Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F. & Liang, P. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics (TACL), vol. 12, pp. 157-173. ACL Anthology: aclanthology.org/2024.tacl-1.9.
  2. Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems (NeurIPS) 33, pp. 9459-9474. (Origin of the RAG approach.)
  3. Anthropic (2024). Introducing Contextual Retrieval. anthropic.com/news/contextual-retrieval. (Chunking, embeddings and retrieval in practice.)
  4. Ouyang, L., Wu, J., Jiang, X. et al. (2022). Training Language Models to Follow Instructions with Human Feedback. NeurIPS 35. (Fine-tuning adjusts behavior more than knowledge.)

Learn more about AI

See all Learn AI