How it works

A mental model for agent functions, the managed harness, durable sessions, capabilities, and triggers

OpenComputer runs agents defined as TypeScript functions. You describe the agent for the current step; OpenComputer supplies the managed harness that calls the model, executes tools, streams output, and records the durable session.

The runtime model

Your agent function describes the next step

The default export is a synchronous function. It reads the current input, selects resources with hooks, and returns instructions:

import { useInput, useModel, useTool } from "@opencomputer/agent";
import { inspectRepository } from "./tools/inspect-repository";

export default function Agent() {
  const input = useInput();

  useModel("anthropic/claude-sonnet-4.6");
  useTool(inspectRepository);

  return `
    You are a release-readiness agent.
    Inspect the repository before giving a RELEASE or DO NOT RELEASE verdict.

    Current request: ${input.text ?? "Review the configured repository."}
  `;
}

The function does not call the model or execute the tool. Each hook contributes to the effective configuration for the next model step.

The harness performs the loop

OpenComputer owns the agent harness. For each step it:

renders the agent function;
builds a model request from the returned instructions and selected resources;
streams the model response;
validates and executes requested tools;
records the resulting events; and
renders again when another model step is required.

Because a function can render more than once during a turn, keep it synchronous and free of external side effects. Network calls and mutations belong in tools or remote MCP servers.

A session makes execution durable

A session stores the conversation and runtime events across turns. Clients can disconnect, reconnect, and continue without reconstructing the agent’s history themselves.

Every session remains pinned to the immutable deployment it started with. A new development sync or production deployment affects new sessions, not code already running inside an existing session.

Memory is what outlives a session: project-scoped documents that the agent function reads at render with useMemory, that the model saves through memory tools, and that the owner reads, edits and exports.

Capabilities are selected, not executed, during render

Use the narrowest capability that fits the work:

Capability	What the harness receives
`useTool(tool)`	One typed operation implemented by your project
`useMcpServer(server)`	A collection of tools advertised by a remote MCP server
A skill under `skills/`	Reusable instructions and supporting resources
`useMemory(memory)`	The bound documents’ text and the tools that save to them

The model decides whether to request an available tool. The harness remains responsible for validating the request, executing it, and recording the result. See Agent capabilities for the full comparison.

Deployment registers; rendering selects

A deployment packages the agents and resources that are allowed to exist. A render selects the tools, instructions and other resources for one model step.

Managed GitHub access is session-wide: its token carries the deployment’s declared GitHub permissions. Conditional useConnection() calls do not change that token’s authority.

Development and Production point to different deployments and keep operational configuration—such as secrets, schedule state, and webhook tokens—separate. Read Deployments and environments for that lifecycle.

Remember this

The agent function decides what the agent is for this step.
The harness decides how to run that step.
The session remembers what happened.