---
name: apply-context-systems-thinking
description: Apply Jacob Dietle's Context Systems method to real organizational AI work. Use when someone wants to improve AI-assisted work, identify the shared context behind several business use cases, build a small personal Context OS, turn repeated work into a reusable skill, or decide whether proven work is ready for team ownership, review, releases, and dependencies.
---

# Apply Context Systems Thinking

Begin with work that matters. Identify the context limiting it. Build only the smallest useful system for making that context reusable.

Follow the layers in order. Do not design the perfect taxonomy or an organization-wide system before simpler use has been proven.

## Hold the core distinctions

- Context mattered before AI. Shared context, stories, and meaning-making already made human collaboration possible.
- Agents are bounded by the context provided to them. More model capability does not replace missing organizational context.
- **Single-player context** determines the quality of one person's AI-assisted artifact.
- **Multiplayer context** determines whether one person's or team's learning can improve another's work.
- People decide what becomes shared context. The system preserves the evidence and reasoning behind that judgment.
- Never outsource the thinking. Use the system to find, assemble, and reuse prior thinking.

## 1. Begin with two or three real use cases

Ask for two or three high-value business use cases the user wants AI to improve. Keep them concrete: an article, campaign, sales artifact, product decision, customer-success handoff, or another recurring piece of work.

For each use case, identify:

- the work or decision being produced;
- who performs, reviews, or uses it;
- whether the constraint is poor artifact quality or learning that fails to travel;
- the prior decisions, evidence, language, and standards the work needs.

Do not propose infrastructure yet. First find what the use cases have in common.

## 2. Use the E-drive model

Treat a Context OS like the shared E drive from a school computer lab:

- the **files** hold the work;
- the **map** tells people and agents where things live;
- the **rules** say where work belongs and how it may change.

Shared storage alone is not a system. It becomes usable when someone establishes the map and rules. Modern agents make the underlying file structure practical again because they can navigate paths that people find cumbersome.

Prefer plain files and clear operating instructions before adding another platform or abstraction.

## 3. Work backward to reusable ingredients

Use the pantry and recipe distinction:

- **Ingredients** are the small number of context elements needed repeatedly.
- **Recipes** are repeatable processes that assemble those ingredients into work.

Do not store every possible snippet of context. Identify the small number that materially changes the selected use cases.

For each current belief, preserve the evidence behind it. If a customer call changes positioning, update the current positioning and retain the call note or transcript that caused the change. Keep what the user believes now easy to use without erasing how they arrived there.

## 4. Build the smallest useful single-player system

Start with one directory, one rulebook, and the context repeatedly needed for the selected use cases.

```text
context-os/
├── README.md       # Human-readable map
├── CLAUDE.md       # Claude Code operating guidance
├── AGENTS.md       # Codex operating guidance
├── context/        # Current beliefs and reusable ingredients
├── sources/        # Raw evidence
├── skills/         # Repeatable methods
├── work/           # Drafts and intermediate artifacts
└── releases/       # Human-approved outputs safe to reuse
```

Use these roles inside one working corpus:

- `sources/` preserves what happened.
- `context/` holds what the user currently believes.
- `skills/` describes repeatable ways to turn context into work.
- `work/` holds drafts and intermediate artifacts.
- `releases/` holds outputs the user has approved for reuse.

Tell the agent to identify the requested outcome, read relevant current context, search existing sources and work, follow any applicable skill, preserve source material, distinguish evidence from inference, preserve the user's language, and require human approval before treating an output as reusable.

Capture first. Classify later, after repeated use reveals which distinctions matter.

## 5. Turn one recurring use case into a recipe

Create one skill for one selected use case. Give it:

- a concrete outcome;
- the inputs it should draw from;
- an ordered assembly process;
- a definition of done that requires human review.

The process should inventory sources, state the intended result, assemble the work in stages, trace substantial claims to sources, preserve the user's language, and check for repetition, abstraction, and unsupported claims.

Treat the recipe as an amplifier of the user's thinking, not a substitute for it.

## 6. Prove the single-player loop before scaling

Use the system on the original two or three use cases. Look for better work, faster reuse, and preserved evidence and reasoning.

If the system is not useful in repeated single-player work, improve that layer instead of adding team infrastructure. When the proven constraint becomes collaboration across people or teams, continue.

## 7. Add the minimum multiplayer process

Address three things explicitly:

1. **Architecture:** What context represents the team's collective knowledge?
2. **Lifecycle:** Who is responsible for each part, and how does it stay accurate?
3. **Collaboration and permissions:** Who can propose, review, approve, and use each part?

Use one simple lifecycle:

> Owners review versions to cut releases.

- An owner is qualified and responsible for the context.
- A contributor proposes a visible version rather than silently replacing the current one.
- The owner reviews the proposed change.
- Approval creates a release others can safely use.

Centralize the review process so collaboration can remain decentralized.

## 8. Use Git to enforce the lifecycle when needed

Use Git beneath the workflow to make proposed changes visible, preserve prior snapshots, record lineage, and calculate exact differences between versions.

Do not require every participant to work directly inside Git. Familiar interfaces may sit above it while the system preserves ownership, review, history, and reusable releases underneath.

## 9. Make shared dependencies visible

After owners are cutting real releases, show:

- where each context package lives;
- who owns it and which release is trusted;
- which downstream work depends on that release.

This is federation: one shared system and rulebook, with ownership and judgment distributed to the people closest to the work. Dependencies show what may need attention when upstream context changes.

## 10. Make influence structural

The end state is not merely faster content generation. A team's expertise should influence downstream work even when the person who earned that knowledge is not in the room.

Evidence becomes reviewed context. Other teams depend on its approved release. Their results return as new evidence. The organization stops making every team learn the same lessons independently and begins new work from what the company has already learned.

## Apply only the layer the work has earned

When responding, show:

1. the two or three use cases;
2. their shared reusable ingredients and supporting evidence;
3. the smallest single-player system and first recipe;
4. whether repeated use has earned a multiplayer layer;
5. only the next required operating layer.

Make assumptions and unresolved evidence explicit. Do not present later layers as requirements when the current layer has not been proven.

## Stopping rules

- Do not design the perfect taxonomy before repeated use establishes the need.
- Do not collect every possible piece of context.
- Do not replace human judgment with automatic publication.
- Do not scale before the first two or three use cases validate the foundation.
- Do not treat team adoption as a small extension. Each successive layer is as difficult as the previous layers combined.
- Acknowledge that this field is early and that more than one implementation can work well.