A context set is a governed bundle of approved context that an agent starts from instead of searching the whole workspace.
Context sets
A context set (/platform/context-graph?view=library&set=<id>) is a governed bundle of approved context that an agent starts from instead of searching the whole workspace blindly.
Anatomy of a context set
Each context set defines three parts:
- About the set: A unique name (up to 120 characters) and a purpose (up to 2,000 characters) that agents read to pick the right set for a task.
- Scope: Chosen collections (up to 8) or chosen documents (up to 20). Agents using the set read only inside this scope, and never bypass document permissions.
- Members:
- Approved library entries (up to 100): business terms, verified answers, instructions, and approved query templates, each pinned to the version the library serves. An entry whose citations fall outside the set’s scope cannot join (and is withheld as
outOfScopeif a later library update cites an outside document). - Rule templates (up to 20): vetted temporal-graph rule templates the set’s agents may run.
- Must-include documents and entities (up to 20 each): items that every context pack built from the set prioritizes after approved entries.
- Approved library entries (up to 100): business terms, verified answers, instructions, and approved query templates, each pinned to the version the library serves. An entry whose citations fall outside the set’s scope cannot join (and is withheld as
Lifecycle, access, and versions
A set is draft, active, or archived. Only active sets serve agents (AGENT_CONTEXT_SET_INACTIVE otherwise).
| Access level | Who can hold it | Capabilities |
|---|---|---|
| Steward | Workspace owners/admins, or people with library:edit | Apply changes directly, approve or reject editor proposals, roll back with a reason, activate, archive, restore as draft, attach evaluation datasets, and manage access |
| Editor | People with library:edit | Propose changes, run Preview what an agent gets, and run Measure impact / Check changes |
| Reader | People, workspace roles, or agent credentials (agent_credential:manage required to add credentials) | View the set, preview packs, and build agent context packs from the set |
Every change appends an immutable version (context_set_versions). When the business context library approves, rolls back, retires, or suspends a member entry, Bundata automatically writes a system member_updated set version that re-pins the newly served entry version.
Preview and measured impact
- Preview what an agent gets (
POST /api/w/:wsId/context-sets/:setId/preview): Enter a task to inspect the exact pack an agent reading the set would receive, including token breakdown by part (verified_answers,definitions,instructions,required_evidence,evidence). - Measure impact and Check changes: Stewards can attach an Eval Studio RAG/retrieval dataset (
PUT /api/w/:wsId/eval/change-checks/sets/:setId/attachment). Measure impact compares the workspace agent withtools_onlyvscontext_set_first. Check changes compares the current set version against a proposed version; approving a proposal whose check found an accuracy regression requires anoverrideReason(409 REGRESSION_OVERRIDE_REQUIRED).
Binding agent credentials
In Settings → Agent access, admins can bind a credential to up to 10 sets (PUT /api/w/:wsId/agent-credentials/:id/context-sets):
- A bound credential reads only inside its active bound sets: their scope, their approved entries, their query templates, and their rule templates. Workspace-wide temporal graph tools (
query_as_of,get_entity_history,compare_times,get_value_series,get_activity_series) are hidden and refused (AGENT_CONTEXT_SET_TOOL_REFUSED). - An unbound credential works across readable collections as before, and can also list and use sets where a steward made it a reader.