Context engineering, tested.
System prompts, retrieved docs, tool descriptions, rules files: your agent's context is now the most important thing you write. Subjourney runs it with simulated users, so you know it's complete before your agent acts on it.
You version your context. You don't test it.
Context engineering has the writing and the versioning down. The missing step is the test. Evals check outputs downstream, after the agent has already filled the gaps with guesses.
Subjourney tests upstream. It runs the context itself and shows you which line is missing, ambiguous or in conflict with another.
How it works.
- 01Import the context.Prompts, knowledge base, tool descriptions, process docs.
- 02Run real goals through it.Simulated users try to get what they came for.
- 03Fix the line.Each stall names the instruction or doc responsible. Patch it with your coding agent, then re-run.
Output evals vs context runs.
| Output evals | Context runs | |
|---|---|---|
| What's tested | The agent's answers | The context the answers come from |
| A failure tells you | The score dropped | Which paragraph is missing or conflicting |
| Test cases | Written by hand | Drawn from the journeys your context describes |
| When | After the agent responds | Before it ever does |
What's tested
- Output evals
- The agent's answers
- Context runs
- The context the answers come from
A failure tells you
- Output evals
- The score dropped
- Context runs
- Which paragraph is missing or conflicting
Test cases
- Output evals
- Written by hand
- Context runs
- Drawn from the journeys your context describes
When
- Output evals
- After the agent responds
- Context runs
- Before it ever does
“We already have evals.”
Keep them. Context runs make them more useful: when an eval fails, you'll know which line of context to change.