> ## Documentation Index > Fetch the complete documentation index at: https://checkfu.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Context > Understand what an Agent sees, what mounts into its sandbox, and how long-running Sessions stay within a model's context window. Context is the information available to an Agent while it works. In Checkfu, that information does not arrive through one unbounded prompt. Conversation, instructions, files, Memory, and capabilities each have a different lifecycle and authority boundary. | Source | How it reaches a Run | When it changes | | ----------------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Agent instructions | From the published Agent version | Frozen when the Session is admitted | | Conversation | Rebuilt from the Session's ordered event log | Grows as the Session is driven | | Project and File mounts | Staged into the sandbox at declared absolute paths; exact root repository Skills are indexed when `read` is admitted | Project selectors resolve at each Run boundary; File IDs are immutable | | Memory mounts | Read from an authorized MemoryStore | Contents resolve at each Run boundary | | Skills | Mounted as versioned instructions and files | Frozen when the Session is admitted | | Tools | Attached by the published Agent and invoked through a governed call path | The attached set freezes at admission; live authority is re-checked per call | The distinction matters. A Git repository is mounted data, a Skill is versioned instructional content, and a Tool is an action the Agent may call. Putting all three behind a generic "context" switch would hide different permission, retention, and reproducibility rules. ## Files and projects Use a **File mount** for one uploaded file and a [**Project**](/concepts/projects) for a file tree or Git repository. Both resolve through the same mount machinery: destinations cannot overlap, staged bytes are digest-verified, and `session.mounts_resolved` records what a Run actually received. Projects add immutable revisions. A mount may pin one revision or follow `latest`; `latest` resolves to a concrete revision again before each Run. Writable overlays remain disposable unless a Git-backed Project explicitly enables pull-request writeback. GitHub is therefore one provider-specific path through Projects and governed [Connections](/concepts/capabilities), not a separate context system. A Git Project also announces D54-valid Skills found exactly at `.claude/skills//SKILL.md` in the resolved revision. 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. For a new Session, pass repositories, files, and Memory stores through CMA's single `resources[]` request field. Each Session owns that admitted resource selection; there is no separate reusable SessionTemplate resource or live configuration link. See [Session mounts](/reference/sessions#mounts) for the wire shapes and [Projects](/concepts/projects) for upload, Git, and writeback behavior. ## Memory [Memory](/concepts/memory) is durable, governed knowledge that can outlive any one Session. A mount requests `read_only` or `read_write` access; admission clamps that request against the acting Principal's PermissionAssignments. The access ceiling is fixed for the Session, while the contents are read again for each Run. Memory is not hidden conversation history. Stores and revisions 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: * 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.