Managing Contexts

Once you have Contexts in your project, this guide covers the full management lifecycle: browsing the Context list, editing content, publishing new versions, rolling back to a previous version, deleting Contexts, and understanding which personas and sessions are currently using each Context.

Viewing All Contexts

The Contexts list page at /p/{projectId}/context shows every Context in the project. Each row displays:

• Name - the Context’s display name
• Description - a one-line summary
• Version count - how many published versions exist
• Last published - the timestamp of the most recent active version
• Usage count - how many personas and session types reference this Context

Click any row to open the Context detail page, where you can read the current content, browse version history, and make edits.

Editing Context Content

Open the Context detail page and modify the markdown content in the editor. Your edits are saved automatically as a draft. The editor shows an Unpublished changes indicator in the header bar whenever the draft differs from the currently active version.

Editing a draft does not affect running sandboxes or the active version. Sandboxes always receive the active published version. Draft content is only staged for the next publish.

Publishing a New Version

Viewing Version History

The Version History panel on the Context detail page lists every published version in descending chronological order. For each version you can see:

• Version number - an incrementing integer starting at 1
• Status badge - active (green) or inactive (gray)
• Published at - exact timestamp of when this version was published
• Published by - the team member who clicked Publish

Clicking a version in the list opens a read-only view of that version’s content. You can compare it side-by-side with the current draft to understand what changed between versions.

Restoring a Previous Version

If a newly published version causes problems - for example, an agent starts behaving unexpectedly because the Context content was changed incorrectly - you can roll back to any previous version:

Deleting a Context

To delete a Context, open its detail page and select Delete from the actions menu (the three-dot overflow menu in the page header). Deletion is a soft delete- the Context is moved to the project’s trash and is no longer visible in the Contexts list, but its data is preserved for a grace period.

What Happens on Deletion

• The Context no longer appears in the active Contexts list
• Any session-type bindings that referenced this Context are cleared automatically
• Persona bindings that referenced this Context are cleared automatically
• Existing sandboxes that already received the Context content are not affected
• The Context and all its version history are moved to the trash

Recovering from Trash

Deleted Contexts can be recovered from the project’s Trash section, accessible from the project sidebar. Restoring a trashed Context returns it to the active Contexts list with all its version history intact. Session-type and persona bindings that were cleared on deletion are not automatically re-established - you will need to re-link the Context after restoring it.

Context Usage Analytics

The Usage tab on each Context detail page shows exactly which parts of your project are currently referencing that Context. This is essential for understanding the blast radius of a change before you publish a new version.

Session Type Bindings

The Usage tab lists all session types that have this Context set as their default:

• Each entry shows the session type (answering, issues, learning, merging, evaluator, judge)
• A direct link to the corresponding setup tab in Project Settings
• When the binding was last updated

Persona Bindings

The Usage tab also lists all personas that have this Context set as their persona-level override:

• Persona name and type
• A direct link to the persona’s detail page
• When the persona was last updated to use this Context

If no personas or session types are listed in the Usage tab, the Context is not currently being injected into any sessions. You can safely publish changes or archive it without affecting active workflows.

Best Practices for Context Management

• Keep Contexts focused - One Context per domain area (architecture, security, testing) rather than one giant document. Focused Contexts are easier to update and the agent uses them more precisely.
• Review Usage before publishing - Check the Usage tab to understand which session types and personas will be affected by a new version before you publish it.
• Write a description for every version - The version history panel helps future team members understand the evolution of a Context. Treat it like a commit history.
• Audit after major codebase changes - When you migrate a framework, change file conventions, or add a major dependency, audit all Contexts to ensure the content still reflects the codebase accurately.
• Use separate Contexts per technology layer - A frontend Designer does not need backend API documentation. Keep Contexts small and layer-specific, then bind only the relevant Context to each persona.

Next Steps