# How should a model get your company's knowledge?

> Do you put your documents in the prompt, build retrieval, fine-tune a model, or let it find what it needs? Knowledge isn't a system prompt. The system prompt is always loaded, because it sets how the agent thinks; knowledge depends on the need, and no situation needs all of it. So understand the need first, then disclose progressively: an entry point (a README of at most 750 lines, or an llms.txt map) whose links each say what's behind them, followed only where the question leads. The same goes beyond documents: some specific emails, some rows, some passages found by meaning. Retrieval is one source the agent can query, not the strategy. Cache what's always read, check with real questions that it finds the right source, and leave fine-tuning for format.

- A concept by Nicolas Dao (Cloudless Labs, Sydney): the decision before the tool
- Area: [Putting AI into software](https://cloudlesslabs.com/concepts/areas/ai/index.md)
- Last reviewed: 9 November 2026, by Nicolas Dao
- Web page: https://cloudlesslabs.com/concepts/progressive-disclosure/

## What you'll be able to decide

How a model or an agent gets the knowledge a question needs: why knowledge isn't a system prompt, how to organise documents so an agent reads only what it needs, where search by meaning fits, what caching is for, and how to check it finds the right source.

## In short

### The options

- **A. Load it all up front:** Every document the model might need goes in the prompt, every time. Simple, and mostly irrelevant to the question asked. Tools: [Anthropic API (for client systems)](https://cloudlesslabs.com/stack/anthropic-api/index.md) (Skip).
- **B. Retrieval as the strategy:** Each question is turned into a vector and the closest passages are pasted in. Good at meaning, blind to structure: a procedure can arrive in pieces. Tools: [pgvector](https://cloudlesslabs.com/stack/pgvector/index.md) (My default), [Amazon S3 Vectors](https://cloudlesslabs.com/stack/aws-s3-vectors/index.md) (Use when it fits).
- **C. Progressive disclosure:** Understand the need, read an entry point, then follow only the links, emails, rows or passages the need calls for. Tools: [Claude Code](https://cloudlesslabs.com/stack/claude-code/index.md) (My default), [HappySkills](https://cloudlesslabs.com/stack/happyskills/index.md) (My default), [pgvector](https://cloudlesslabs.com/stack/pgvector/index.md) (My default).
- **D. Fine-tuning:** Train your own copy of a model on your examples. It changes how the model writes more than what it knows.

### The rule of thumb

Knowledge isn't a system prompt: understand the need first, then load only what it calls for.

### How the answer changes with scale

- **A handful of documents:** An entry page that links them is already progressive disclosure. Cache what's always read.
- **A large knowledge base that changes every day:** A README of at most 750 lines, every document cross-linked from it, each link saying what's behind it.
- **Millions of tickets or emails, with nothing to navigate:** Add search by meaning (pgvector) as one more source the agent can query.
- **A reply needed within a second:** No time for several hops: one search, then the answer.

## The problem, in plain words

Every company wants its AI to know how the company works: its policies, products, procedures and history. The usual answers are to paste everything into the prompt, to build retrieval (RAG), or to fine-tune a model. All three start from the knowledge. I start from the need.

The mistake is treating knowledge like a system prompt. A system prompt is always loaded, because it sets how the agent thinks, and that's right. Knowledge is different: no situation needs all of it, and every situation needs a different part. So the first step is to understand what the question, or the agent asking it, actually needs, and only then decide what to load.

That's progressive disclosure: give the model an entry point, let each link say what's behind it, and let it open only what the need calls for.

## The picture

One question about workplace safety, answered three ways.

**Diagram:** One question, someone cut themselves with a kitchen knife, answered three ways: with every document loaded up front; with the five passages closest in meaning; and with progressive disclosure, which works out the need, reads the README, follows it to the first-aid procedure, and fetches only the incident form, today's first aiders and similar past reports.

- **Everything up front:** The question → Every document, every time → The answer. Most of what you paid for had nothing to do with the question.
- **Retrieval as the strategy:** The question, as a vector → The five closest passages → The answer. Close in meaning isn't the same as needed: the procedure arrives in pieces.
- **Progressive disclosure:** The need: first aid, now, in the kitchen → README, then Workplace safety, then First aid → [The first-aid procedure / The incident form / Today's first aiders, from the database / Similar past reports, by meaning]. It reads a handful of pages, not the whole manual.

## The options

**Load it all up front.** It works for a few pages, and it's the simplest thing to build. But most of what's loaded is irrelevant to the question, and it gets worse as the documents grow. Caching makes what's always loaded cheap. On Sonnet 5.5, at $2 per million input tokens with cache reads at 0.05 times that, 20,000 tokens cost about $0.04 a question uncached and about $0.002 cached. So cache what every question reads (the system prompt, the entry point), and don't take caching as a reason to load everything.

**Retrieval as the strategy.** Every question becomes a vector, and the passages closest in meaning are pasted in. It's very good at what it's for: finding meaning in a mass of text that has no structure, and doing it fast. I run it in production. On [HappySkills](https://cloudlesslabs.com/work/happyskills/index.md), people describe the task they're trying to do, and search finds the skills that fit through Postgres and [pgvector](https://cloudlesslabs.com/stack/pgvector/index.md). As the strategy for a structured knowledge base, though, it chops procedures into passages and picks them by similarity, not by need. For exact words or every mention, it's the wrong tool altogether: that's full-text search, and Postgres has it built in. My verdict on [OpenSearch](https://cloudlesslabs.com/stack/aws-opensearch/index.md) is that it's overkill for most apps.

**Progressive disclosure.** The entry point is a README, a good one never more than 750 lines, with every other document cross-linked from it and each link saying what's behind it. On a website, the same thing is an `llms.txt` map with a Markdown copy of every page, leaner than HTML. The agent reads the entry point, decides which links the need calls for, ignores the rest, and loads them on demand. It doesn't stop at documents. Halfway through, the agent may decide it also needs some emails (a few specific ones, not all of them), some rows from the database, or some passages from an embedding index. Each is queried on the fly, where the agent thinks the answer is. It's progressive disclosure all the way, and retrieval becomes one of its sources.

This website is built that way. [ask.cloudlesslabs.com](https://ask.cloudlesslabs.com) is the map, with a note on every link saying what it answers, and every page has a Markdown copy. An assistant asked about a project reads the map, then only the pages the question needs. My [/init-context](https://happyskills.ai/skill/nicolasdao/init-context) skill does the same for a codebase: it reads the docs index first, then follows only the documents the task touches.

**Fine-tuning.** Training your own copy of a model changes how it writes more than what it knows, and knowledge changes faster than you'd retrain. I've never needed it in production. Keep it for a format or a style no prompt can hold.

## A concrete scenario

A company keeps its workplace safety knowledge in three places: the safety manual and its procedures, an incident database, and years of written incident reports. Someone asks the assistant: "A colleague just cut their hand with a kitchen knife. What do we do?"

1. **The need first:** first aid, now, in the kitchen; then the paperwork.
2. **The entry point:** the README lists the manual's sections, one line each. The agent opens Workplace safety, then First aid.
3. **Only what's needed:** the first-aid procedure, and the incident form to fill in afterwards.
4. **Other sources, on demand:** today's first aiders on site, from the staff database; and, if it helps, the most similar past reports, found by meaning in the embedding index.

It read a handful of pages and a few rows. The assistant that loaded the whole manual paid for every page of it, and the one that only searched by meaning got passages from three different procedures.

## The trade-offs

| | Load it all up front | Retrieval as the strategy | Progressive disclosure | Fine-tuning |
|---|---|---|---|---|
| What it reads | Everything | The closest passages | What the need calls for | Nothing extra at question time |
| Keeps the structure | Yes | No: passages | Yes: it follows the links | No |
| Cost per question | The highest, unless cached | Low | Low: a few small reads | Low, after paying for training |
| Speed | One call | One search, one call | Several hops | One call |
| Fails when | It outgrows the window, or the noise drowns the answer | The answer is split across passages, or worded differently | The links are poor, or the entry point is bloated | The knowledge changes |
| To maintain | One file | An index kept in sync | Documents with good links | Retraining |

## The rule of thumb

**Knowledge isn't a system prompt.** Understand the need first, then give the model an entry point and let it load only what the need calls for. Search by meaning is one of the places it can look, not the plan.

## When the answer changes with scale

- **A handful of documents:** an entry page that links them is already progressive disclosure. Cache what's always read.
- **A large knowledge base that changes every day:** a README of at most 750 lines, every document cross-linked from it.
- **Millions of tickets or emails, with nothing to navigate:** add search by meaning with pgvector, as one more source.
- **A reply needed within a second:** a live chat has no time to follow links, so it's one search, then the answer.

## Before you build on it

**Check that it finds the right source.** This part is verifiable, so make it a test. Write down real questions, each with the page or passage that holds the answer, and re-run the list after every change to the documents. Count how many reached the right source. If the safety assistant stops reaching the first-aid page, you find out before your staff do.

**In Australia,** the knowledge goes where the model does ([Where may the data go?](https://cloudlesslabs.com/concepts/data-residency/index.md)):

- Claude through [Amazon Bedrock](https://cloudlesslabs.com/stack/aws-bedrock/index.md)'s Australian profile.
- The documents served from Sydney, behind a login if they're private. Bedrock has no server-side web search or code execution, so your own code fetches the pages for the model.
- When search by meaning is one of the sources, embeddings through Bedrock in Sydney (Titan Text Embeddings V2 is $0.026 per million tokens there), with the vectors in the client's own Postgres.

## Questions that change the answer

- What does this question actually need? Work that out before deciding what to load.
- Is there an entry point, and does each of its links say what's behind it?
- Is the answer in a structure (a manual, a procedure) or scattered across a mass of text (tickets, emails)? Structure is followed; scattered text is searched by meaning.
- How fast must the reply be? Under a second leaves no time to follow links.

Doesn't cover:

- Exact words and every mention ("which contracts contain this clause?"): that's full-text search in Postgres, not retrieval, in the [semantic search use case](https://cloudlesslabs.com/stack/use-cases/search/index.md).
- Which model reads it and what it costs: that's [Which model, at what price](https://cloudlesslabs.com/stack/guides/which-model/index.md).

## Check your call

- **A 400-page staff handbook, updated every week, for an internal assistant.** Progressive disclosure: a README that maps the handbook in a few hundred lines, each section a linked page with a line on what it covers. The assistant reads the map and opens the two or three sections a question needs.
- **Five years of support tickets, and agents asking "has a customer had this problem before?"** Search by meaning over the tickets, with pgvector next to the data: there's no structure to navigate. In an agent, it's one source among the others, queried when the question calls for it.
- **A team wants to fine-tune a model so it knows the product catalogue.** Don't. Fine-tuning changes how a model writes more than what it knows, and the catalogue changes. Give the agent a catalogue it can navigate and query.

## The technology on this site

- [pgvector or S3 Vectors?](https://cloudlesslabs.com/stack/guides/vectors/index.md): the decision guide
- [Which model, at what price](https://cloudlesslabs.com/stack/guides/which-model/index.md): the decision guide
- [Anthropic API, Bedrock or OpenRouter?](https://cloudlesslabs.com/stack/guides/anthropic-bedrock-or-openrouter/index.md): the decision guide
- [Semantic search and RAG](https://cloudlesslabs.com/stack/use-cases/search/index.md): the use case
- [An AI chat or LLM feature](https://cloudlesslabs.com/stack/use-cases/ai-chat/index.md): the use case
- [HappySkills, the package manager for AI agent skills](https://cloudlesslabs.com/work/happyskills/index.md): in our client work

## Related

- [How much freedom should an AI step get?](https://cloudlesslabs.com/concepts/ai-autonomy/index.md): read next
- [Where may the data go?](https://cloudlesslabs.com/concepts/data-residency/index.md): read next
- [System 1 or System 2?](https://cloudlesslabs.com/concepts/system-1-or-system-2/index.md): read next
- [Putting AI into software](https://cloudlesslabs.com/concepts/areas/ai/index.md): the area, and the technology for each answer
- [Every concept](https://cloudlesslabs.com/concepts/index.md)
- [Map of every Markdown file on cloudlesslabs.com, with what each one answers](https://ask.cloudlesslabs.com)