> ## 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. # Coming from Claude Managed Agents > Map Claude Managed Agents resources onto Checkfu's Agent, AgentVersion, Environment, Session, Vault, and governance model. Checkfu keeps the central Claude Managed Agents shape familiar: create an Agent, create an Environment, then create a Session that selects both. Agents are versioned, Sessions keep a durable event log, Sessions reference Vaults for Credential custody, and resources can be attached at Session creation. This page maps concepts. It is not a drop-in compatibility promise. Use Checkfu's typed API, SDK, and CLI contracts for exact requests and responses. ## The core mapping | Claude Managed Agents | Checkfu | What to carry over | | - | - | - | | Workspace | Workspace | The normal isolation, authoring, and policy boundary. Tenant exists but normally remains implicit. | | Agent | Agent | The mutable authored resource with a stable identity. | | Agent version | AgentVersion | The immutable configuration selected for execution. Creating an Agent makes Version 1; a material update makes the next Version. | | Environment | Environment | A reusable execution environment selected by `environment_id` for each Session. Self-hosted definitions retain their bounded account or Organization visibility. | | Session | Session | Durable execution truth spanning conversation history, Turns, Runs, recovery, continuation, and observations of harness-native subagents. It does not expose in-Session child-agent orchestration. | | Vault | Vault | The Workspace-scoped custody boundary for secret-bearing Credentials referenced by a Session. | | Vault credential | Credential | Secret-bearing authorization material. Its value never enters model context, harness configuration, Session events, Files, Memory, tool arguments, or the sandbox. | | File or resource | File and Session resources | Durable resources mounted or made available through Session admission. | | Memory store and memory versions | MemoryStore and MemoryVersion | Durable memory with immutable history. | | Skill | Skill and SkillVersion | Reusable capability content selected by the Agent and frozen for execution. | | Multiagent coordination | Automation and AutomationGraph | Checkfu composes agents through Automations rather than in-Session child threads; Outcome is graded two-agent coordination on that graph. | | Scheduled autonomous work | Automation and AutomationRun | Triggered composition with one durable record per firing. | | Self-hosted execution | Self-hosted Environment | Execution on your infrastructure behind the same Agent, Environment, and Session ontology. | ## Agent lifecycle The Agent mapping is direct: ```text theme={"theme":{"light":"github-light","dark":"github-dark"}} create Agent → AgentVersion 1 update Agent → next immutable AgentVersion create Session → current or explicitly pinned AgentVersion ``` Creating and updating an Agent directly produces its immutable Version history. The Agent is the mutable authored resource; AgentVersion is the configuration selected for execution. ### The one field a ported request must add Checkfu serves a CMA-shaped managed-agent contract through several agent-loop implementations, so an Agent names the one it runs on. `harness` is **required** on create and has no default. A request body ported from Claude Managed Agents therefore needs exactly one added line: ```ts theme={"theme":{"light":"github-light","dark":"github-dark"}} const agent = await checkfu.agents.create({ name: "reviewer", model: "claude-opus-5", harness: "claude-code", // ← the only addition; requires a qualified release in this deployment system: "Review the diff and cite the failing case.", }) ``` Omitting it is a validation error that lists the harnesses this deployment serves, rather than a create that silently succeeds against whichever loop the deployment happened to default to. The value is a harness catalog name, optionally pinned to one published profile version (`name@3`); it is frozen into every AgentVersion, and `sessions.create` can override it for a single Session through `agent: { type: "agent_with_overrides", … }`. The grammar also admits a Workspace HarnessProfile name. Session admission resolves a profile-only bare name to its current version, or `name@3` to that exact profile version. A bare name shared with the deployed catalog is ambiguous; pin the Workspace profile version to select it. The profile must have current signature-verified conformance evidence for the selected Environment, and its release must be launchable in this deployment. Otherwise Session creation returns a typed conflict naming the missing qualification; it never substitutes another harness. Availability still gates execution: naming a harness this deployment cannot launch yet is accepted on create and refused at Session admission, with the refusal naming the harness you chose. Checkfu never substitutes a different one. The example model is BYOK. Add an Anthropic provider key in [Model credentials](https://app.checkfu.com/model-credentials) and pin it with the Checkfu extension fields `model.provider` and `model.model_credential_id` before starting a Session; see [Model access](/concepts/harnesses-and-models#model-access). A CMA client that sends only `model.id` is unchanged: that model routes on Checkfu-managed supply, which must serve it. A Session can select the current AgentVersion by Agent ID or pin an exact Version: ```ts theme={"theme":{"light":"github-light","dark":"github-dark"}} const session = await checkfu.sessions.create({ agent: { type: "agent", id: agent.id, version: agent.version, }, environment_id: environment.id, }) ``` Admission freezes the resolved AgentVersion and Environment authority. Updating either resource later does not change that Session. ## Environments and Workspaces An Environment is the reusable sandbox or self-hosted execution configuration used by Sessions. Multiple Sessions can select the same Environment while receiving separate execution custody. Do not map development, staging, or production onto Environment names as isolation boundaries. In Checkfu those are separate Workspaces. A self-hosted Environment may widen selection visibility to authorized accounts in the same Tenant or Organization, but it never shares Session sandboxes or data. ## Vaults, Connections, and governance Pass `vault_ids` when a Session needs Credential custody: ```ts theme={"theme":{"light":"github-light","dark":"github-dark"}} const session = await checkfu.sessions.create({ agent: { type: "agent", id: agent.id }, environment_id: environment.id, vault_ids: [vault.id], }) ``` The named CLI command accepts the same Session create body. Put your actual resource IDs in `session.json`, then run `checkfu session create --input @session.json`: ```json theme={"theme":{"light":"github-light","dark":"github-dark"}} { "agent": { "type": "agent", "id": "agent_0123456789abcdef0123456789abcdef" }, "environment_id": "env_0123456789abcdef0123456789abcdef", "resources": [ { "type": "memory_store", "memory_store_id": "memstore_0123456789abcdef0123456789abcdef", "access": "read_only" } ], "vault_ids": ["vlt_0123456789abcdef0123456789abcdef"] } ``` The CLI validates `--input` against the same Session operation as the API and prints the created Session ID. A referenced resource still needs the applicable permission and must pass Session admission. A Vault owns secret-bearing Credential custody. A Credential is authorization material with no public read-back value. A Connection is the nonsecret governed link to one external account or provider capability; it is not the token, password, API key, or OAuth grant. Every connected effect follows the same trust path: ```text theme={"theme":{"light":"github-light","dark":"github-dark"}} PermissionAssignment → ActionPolicy → ActionApproval when required → live Connection, permission, policy, egress, and revocation recheck → Credential attached at the trusted provider edge → provider effect → Audit ``` An ActionApproval never replaces permission, and an earlier approval cannot preserve a revoked Connection. Credential values never enter Agent or AgentVersion configuration, model context, harness configuration, Session events, Files, Memory, tool arguments, or the sandbox. Recovery never turns an uncertain external effect into a safe retry. See [Capabilities](/concepts/capabilities) for the current resource surface and [Tenancy and governance](/concepts/tenancy-and-governance) for identity, permission, policy, approval, revocation, and Audit. ## Tools, MCP, Skills, Files, and Memory Move reusable configuration to the resource that owns it: * declare tools and MCP servers on the Agent; * register third-party access through nonsecret Connections and Vault-owned Credential custody; * put reusable procedures in versioned Skills; * upload durable content as Files and attach it through Session resources; * put durable learned state in MemoryStores rather than in a harness-specific transcript. The harness may change. The common resources and the durable Session event log do not. ## Composition and desired state Map scheduled or event-triggered autonomous work to Automation. Use AutomationGraph for composition while each specialized resource retains its own runtime authority. UI, HTTP, SDK, CLI, and MCP are interfaces over the same canonical resource operations, not independent owners. YAML and Git may supply desired state, but they do not become a second control plane, reconciler, scheduler, policy engine, or transcript. A resource has zero or one active desired-state owner. References and proposals claim nothing; adopting or transferring an existing resource requires an explicit, audited handoff. See [Author an Agent project](/guides/author-an-agent-project) for the current source-authoring workflow. ## Parity and availability In-Session multi-agent orchestration (coordinator rosters, child SessionThreads, and the advisor) is a deliberate departure, not a gap: Checkfu composes agents through the Automation graph, and an Outcome is coordination between two agents done through that graph. Availability is a separate question: a behavior may still be restricted by provider qualification or rollout policy in a particular installation. Review [capability status](/getting-started/status) before depending on a managed runtime in production. ## Migration sequence 1. Create the target Workspace and Environment. 2. Create each Agent. The first create produces AgentVersion 1. 3. Move Skills, Files, MemoryStores, Connections, Vaults, and Credentials into their corresponding resources. 4. Recreate PermissionAssignments, ActionPolicies, and approval behavior explicitly. 5. Create a pinned Session and compare its durable event history with your source behavior. 6. Move triggers to Automations only after direct Session execution is correct. Create the authored resource and inspect immutable AgentVersion history. Configure the reusable execution environment selected by a Session. Map Vaults, Credentials, Connections, Files, Memory, Skills, and tools. Map identity, PermissionAssignments, ActionPolicies, approvals, revocation, and Audit. Keep desired state behind one active authoring owner. Replace a hand-built loop with Session creation, events, and durable history. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.