Coming from Claude Managed Agents

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:

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:

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 and pin it with the Checkfu extension fields model.provider and model.model_credential_id before starting a Session; see 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:

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:

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:

{
  "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:

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 for the current resource surface and 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 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 before depending on a managed runtime in production.

Migration sequence

Create the target Workspace and Environment.
Create each Agent. The first create produces AgentVersion 1.
Move Skills, Files, MemoryStores, Connections, Vaults, and Credentials into their corresponding resources.
Recreate PermissionAssignments, ActionPolicies, and approval behavior explicitly.
Create a pinned Session and compare its durable event history with your source behavior.
Move triggers to Automations only after direct Session execution is correct.

Create and version an Agent

Create the authored resource and inspect immutable AgentVersion history.

Environments

Configure the reusable execution environment selected by a Session.

Capabilities

Map Vaults, Credentials, Connections, Files, Memory, Skills, and tools.

Tenancy and governance

Map identity, PermissionAssignments, ActionPolicies, approvals, revocation, and Audit.

Author an Agent project

Keep desired state behind one active authoring owner.

Migrate from your own loop

Replace a hand-built loop with Session creation, events, and durable history.

Get started

Agents

Sessions

Environments

Tools

Context

Automations

Permissions

Security

Billing

Deployment

Coming from Claude Managed Agents

The core mapping

Agent lifecycle

The one field a ported request must add

Environments and Workspaces

Vaults, Connections, and governance

Tools, MCP, Skills, Files, and Memory

Composition and desired state

Parity and availability

Migration sequence

Create and version an Agent

Environments

Capabilities

Tenancy and governance

Author an Agent project

Migrate from your own loop

​The core mapping

​Agent lifecycle

​The one field a ported request must add

​Environments and Workspaces

​Vaults, Connections, and governance

​Tools, MCP, Skills, Files, and Memory

​Composition and desired state

​Parity and availability

​Migration sequence

Create and version an Agent

Environments

Capabilities

Tenancy and governance

Author an Agent project

Migrate from your own loop

The core mapping

Agent lifecycle

The one field a ported request must add

Environments and Workspaces

Vaults, Connections, and governance

Tools, MCP, Skills, Files, and Memory

Composition and desired state

Parity and availability

Migration sequence