Context Documents

Context Documents are reusable knowledge artifacts that get version-controlled and automatically injected into sandboxes as system prompts or CLAUDE.mdcontent. Rather than embedding the same architectural overview or coding standards in every persona’s instructions, you write it once as a Context, publish it, and bind it to whichever session types or personas need it. Every time a matching sandbox is provisioned, the active version of that Context is injected automatically.

Contexts live at /p/{projectId}/context and are scoped to a single project. A project can have any number of Contexts, each covering a different domain of knowledge - one for architectural conventions, another for API documentation, another for security rules.

What Contexts Are

At its core a Context is a named, versioned markdown document. Each Context record stores:

• Name - A human-readable label (e.g., “Project Architecture”, “Security Standards”)
• Description - An optional summary of what the Context covers and when to use it
• Content - The full markdown body injected into sandboxes
• Version history - A complete audit trail of every published version

Contexts are designed for the kind of persistent, project-level knowledge that every agent of a given type should carry. Examples include:

• Full architectural overviews describing the technology stack, service boundaries, and data flow
• Coding standards and style guides that agents must follow when writing code
• CLAUDE.md content that gets written into the sandbox filesystem before the agent runs
• Domain-specific API documentation or integration patterns agents need to reference
• Security checklists and compliance requirements for agents performing code reviews

Context Version Lifecycle

Every time you edit a Context’s content and publish the change, a new version is created. Versions have two statuses:

The lifecycle for a typical Context edit is:

1. You open the Context editor and modify the markdown content
2. You click Publish - this creates a new version with status active
3. The previously active version is automatically set to inactive
4. All future sandboxes that reference this Context receive the new active version
5. The old version remains in the version history for audit and rollback purposes

Session Type Bindings

Contexts can be bound to specific session typesfrom the Project Settings page. When a session of that type is created, the bound Context’s active version is automatically injected. CodeCourier defines six session types, each corresponding to a different stage of the AI workflow pipeline:

Each session type has its own setup tab in Project Settings where you can link exactly one Context. This makes it easy to give, for example, the evaluator agent a different set of quality criteria than the issue discovery agent.

Persona-Level Context Override

In addition to session-type bindings, individual personas can bind to a specific Context from their Context tabon the persona detail page. A persona-level binding takes precedence over the session-type default - meaning that when a persona with its own Context binding runs, it uses the persona’s Context rather than the session-type default.

This override mechanism enables fine-grained control. Consider a project with two Designer personas - one for frontend work and one for backend work. The frontend Designer is bound to a “Frontend Architecture” Context, while the backend Designer is bound to a “Backend Architecture” Context. Both inherit the session-type default as a fallback if no persona-level binding is set.

Why Contexts Matter

Before Contexts, teams had to copy-paste architectural knowledge into each persona’s instructions or maintain separate CLAUDE.md files per workflow. This created drift: different agents would have subtly different understandings of the codebase because their instructions were edited independently. Contexts solve this by providing a single source of truth that all relevant agents share.

The key benefits are:

• Consistency - All agents of a session type share the same up-to-date knowledge. When the architecture changes, you update one Context and all future sessions immediately get the change.
• Version control - Agent instructions are versioned just like code. You can see who published which version, when, and roll back to a previous version if a change causes regressions.
• Separation of concerns - Persona instructions stay focused on role-specific behavior. Shared knowledge lives in Contexts. Each has a clear home.
• Auditability - When an agent produces unexpected output, you can check the version history to see exactly which Context version was active at the time of that session.

Next Steps