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: itsscope 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:
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 for what
replaces it. See Author an Agent project
for the current source-authoring path.
Session admission freezes execution authority
Your product creates a Session 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.
Replaceable execution lanes
A Harness 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. 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 for the current resource surface and Tenancy and governance for permission, policy, and approval semantics.Next steps
Agents and Versions
Learn how the mutable Agent head and immutable AgentVersions work.
Environments
Configure reusable execution environments selected at Session admission.
Sessions and Runs
Follow durable execution from admission through Turns, Runs, and settlement.
Capabilities
Connect resources without moving Credential values into untrusted execution.
Tenancy and governance
See how Workspace identity, permissions, policies, approvals, and audit fit together.
Author an Agent project
Use one desired-state owner across direct and source-backed authoring paths.