# Context engineering, and the half of it your team has to own

> What context engineering is, how it differs from prompt engineering, its four strategies, and why the write and select half needs a store a team shares.

Source: https://baalda.com/blog/context-engineering
Site: Baalda, https://baalda.com
Published: 2026-11-08

**Short answer.** Context engineering is choosing what goes into a model's context window on each step, not just wording the prompt. LangChain sorts it into four moves: write, select, compress and isolate. The agent's harness handles compress and isolate. Write and select depend on where the notes live, and for a team that has to be one shared folder.

Context engineering is the work of deciding what a model sees on each step: the instructions, the tool results, the files it pulls in, the notes it kept, and how much of the history survives. Prompt engineering is one part of it, the wording of a single instruction. Context engineering is the whole set of tokens, managed across a long run.

Every guide to it so far assumes one agent on one machine. That covers half the job. The other half is the notes the agent reads and writes, and once a team of five is involved, the question becomes where those notes live and who else can open them.

## What is context engineering?

Anthropic's engineering team put a definition on it in a post published on 29 September 2025: context engineering "refers to the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference."

The reason it matters is that a context window is not free storage. The same post describes context rot: "as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases." It says context "must be treated as a finite resource with diminishing marginal returns", and that good context engineering "means finding the smallest possible set of high-signal tokens." We covered the research behind that in [context rot](/blog/context-rot).

So the job is not to fit more in. It is to put the right few things in, at the moment they are needed, and keep everything else somewhere the agent can reach when it wants it.

## How is context engineering different from prompt engineering?

Prompt engineering asks how to word one instruction. Context engineering asks what the model should be looking at when it reads that instruction, on turn one and on turn forty.

A single question to a chatbot is mostly a prompt problem. An agent that runs for an hour, calls tools, reads files and hands work to sub-agents is mostly a context problem, because by turn forty the system prompt you wrote is a small fraction of what is in the window. The rest is whatever the agent pulled in along the way.

## What are the four strategies of context engineering?

LangChain's post on context engineering for agents (2 July 2025) sorts the techniques into four moves, and Anthropic's post describes the same set in its own words. The useful thing about the split is that it shows who does each part.

Figure: The four moves of context engineering, and which ones depend on where your notes live

| Strategy | LangChain's definition | What it looks like | Who does it |
|---|---|---|---|
| Write | "saving it outside the context window" | Notes, memory files, a to-do list the agent keeps | Wherever the files are stored |
| Select | "pulling it into the context window" | Reading a file, loading a skill, searching | Wherever the files are stored |
| Compress | "retaining only the tokens required" | Compaction, clearing old tool results | The agent's harness |
| Isolate | "splitting it up" | Sub-agents with clean context windows | The agent's harness |

Compress and isolate happen inside a run. Claude Code, Codex and the rest ship them, and nothing outside the harness can do them for you. Write and select are different. They depend entirely on a store: where the notes go when the agent writes them, and where it looks when it needs them back.

## Where does an agent's written context live today?

On the machine it runs on. Look at what the Anthropic post recommends.

Structured note-taking, which it also calls agentic memory, "is a technique where the agent regularly writes notes persisted to memory outside of the context window", and "these notes get pulled back into the context window at later times." The memory tool Anthropic released in public beta with Sonnet 4.5 stores that information "through a file-based system." And for selection, the post points at Claude Code, where "CLAUDE.md files are naively dropped into context up front, while primitives like glob and grep allow it to navigate its environment and retrieve files just-in-time."

All of that is good advice, and all of it writes to a folder one person controls. Give the same advice to a team of five and you get five sets of notes: five `CLAUDE.md` files that drift apart, five memory directories, and a decision one person's agent recorded on Tuesday that nobody else's agent will ever select, because it is not on their disk.

That is the gap [Baalda](/docs/mcp-tools) is built for. It is a team second brain: a vault of plain markdown files on each member's disk, edited live by several people at once, with per-file permissions, and readable and writable by AI assistants over MCP. For context engineering it is the write and select store, shared, so that what one agent writes down is what every agent on the team can select.

## What does just-in-time context look like when a team shares it?

Anthropic's version of just-in-time context is that agents "maintain lightweight identifiers (file paths, stored queries, web links, etc.)" and "use these references to dynamically load data into context at runtime using tools." The cheap thing goes in up front. The expensive thing is loaded only when the agent decides it needs it.

The clearest example is Agent Skills. Anthropic's skills post (16 October 2025) calls progressive disclosure "the core design principle" of the format, in three levels. "At startup, the agent pre-loads the name and description of every installed skill into its system prompt." If a skill looks relevant, the agent loads it "by reading its full SKILL.md into context." Any files the skill links to are the third level, which the agent can "navigate and discover only as needed."

Baalda's MCP server serves those same three levels out of the team's own skills library, as three separate tools, so an agent never pays for a level it did not ask for:

Figure: The three levels of a team skill over MCP, and what each call costs the context window

1. `list_skills` returns the vault's published skills, and for each one only its name, description, the version members get, whether it is required for everyone, the latest version, and whether an admin pinned an older one. No skill text.
2. `get_skill` takes a name and returns that skill's `SKILL.md` text, its release notes and its file list.
3. `read_skill_file` takes a name and a path from that list and returns one file as text, 50,000 characters by default and 200,000 at most, with a `truncated` flag saying whether there was more.

A first call looks like this, trimmed to one skill:

```json
{
  "skills": [
    {
      "name": "release-notes",
      "description": "Write release notes from merged PRs in our house style",
      "version": 3,
      "required": true,
      "latestVersion": 4,
      "pinned": true
    }
  ]
}
```

That is the whole first level: a line per skill, a few dozen tokens each. Here an admin has pinned version 3 because version 4 broke something, and every agent on the team gets 3 until the pin comes off. Agents only ever see published versions, never drafts. We covered how a team writes and publishes skills in [how to share Claude skills with your team](/blog/share-claude-skills-with-team).

Notes work the same way. `list_notes` returns each note's docId, title, path and your permission, which is exactly the lightweight identifier Anthropic describes, and the text comes in only when the agent calls `read_note` on the one it wants. Every one of these calls is checked against the person who made the connection, so selection can only ever reach what that person could open themselves.

## How does an agent write notes back without overwriting a teammate?

Structured note-taking into a shared folder raises a problem a private memory directory never has: two agents updating the same note.

`read_note` returns the note's `revision` along with its text. When the agent writes back with `edit_note`, `update_note` or `append_note`, it passes that revision as `expectedRevision`, and the write is refused if the note changed in between. The agent has to read the new version and decide again, rather than replacing a teammate's update with its own stale copy. Edits from people in the app and from agents over MCP land on the same file, so the note the team opens on Friday is the one the agents have been maintaining all week.

## What does a shared vault not do for context engineering?

Most of the work inside a run. A vault does not compact a transcript, clear old tool results, decide what to evict, or spin up sub-agents. Those are compress and isolate, they belong to the harness, and if your problem is that a long agent run gets expensive and drifts, the fix is there. We made the same point in [a model's context belongs in a file your team can open](/blog/context-file-teams-can-open), and it still holds.

A few more limits, plainly:

- **It cannot make a bad note good.** An agent that files a summary after every task fills the vault with pages nobody reads, and every one of them is a distractor the next agent may select. Someone still has to prune.
- **MCP needs a synced vault.** A local-only vault has no server for an assistant to reach, so the shared store exists only once the team syncs.
- **Skills over MCP are read only.** An agent can find and read the team's skills. Writing and publishing a new version is done by an owner or admin in the app.
- **One person may not need any of this.** If nobody else reads your agent's notes, a `CLAUDE.md` and a local folder are fine, and [Obsidian](/compare/obsidian) is a better fit than a multiplayer vault.

## Where should a team start?

With the file that is loaded on every request. Whatever sits in `CLAUDE.md` or `AGENTS.md` is paid for on every turn of every session, so keep it to the few lines every task needs: what the project is, how to run it, where to look for the rest.

Then move the rest out to where it can be selected instead of carried. Procedures that only some tasks need become skills, where the agent sees one line until it asks for more. Decisions, runbooks and the current state of the work become notes in a folder the whole team can open, so the agent writes them where the next person's agent will find them.

That split, small and always loaded against large and loaded on demand, is most of what context engineering asks for. The only part that changes on a team is that the large half has to be a place everyone shares.

## FAQ

### What is context engineering in AI?

It is managing the full set of tokens a model sees during a task: instructions, tool results, retrieved files, notes and history. Anthropic's engineering post of 29 September 2025 defines it as the strategies for curating and maintaining the optimal set of tokens during LLM inference.

### What is the difference between context engineering and prompt engineering?

Prompt engineering is the wording of an instruction. Context engineering covers everything the model is looking at when it reads that instruction, across every turn of a long run, including what gets loaded, summarised, cleared or handed to a sub-agent. Prompt engineering is one part of it.

### What are the best practices for context engineering?

Keep the always-loaded instructions short, load everything else just in time through tools, write durable notes outside the context window, compact long histories, and give focused work to sub-agents. Anthropic's guidance is to find the smallest set of high-signal tokens for each step.

### How does context engineering work for a team rather than one person?

Compaction and sub-agents work the same, because they happen inside one run. Notes and skills do not, since they are files on one machine by default. A team needs those in a shared store, such as a Baalda vault that agents read and write over MCP under each person's own permissions.