Skip to main content
An Agent defines reusable behavior. A Session keeps a conversation and its execution history. A Run carries out one request within that Session. Consider a support assistant that drafts replies to customer tickets.

Agent

Create a Support Agent with instructions for writing replies. Select its harness and a compatible model explicitly: the harness controls the execution loop, and the model generates responses. There is no default harness. You can also bring your own harness, including a harness built for your support workflow. Creating the Agent creates immutable AgentVersion 1. A material change to its configuration automatically creates the next version; there is no separate publish step. See Agents.

Session

Start a Session for ticket 482. When the Session starts, Checkfu selects and freezes the AgentVersion and Environment configuration for that Session. The Session keeps the ticket’s inputs, responses, and execution events as durable history. If you change the Agent’s instructions, Checkfu creates Version 2. The ticket’s existing Session stays on Version 1. A new Session that selects the Agent’s current version uses Version 2. You can also select an exact version when starting a Session. Your application can send messages through the Session API. If the ticket comes from a chat app, your service owns the messaging adapter.

Run

Send “Draft a reply to ticket 482.” A Run carries out that request. After it finishes, send “Make it shorter” as a separate follow-up request. That work belongs to a new Run in the same Session. Model generations, tool rounds, waits, and recovery continue the work of the original Run. They do not create new Runs by themselves. Read the Session’s recorded outcomes to determine what finished; a closed stream or a message saying “done” does not establish that the work finished. See Sessions for the event lifecycle.

Context

Give the assistant access to help articles through its Context configuration. The Session freezes the rules for selecting resources. Those rules can still select fresh content later. For this ticket, when Checkfu takes up the next new request after the current task finishes, a new turn begins. A FileTree reference set to latest can then select a newer revision. That turn keeps its exact selected context through waits and recovery. Recovery checks current access to the original resources; it does not silently replace them. To look up an order, configure a tool and the account Connection it needs. To schedule a follow-up, use an Automation. Each has its own configuration and lifecycle.

Execution

An Environment supplies reusable packages and network configuration. The Session owns the work and its private workspace. Choose the native tools and permissions the Agent needs; Checkfu realizes the supported execution path automatically. Reuse Files, Skills, Memory and repository content through their normal resource operations. External browsers and desktops are tools on an authenticated Connection. Their provider owns machine state, login, viewing and physical cleanup.

Permissions

Selecting a resource does not grant access to it. For a connected action, Checkfu checks permission, evaluates policy, and requests approval when the policy requires it. An approval applies to the exact proposed action. It cannot grant missing permission or override a denial. See Permissions and Approvals. Custom tools that your application executes follow their ActionPolicy directly; they have no inherent Connection or PermissionAssignment gate.

Deployment

Use Checkfu-managed Cloudflare hosting. Customer-operated Cloudflare is a deployment direction that is not yet qualified. Deployment ownership is separate from your harness and model choices. Bringing your own harness (BYOH) chooses the engine; bringing your own key (BYOK) chooses model access. See Deployment.

Details

The example covers the core objects. These pages explain the remaining boundaries:
  • Resource boundaries covers Workspace scope, versioning, and the full resource hierarchy.
  • Source validation and authoring cover Agent configuration. Graphs describe composition. These source forms use canonical resource operations, with at most one active owner of desired configuration.
  • Checkpoints explains recovery. The Session log does not replace provider effect receipts or the authoritative Usage facts used for Billing.
  • Security covers isolation and credentials. Custodied secrets resolve at the trusted effect boundary; keep your own secrets out of prompts, context, tool arguments, and results.
  • Retention explains how Standard retention and ZDR differ in persistence, recovery, replay, and export.
For availability in a particular deployment, check capability status. For exact terms, see the glossary.