> ## 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. # Resource boundaries > Understand Checkfu's Organization, implicit Tenant, Workspace, authored resources, and Session execution boundary. Use this page to check Workspace isolation, versioning, authoring ownership, and Session admission. Start with the [product model](/concepts/product-model) for the short explanation of how the resources fit together. The resource hierarchy is: ```text theme={"theme":{"light":"github-light","dark":"github-dark"}} Organization └── Tenant, normally implicit └── Workspace ├── Agent │ └── AgentVersion ├── Environment ├── Session │ └── Turn │ └── Run │ └── RunAttempt ├── Vault │ └── Credential ├── Connection ├── File ├── FileTree ├── Computer │ └── Screen ├── MemoryStore │ └── MemoryVersion ├── Skill │ └── SkillVersion ├── Automation │ └── AutomationRun └── AutomationGraph extension ``` ## Organization, Tenant, and Workspace An **Organization** is the top-level customer account. Every Workspace belongs to a **Tenant**. Tenant is a real isolation boundary, but it normally stays implicit in builder-facing APIs and documentation. You do not choose a Tenant each time you create an Agent or start a Session. A **Workspace** is the normal customer isolation, authoring, and policy boundary. Agents, Environments, Sessions, Vaults, Connections, Files, FileTrees, Computers, MemoryStores, Skills, and Automations belong to and are used through a Workspace. Development, staging, and production should be separate Workspaces rather than values on an Environment. Workspace isolation is structural. The bounded visibility exception is a self-hosted Environment: its `scope` may let authorized accounts in the same Tenant or Organization select the definition. That never shares a Session sandbox or data, and runtime state remains Workspace-isolated. ## Versioned resources and execution records Some stable resources have immutable Versions. Automation instead has a durable record for each firing: | Stable resource | Related record | Meaning | | - | - | - | | Agent | AgentVersion | One immutable authored configuration selected for execution | | MemoryStore | MemoryVersion | One immutable point in durable memory history | | Skill | SkillVersion | One immutable reusable capability version | | Automation | AutomationRun | One Automation firing and its execution record | AgentVersion, MemoryVersion, and SkillVersion are immutable history. An AutomationRun is a runtime record, not an Automation configuration version. The Session event log remains durable execution truth. Authoring interfaces do not own resources. UI, HTTP, SDK, CLI, and MCP invoke the same canonical operations. A resource has zero or one active desired-state owner. Direct writes are available while it is unclaimed. A YAML, Git, or AutomationGraph application may retain authorship only through an explicit claim or audited adoption. None of those source forms becomes another runtime, scheduler, policy engine, or transcript authority. AutomationGraph extends this model for composition. It does not replace the specialized resources that retain runtime authority. Checkfu has no package install step; see [Agent Blueprints](/concepts/agent-blueprints) for what replaces it. See [Author an Agent project](/guides/author-an-agent-project) for the current source-authoring path. ## Session admission freezes execution authority Your product creates a [Session](/concepts/sessions-and-runs) with: * an Agent selector, which resolves to the current AgentVersion or names an exact AgentVersion; * an `environment_id`, which selects a reusable Environment; * optional resources and Vault references. Admission validates the request and freezes the resolved AgentVersion and Environment authority for that Session. Later edits to either resource do not change an admitted Session. The Session event log is durable execution truth. Turns, Runs, child Runs, subagents, checkpoints, recovery, and continuation remain inside the same Session history. A sandbox, runner, harness process, or stream connection is disposable machinery around that truth. ## Replaceable execution lanes A [Harness](/concepts/harnesses-and-models) runs the agent loop. It prepares model context, calls a model, invokes tools, and decides what to do next. Models and harnesses are replaceable execution lanes. They never replace or wrap Agent, Environment, or Session as the common product model. ```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}} %%{init: {"theme":"neutral","themeVariables":{"fontFamily":"ui-sans-serif, system-ui, sans-serif","primaryColor":"#F5F5F4","primaryBorderColor":"#A8A29E","primaryTextColor":"#282828","lineColor":"#78716C","secondaryColor":"#FAFAF9","tertiaryColor":"#FFFFFF"}}}%% flowchart LR A[Your product] --> B[Workspace resources] B --> C[Session admission] C --> D[Durable Session log] C --> E[Admitted execution] E --> F[Environment] E --> G[Harness] G --> H[Model] ``` Checkfu keeps trust, credential custody, Usage, and the durable event log outside the harness. A Vault owns secret-bearing Credential custody; a Connection is the nonsecret governed link to an external account or capability. External actions follow one path: PermissionAssignment → ActionPolicy → ActionApproval when required → live authority and revocation recheck → trusted provider effect → Audit. Credential values never enter Agent or AgentVersion configuration, model context, harness configuration, Session events, Files, Memory, tool arguments, or the sandbox. See [Capabilities](/concepts/capabilities) for the current resource surface and [Tenancy and governance](/concepts/tenancy-and-governance) for permission, policy, and approval semantics. ## Next steps Learn how the mutable Agent head and immutable AgentVersions work. Configure reusable execution environments selected at Session admission. Follow durable execution from admission through Turns, Runs, and settlement. Connect resources without moving Credential values into untrusted execution. See how Workspace identity, permissions, policies, approvals, and audit fit together. Use one desired-state owner across direct and source-backed authoring paths. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.