Context Fabric Lifecycle

Context Fabric stores useful context from earlier work so that later sessions can find it. For example, a new coding session can find a verified explanation of a test failure that a colleague already investigated.

Each item of context belongs to a scope: organization, team, agent, repository, branch, and session. A caller finds only the context in scopes that it can access. This page follows context from capture to removal. Work Reuse describes how the gateway reuses completed work.

Start with one agent

1. Add a context_fabric block to the agent configuration. Start with capture_mode: nudge, and add exclusion patterns for content that must not be stored, such as private keys. See Configure capture.
2. Deploy the configuration to a test agent.
3. Run one session with content that has no sensitive data.
4. Open the agent in Agents and select the Context tab. Make sure that the stored context has the correct branch and source.
5. From a second authorized session in the same scope, search for that context.

The second session finds the context with its source and verification state. A search result does not prove that the context is correct, or that the gateway reused it.

Lifecycle stages

Stage	What happens	Where
1. Configure	The configuration sets capture behavior.	policy-config.yaml or a control manifest
2. Register a scope	A session declares its repository, branch, and team.	POST /v1/context/register
3. Capture and share	The gateway captures context, or a caller shares it.	POST /v1/context/share
4. Search and resolve	Callers search their scope and examine resolution plans.	POST /v1/context/search and related routes
5. Verify and correct	Callers verify, dispute, and correct context, and resolve conflicts.	POST /v1/context/verification/apply and related routes
6. Reuse work	Work receipts record completed work for trusted reuse.	POST /v1/work-receipts
7. Flush	A completed session becomes a recall document.	POST /v1/context-flush
8. Purge	An approved privacy workflow removes the context of one user.	DELETE /v1/context/by-user/{id}

Configure capture

Put a context_fabric block at the top level of policy-config.yaml to set the default for the gateway. An agent declaration can have its own block that overrides the default.

policy-config.yaml

context_fabric:
  enabled: true
  capture_mode: nudge
  capture_exclude_patterns:
    - "BEGIN [A-Z ]*PRIVATE KEY"
    - "internal-only"

The gateway applies three settings when it captures a response:

Setting	Effect
enabled	Turns Context Fabric on or off. The default is true.
capture_mode	nudge (default) suggests that the user saves a useful response for the team. auto captures without a suggestion. off captures nothing.
capture_exclude_patterns	Regular expressions. The gateway does not capture content that matches one. A pattern that is not a valid regular expression matches as case-insensitive text.

The schema also accepts pool limits, TTLs, deduplication and compaction thresholds, pii_detection and dlp_filter switches, confidence and verification settings, branch inheritance, cache settings, a conflict strategy, multi-gateway peers, and direct_answer_threshold. The gateway resolves these values, but they do not change capture or customer search. Customer search uses a direct answer threshold of 0.85.

Because the schema accepts settings that the gateway does not enforce, apply retention and data classification with active policy controls before you turn on capture.

Register a working scope

POST /v1/context/register registers or updates the session of the signed-in user. The request has a session_id, a repository, and a branch. It can also have a commit, a working directory, and a team scope.

Register again when the repository or branch changes. A new branch starts a new History session relationship, and Context Fabric puts later work in the new branch scope.

A repository name is not a security boundary. Authentication, organization membership, team scope, and API authorization apply to each request.

Capture and share context

capture_mode controls automatic capture. To share context yourself, use POST /v1/context/share. A share request can include session, team, repository, branch, commit, source, tag, verification, and provenance information. A request with a branch must also have a repository.

Before you share content:

• Remove secrets, and personal data that the task does not need.
• Make sure that the team and repository are correct.
• Attach provenance.
• Classify the content as observed, inferred, or verified.

When Context Fabric finds a duplicate, it offers replace, keep both, or discard. Examine the duplicate and its scope before you select one.

The pii_detection and dlp_filter switches do not protect capture in the gateway. Use the PII Detector and DLP Filter controls, and add capture_exclude_patterns for content that must not be stored.

Search and resolve

Route	Use
POST /v1/context/search	Search the team, agent, repository, branch, and session scopes that you can access
GET /v1/context/recent	List recent context in a bounded scope
GET /v1/context/schema/{table}	Get context about one named schema or table
POST /v1/context/graph/query	Query context graph relationships
GET /v1/context/graph/entity/{name}	Get one graph entity
POST /v1/context-resolution/inspect	Get a staged resolution plan and its trace
GET /v1/context/stats	Get statistics for an agent, a time range, or a branch

A search needs a query, except in agent list mode. Search leaves out disputed content unless the caller asks for it and is authorized.

A direct answer is a suggestion. It has its source document IDs and a confidence value. Keep the sources with the answer, and do not show an answer as verified when its source is not verified.

Resolution inspection redacts content by default. It includes content only when the caller asks for it and can view each item.

Build the context graph

Use POST /v1/context/graph/upsert only for authorized facts that have a source. Query the graph first, so that you do not add a duplicate entity. Keep the source reference on each relationship.

A graph entry does not prove that a fact is still correct. Keep provenance, confidence, verification status, and timestamps with each result.

Verify and correct context

Route	Use
POST /v1/context/verification/apply	Apply verification outcomes to documents in scope
POST /v1/context/feedback	Record helpful, not-helpful, or corrective feedback. A correction creates a document that replaces the earlier one.
POST /v1/context/flag	Record a flag, verify, or dispute vote, and calculate the document state again
GET /v1/context/conflicts	List open conflicts
POST /v1/context/conflicts/resolve	Resolve one conflict

The verification route skips each document that is out of scope and does not change it. Examine the counts and the outcome of each document in the response.

Give each correction its evidence and scope so that a reviewer can examine it. Do not remove a disagreement only to increase a confidence value.

Record and reuse work

POST /v1/work-receipts records evidence of completed work that can be reused. POST /v1/work-receipts/search finds receipts in scope. Before the gateway reuses a receipt, it evaluates the active governance rules again.

Context Fabric estimates the work and cost that reuse saved from telemetry. These estimates are not invoice data. Work Reuse describes execution, trust states, protection from data poisoning, and verifier limits.

Flush completed context

POST /v1/context-flush turns the eligible context of a session into a recall document for later sessions. The request names a History session and a context plan hash. A repeated request for a completed flush returns the stored result.

Flush a session after its sources and scope are correct. Then examine the recall document, its retention and verification state, and a search that should find it.

A flush does not delete anything.

Purge the context of one user

DELETE /v1/context/by-user/{id} starts the removal of the context that belongs to one user. It can change registrations, feedback, and stored context relationships. You cannot undo it.

Use it only in an approved privacy or offboarding workflow:

1. Verify the user ID and the organization.
2. Find legal holds and retention requirements.
3. Get the necessary approval.
4. Record the scope. Do not copy content that you do not need.
5. Send the delete request one time and record the counts in the response.
6. Make sure that an authorized search returns no context for this user.
7. Keep the Trail record of the operation.

Removing a member from the organization does not purge their context.

API boundaries

The routes on this page take a customer bearer token. Their prefixes are /v1/context, /v1/work-receipts, /v1/context-flush, and /v1/context-resolution/inspect.

Routes under /v1/gateway/ take gateway machine tokens. Do not call them from an application with a user session or an ordinary API token.

Next steps

• Context Fabric Work Reuse: when the gateway can reuse a work receipt.
• Agents: the Context tab and agent settings.
• API Overview: authenticate to the customer API.