> ## Documentation Index > Fetch the complete documentation index at: https://docs.checkfu.com/llms.txt > Use this file to discover all available pages before exploring further. # Context > Supply Agent context, select exact versions for each user turn, and preserve them through continuation. Context is the information an Agent uses to do your work: instructions, conversation, repositories, files, Skills, and Memory. You choose the sources and how their versions are selected. The selected Harness determines how the Agent receives and uses them. For example, give a support Agent a product repository, a troubleshooting Skill, and a MemoryStore of approved answers. Ask it to explain a failed upgrade. Checkfu records the exact versions selected for that user turn. If the Agent pauses for an answer while you publish a new troubleshooting Skill, the waiting work keeps its original version. A later user request can select the new version. ## Choose the inputs | Input | What you supply | Version selection | | - | - | - | | Agent instructions | Instructions in a published AgentVersion | Fixed when the Session starts | | Conversation | Messages and results in the Session | Grows in the ordered event log; model input may contain a bounded portion | | Files and repositories | File mounts, FileTrees, or repository Resources | File IDs are immutable; FileTree selectors resolve at each eligible user turn; repository Resources freeze a checkout at attachment | | Skills | Versioned instructions and supporting files | Exact versions stay fixed; omitted or `latest` versions resolve at each eligible user turn | | Memory | An authorized MemoryStore and access mode | An exact version stays fixed; named refs and unselected contents resolve at each eligible user turn | Use [Session resources](/reference/sessions#resources) to attach files, repositories, and Memory through `resources[]`. Configure Skills on the Agent; see [Install a Skill](/guides/install-a-skill). Each Session owns its resource selection. It does not follow a live reusable Session template. A Skill can explain how to publish a release. It cannot grant the Tool, provider account, credentials, or permission to publish one. The same rule applies to repository instructions and Memory. Configure actions separately through [Tools](/concepts/tools). ## Resolve a user turn Starting a Session fixes its AgentVersion, Skill references, and resource selection policy. It does not freeze every `latest` source for the Session's entire life. When a new user turn becomes eligible to run, Checkfu resolves its selectors and records exact versions and content digests. A configured exact version stays on that version. A `latest` selector can pick up a publication made since the previous turn. An additional authorized Skill activation can be pending for a later eligible turn; it does not rewrite active work. Tool rounds, answers to questions, approvals, retries, and recovery continue the same Run. They retain the original resolved inputs rather than looking up `latest` again. A new independent request has its own Run and context selection. See [Sessions and Runs](/concepts/sessions-and-runs). Memory can also advance through that input's own retained, committed write checkpoints on a supported path. Each later round records its exact revision and write provenance; retries preserve those records. This does not select unrelated changes to today's Memory. See [Memory](/concepts/memory). ## Keep access current A version pin identifies content; it does not grant lasting access. Discovery, reads, writes, reuse, and publication require current authorization. Recovery cannot restore a revoked permission or recover content that retention or erasure has removed. If an original required input is missing or no longer authorized, continuation refuses or reports unavailable. It does not replace that input with a newer version, a resource with the same name, or another account. Content also keeps its audience restrictions. A personal MemoryStore or native private memory does not become Workspace knowledge because a Session used it. Shared adoption and later reuse follow the existing resource's permissions, retention, and promotion rules. ## Files and file trees Use a **File mount** for one uploaded file and a [**FileTree**](/concepts/file-trees) for a file tree or Git repository. Both resolve through the same mount machinery: destinations cannot overlap, staged bytes are digest-verified, and `session.resources_resolved` records the exact inputs selected for a Run, including version and content provenance. It is not a receipt that the harness read those bytes or used the instructions. Verify use through the Run's actual output and supported harness evidence; successful selection alone does not qualify native execution or recovery. FileTrees add immutable revisions. A mount may pin one revision or follow `latest`; `latest` resolves to a concrete revision for each new eligible turn. Question answers and custom Tool results continue the same Run with that turn's full original resolved resource manifest. A revision published while the turn is waiting becomes eligible for a later turn; it does not replace the original continuation inputs. If those original resources cannot be used under current authority, continuation refuses rather than selecting a newer revision. Writable overlays remain disposable unless a Git-backed FileTree explicitly enables pull-request writeback. GitHub is therefore one provider-specific path through FileTrees and governed [Connections](/concepts/capabilities), not a separate context system. On the FileTree compatibility path, a repository mount announces Skills discovered at exactly `.claude/skills//SKILL.md` in the frozen revision — for a Git FileTree that is the resolved version, and for a `github_repository` Session Resource it is the checked-out commit. They stay at their repository paths and never become catalog Skills or release pins. When the Agent has its built-in `read` tool, the prompt points to the generated read-only index at `/environment/.checkfu/repository-skills.md`; without `read`, no pointer is added. Mounting the repository admits those instructions into the Agent's trust boundary, so review that directory for repositories that accept outside contributions. Nested, rootless, and package-local layouts are not announced. Native recorded-Git preparation currently does not discover or load those repository-local Skills. Configure reusable Skills through their versioned resource contract; recording a repository revision does not activate them. See [Session resources](/reference/sessions#resources) for the wire shapes and [FileTrees](/concepts/file-trees) for upload, Git, and writeback behavior. ### Native Session resource boundaries Resource delivery depends on the selected Harness. A native file adapter can expose bounded read-only files and directory readers without creating a writable sandbox checkout. Do not infer shell execution, file mutation, or watches from a readable mount. Git-backed FileTrees retain their original Connection and exact recorded revision; a missing source leaves that namespace unavailable rather than selecting another source. The current native uploaded-tree reader requires an acting Principal. An API-key Session without `acted_as` cannot use that body-reading path, even if the tree's metadata was selected. This is a delivery limitation; specifying `acted_as` still requires the real delegation and resource permissions. Native Workspace execution does not currently publish generated artifacts as downloadable Session Files. A retained Tool result or a readable input mount does not establish that output path. Use the selected Harness's supported capture and File publication path before relying on downloads or reuse in another Session. Private Workspace state and native private memory are not automatically published or shared. Memory writes use their own governed writer. A writable mount needs the original write offering and current write permission; mount metadata alone does not enable it. See [Memory](/concepts/memory) for working refs, checkpoints, and supported read and write paths. Selection, staging, actual use, and retention are separate steps. A resolved revision or successful directory read does not show that the Harness read the file's bytes. Retained conversation does not establish that files or native continuation state survived. Check the selected Harness's [capability status](/getting-started/status) and the Run's output before relying on a particular delivery or recovery path. ## Memory [Memory](/concepts/memory) is durable, governed knowledge that can outlive any one Session. A mount requests `read_only` or `read_write` access; admission checks the Agent's PermissionAssignments for a `resources[]` attachment. When a Principal is part of the acting authority, its PermissionAssignments are checked too. Current permissions are checked again when the Run uses Memory. Shared stores owned by a Workspace, Agent, or CollaborationSpace mount read-only in Sessions. Shared canonical changes follow the store's write and promotion policy; that policy does not grant Session writers direct canonical access. Principal-owned writes stay on the Session's working ref and do not silently become another Session's input. To reuse a writer's retained output, take `new_version` from its `memory.change_checkpointed` event and attach the store with `access: "read_only"` and `selection: { kind: "version", version: new_version }`. A named ref selection resolves to an exact revision before the Run; a selected MemoryVersion identifies one immutable tree. Where the native versioned writer is installed, an explicit selection on an effective `read_write` mount fixes the base of that Session's working ref; it does not edit the selected immutable revision. An existing working ref at a different version refuses that base. Mount paths without this writer refuse explicit selections on effective `read_write` mounts. The Session detail shows declared selection intent, not a frozen Memory input or native-use receipt. Verify delivery through the relevant Run and attempt inputs. Neither selection nor a checkpoint receipt grants access or extends retention: revoked permissions, expired bodies, and erasure still apply. See [carry a sealed revision into another Session](/concepts/memory#carry-a-sealed-revision-into-another-session) for the complete request. Memory is not hidden conversation history. Stores and their MemoryVersions are addressable, access is explicit, and writeback settles through its own durable lifecycle. ## Context windows and condensation The Session event log remains the durable record even when a model cannot read the entire history in one request. Checkfu bounds model input without rewriting that record. Automatic compaction is currently disabled for native Sessions; their Managed Agent snapshot does not carry the `compaction_policy` described below. Do not treat a successful native reply or retained history as proof of compaction support. For execution paths that support these mechanisms: * request-time compaction follows the published Agent version's `compaction_policy` and the admitted model route's context window; * between turns, structural condensation can replace an older conversational prefix with an explicit elision marker while retaining the newest tail; * `session.compacted` and `session.context_condensed` make both boundaries observable. `GET /v1/sessions/{id}/ledger` reports current and cumulative context tokens, loaded Tool and Skill references, compactions, and condensations without returning prompts or messages. Use the [context ledger guide](/guides/export-your-log#read-the-context-ledger) when you need to explain what was loaded and what it cost. ## Next steps Mount uploaded files or Git repositories and control revision and writeback behavior. Give Agents durable knowledge with explicit ownership, PermissionAssignments, and version history. See when identity freezes, when mounted data resolves, and how each turn settles. Keep callable capabilities distinct from files and instructions. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.