Skip to main content
Actions are Arg’s typed capability catalog: file operations, integrations, code execution, agent runs and more, each with an id, an input schema and a permission. actions discovers and runs them; agents is a typed wrapper over the agent_run Action; the resource namespaces (comments, notifications, integrations, automations, code, sites, servers) wrap the workspace APIs those Actions sit on. All of it runs as the current identity, under whatever the host granted.

Discover before you run

Action ids and their inputs evolve. list and schema are the contract; do not hard-code an input shape you have not read from schema. describe explains a single field, which is what an agent or a settings UI uses to offer valid values. actions.enabled and actions.readOnly tell you what the host granted before you try: inside a preview they mirror the Actions switch and the file grant, on a server they are always on, and in an agent script they follow the turn. await actions.ready resolves once the host has reported.

Run

Check status on every receipt. A run may be queued or fail after acceptance, and an accepted write must not be retried blindly; give writes an idempotencyKey so a retry after a dropped connection is safe. getRun needs a durable run: a synchronous read without an idempotency key may report a runId for audit only and answer getRun with not_found.

Agent runs

agents.run is the agent_run Action with typed options: agentName to pick a workspace subagent, chatId to continue a chat, model, maxToolIterations, readOnly, and logPath / logFormat to have the run write its own transcript into the workspace. There are two statuses to inspect: the Action’s (run.status) and the agent’s (run.output.status). Both must be terminal and successful before run.output.result is meaningful. Compare with chat, which starts a conversation you can watch and continue in the UI; agents.run is a run you wait for.

Workspace resources

Each namespace maps onto the workspace APIs and keeps their permissions. Paths are cloud workspace paths even under an authenticated arg serve, where fs reads local disk: a comment or an automation refers to the file in the cloud workspace, never to an unuploaded file on your machine. A few notes that keep these honest:
  • notifications.sendToMe targets the current user. sendToUser takes a user id from users.list(). The lower-level send still accepts a users array for fan-out or email-address recipients. Notification input accepts title, body, type, metadata, target and channels; provide at least a title or target. Channels narrow delivery to ios, email and in-app, and each recipient’s preferences still apply.
  • permissions.shareFile and shareFolder grant an Arg user read, write or manage access. The caller needs manage on the path, the recipient must belong to the workspace organization, and a folder grant applies to its descendants. admin is deliberately unavailable because it is a workspace-level permission.
  • integrations.connections never returns credentials, only which providers are connected. integrations.proxy is a separate server capability for Sites and Servers (see capability tokens); it is not general HTTP authority for a viewer or an agent.
  • code.run executes a shell command in the workspace sandbox. Inspect status; a non-zero exit is failed, not an exception.
  • sites frameworks are static, vite, astro, next and worker; access is public or workspace. A build that is not auto-promoted produces a version you promote later. See tunnels and servers for the lifecycle behind servers.
Which hosts serve which namespace is in the availability table. A preview inside Arg serves actions and agents behind the Actions switch; the resource namespaces need a server, CI, arg serve in account mode, a hosted gateway, or an agent script.