Skip to main content
You build an agent by writing a defineAgent() definition in your project. This page starts from the smallest working agent, then serves as the full reference for every option you can configure.

Build a simple agent

You can build a simple agent in just a few steps.
1

Define the agent

An agent needs a slug, name, description, systemPrompt, and model. Create a file in src/agents/ that default-exports the definition.
src/agents/support.ts
The slug is the stable identity Luno OS uses for discovery, routes, CLI commands, and history.
2

Deploy it

Ship the project to the platform so the agent runs in the cloud.
Deploy builds and uploads your project, and the CLI now targets it automatically. See deploy a project for project setup.
3

Use it

Prompt the deployed agent by its slug, or open Agents in the web app.
The response includes a sessionId, the messages, and any error. For repeatable checks, add a test that prompts the agent or asserts its definition. You can also use the agent directly from Slack (see external channels).
That is a complete, working agent. The rest of this page is the full reference for configuring one.

Configuration reference

Every agent ships with some capabilities out of the box, then accepts options to change those defaults or add more. These capabilities are built in, locally and once deployed, with no configuration: defineAgent() accepts these options. The required fields are all you need to start; the rest are optional.
Credentials are declared on the actions an agent uses and resolved when those tools run; the agent-level credentials option only picks whose user-scoped connections apply in Slack / Teams.

Tools

Tools allow agents to do real work: look up a customer, send an email, run a workflow, or call another agent. You list the tools an agent is allowed to use in tools. Tools come in a few forms:

Actions as tools

The most common tool is an action. The same action works as an agent tool or a workflow step; you just add it to tools.
Reach for actions for deterministic single-step capabilities, workflows for durable multi-step sequences, subagents for open-ended delegation, and MCP tools when an external server exposes an MCP surface.

Subagents as tools

A subagent is an agent exposed as a tool to another agent. Use one when a parent agent should delegate a specialized task (research, a stronger model, a different tool set) without sharing the whole parent conversation as instructions. Import the agent and add it to the parent agent’s tools. The tool name is the subagent’s slug, and the tool expects a message string parameter.
Subagent calls appear as tool calls in the parent session, and the child agent runs as its own queued session with its own memory. On deployed projects the parent pauses while the subagent works (it holds no worker) and resumes with the answer, even across restarts; prompts run inline (a request waiting for the reply) wait for the child instead. If the subagent pauses for a human approval, the approval shows up in the parent’s chat and Slack/Teams thread. Canceling the parent cancels its children. Inspect both in run history. To keep the parent going instead, run the subagent as a background task.

Supervising subagents

Use subagents to control delegation from the parent:
Every subagent result ends with a [ref: researcher:call_…] line. The parent can pass earlier refs in the tool’s contextFromRefs input to give a later subagent those exact results as context (for example, the writer receives the researcher’s findings verbatim).

Workflows as tools

A workflow packages a fixed, multi-step sequence, often several actions chained together with durable retries. Import it into tools when you want the agent to trigger that whole sequence as a single, reliable step instead of orchestrating the steps itself.
The tool’s name and parameters are derived from the workflow’s slug and input schema, so you do not declare them by hand. The agent calls it like any other tool, and the workflow runs as a queued child with its normal durability, including sleeps and hookStep waits. Inspect the workflow run and the agent session together in run history. Choose a workflow tool when the work is a known sequence that should run reliably, and a subagent when the work needs open-ended reasoning.

MCP tools

Model Context Protocol (MCP) servers expose tools over a standard protocol. Register them as org apps, connect credentials, inspect the live tool list, smoke-test with integrations execute, author app.action wrappers, then put the app (or picked actions) in tools. integrations actions list on a custom MCP is not the same as listing an official catalog app. It calls the remote tools/list and shows every tool the server advertises. Those tools may not exist as TypeScript app.action(...) functions yet — smoke-test with integrations execute, then wrap what you need.
Do not import defineMcp from @meetluno/luno/agent. See custom apps and MCP.
This is the client side of MCP: your project using an external MCP server. For the reverse, building Luno OS agents, workflows, and triggers from an MCP-capable agent like ChatGPT or Claude, see MCP for agents.

Human approval

Set needsApproval: true on an action or tool that should not run without a person saying yes (refunds, deletes, outbound emails). When the model calls it, the session stays running, the call waits as a pending approval (luno agents approvals list), and nothing runs until someone decides:
Decide from the dashboard, the chat (Slack/Teams buttons), the CLI or the API:
Once every pending call is decided, the session resumes on its own: approved calls run, denied calls reach the model as errors carrying your reason, and the agent finishes its reply. Sessions must run queued (the default in deployed projects) for the pause to survive restarts. A prompt sent with outputSchema pauses the same way and returns its structured output once the paused calls are decided.

Edit before approving

Add editable: true when the approver should be able to fix the call instead of only saying yes or no (a draft email, a post, an amount):
The web app chat shows Edit on the approval card (the input as JSON), Slack shows Edit and approve (a form with the JSON) and Teams adds an editable field with Approve with edits. The API takes editedInput with an approve: POST /agents/{agent}/sessions/{sessionId}/approvals/{approvalId} with { "decision": "approved", "editedInput": { ... } }. The edited input is checked against the action’s input schema before anything is recorded (an invalid one, or an edit on a tool without editable, is rejected with 400). The call runs with the edited input, the agent is told a person changed it, and both the original and the edited input stay in the approval history.

Decide several at once

When an agent pauses on several calls (a batch of drafts, a list of backfills), the web app chat shows a Select all bar with Approve selected and Reject selected. Through the API, send them in one request:
It is all or nothing: if you may not decide one of them, or one edited input is invalid, nothing is recorded and the error names that approval. The agent resumes once, after all of them.

Who can approve

needsApproval: true without approvers lets the person who owns the session (who started it) or a project admin (the project Admin role, or an org owner/admin) decide; in Slack and Teams, any organization member who may approve for the agent (matched by the chat account’s email). Everyone also needs the agent’s approve list (or use list) — see governance. To name who decides, list the approvers (emails of organization members, or Luno user ids):
Two tokens name people per call instead of up front:
A token that resolves to nobody for a call (no owner, an author who is not a member) names nobody: it never falls back to “anyone may decide”. Mix tokens with emails to keep a fallback approver. Any other $… value is rejected when the tool is defined. You can also pick approvers in the web app: open the agent, Configure rail, Approvals, and choose organization members for each tool that needs approval (requires the project Admin role, project:manage). The rule is simple: approvers picked in the web app replace the ones in code for that tool; clear the picker to fall back to the code. The check runs when someone decides, against the current settings. An agent-level Who can approve list (project Governance settings) applies on top: the decider must be on it too.
  • The API, CLI and web app answer 403 to anyone else.
  • In Slack and Teams, the card lists the approvers. A click maps the chat user’s email to an organization member (Slack needs the users:read.email scope, which the Luno app requests); anyone else, or a chat account whose email is not a member’s, gets a notice and the buttons stay for the real approvers.
  • WhatsApp never gets approval buttons: the customer is told the request awaits approval in Luno.
  • Every decision records who decided (the Luno user id, or slack:<id> / teams:<id> when no member matched), where (dashboard, cli, api, slack, teams), when and the reason. The chat view shows it under the message; luno agents approvals list <agent> <session-id> --all and GET /agents/{agent}/sessions/{sessionId}/approvals?status=all return it.

Signals: messages into a running conversation

Send a message into an existing session from outside it — a build result, a webhook, a teammate’s note. The agent sees it as [message] <text> in the same conversation and memory.
  • queue (default): delivered when the current prompt finishes.
  • inject: a running prompt reads it before its next step, without stopping.
  • An idle session wakes up and answers right away, in the same thread and with the same user’s memory. Several pending signals arrive as one message.
HTTP: POST /agents/{agent}/sessions/{sessionId}/signals with { message, mode? }. Only the session’s owner or a project admin can send signals into it (403 otherwise); sessions with no owner (a chat channel, a trigger) are a project admin’s only. Every signal records who sent it (user:<id>). Triggers can deliver signals too: attach a source with session and message instead of prompt, and each event goes into the session it names ([<trigger slug>] <message>). See deliver into an existing session.

Background tasks

Wrap a subagent or workflow tool in background() when the agent should not wait for it. The call returns at once with a task id, the agent keeps working (or finishes its reply), and the result arrives later as a signal from [background:<tool>]:
src/agents/assistant.ts
  • The model sees Started researcher in the background (task …) as the tool result; the child runs as its own queued session or workflow run.
  • When the child finishes or fails, its result is queued into the parent session: a running parent reads it after its current prompt, an idle one wakes up and answers in the same chat thread (Slack, Teams) and with the same user’s memory.
  • Background tasks need queued execution (the default in deployed projects). A prompt run inline (a request waiting for the reply) waits for the tool like a normal subagent or workflow call.
  • A supervisor’s onDelegationComplete hook does not see background results; they reach the parent as messages.

Goals

Send a prompt with a goal and the agent keeps working until the goal is met. After every prompt in that session a judge checks the agent’s latest reply against the goal. While it is not met, the judge’s feedback goes back into the session as a [goal] message and the agent continues, up to maxRuns judged prompts.
Configure the judge on the agent. It is a model id (one structured-output call per judged prompt; pick a cheap model) or your own function. Without goal, the agent’s own model judges and maxRuns is 5.
  • A new goal replaces the session’s previous one. The goal stops as done when the judge says so and as exhausted after maxRuns judged prompts.
  • Prompts that end in an error are not judged. If the judge itself fails, the goal stays active and the agent stops until the next prompt.
  • Goals need queued execution; follow-ups reply in the same chat thread as the prompt that set the goal.

Multi-agent patterns

Several agents can work on one task. Pick the pattern by who decides what runs next:

Handoffs

A subagent works for its parent and reports back. A handoff instead gives the conversation away: the target agent answers the user in the same session, with the whole transcript, and keeps answering later messages.
src/agents/triage.ts
  • Each target becomes a handoff_to_<slug> tool with a reason and an optional summary. Calling it ends the current turn; the target replies right away, seeing [handoff:triage] … with the reason and summary.
  • Later prompts to the session — through the original agent’s API route, a chat thread (Slack, Teams), a signal, or a trigger — go to the target. Chat replies keep landing in the same thread.
  • Handing off back to the agent that started the session returns the session to it.
  • In direct messages to the shared Slack / Teams bot, the agents a workspace lets people switch to are added as handoff targets of whoever answers, on top of the ones in code.
  • The session stays listed under the agent that started it, and memory stays that agent’s notes about the user, so the target sees the same per-user notes.
  • Handoffs need queued execution (the default in deployed projects). Like any signal, the target’s first reply runs without the user’s personal credentials; later prompts carry them as usual.

Skills and files

Skills are reusable instructions in src/skills/. Files are static project context in src/files/. Both materialize under /workspace/agent before a prompt runs, so the agent can read them like local files. That directory persists across sessions for shared context — not for git checkouts or package installs (use /workspace/session for those). See Sandboxes.
files is a path (or list of paths) under src/files/: a set directory, multiple sets, or specific files.
See project skills and files for the file formats.

Memory

Memory is what lets an agent remember. It is on by default and has three parts: Each user gets their own notes and recall: a dashboard or API user by their account, a Slack or Teams user by their chat id. Runs without a user (triggers, schedules, API keys) write the agent’s shared notes instead, which user conversations can read but never change, so nothing one user says leaks to another. Memory is stored in your project’s database, and you can read or clear it per user from the agent’s Memory tab. Each user sees their own notes and the shared notes there; other users’ notes are visible only to project admins (the project Admin role, or org owners/admins), who are also the only ones who can clear them. Set memory: false for a stateless agent, such as a deterministic classifier or a one-shot extraction agent:
Memory is agent-curated: you don’t pre-load it from the definition. Put stable, author-provided context in the systemPrompt or in files. To shape what the agent tracks, give it a markdown template:
Continue a conversation by passing the same sessionId to the next prompt. See run agents for session commands. Long sessions are compacted automatically when they near the model’s context window: the older part of the conversation is replaced by one summary. To control what of the history reaches the model, add a processor to inputProcessors: it sees the session history and recalled messages on every step.

Observational memory

For agents with long-running sessions (an assistant in a busy Slack thread, a support agent working one ticket for days, a tool-heavy agent that reads large pages), turn on observational memory. A second, cheap model watches the conversation and keeps a dated log of what happened; once the history the model has not observed yet passes a token threshold, the observed messages leave the prompt and the log takes their place. When the log itself grows large, it is condensed again.
  • It replaces compaction for that agent: instead of one summary when the context is nearly full, the prompt stays small all the time, which also keeps it cheaper and more cacheable.
  • Observations are per session. To remember things across sessions, keep notes (workingMemory) and recall on.
  • The session transcript is not changed: the chat and the dashboard still show every message.
  • Cost: extra calls to the observation model, roughly one each time a few thousand tokens of new conversation build up, billed like any other model usage. With the default model this is usually a small fraction of what the agent’s own model costs for the same history. If the observation model fails, the prompt still runs, with the history it has not observed yet.
  • Attachments are not sent to the observation model; it sees their names.

Models

The model is the LLM that powers the agent’s reasoning and tool use. Luno OS supports hundreds of models from providers like Anthropic, OpenAI, and Google, chosen by ID in vendor/model-id format.

Model selection guide

Approximate list prices are USD per 1M tokens (input / output), from the live gateway catalog. Any catalog ID works as model. Model ids change as providers ship new generations — prefer the live catalog when picking an id. These facts were last reviewed in October 2026. For the full, current list of model IDs, see the Luno OS models catalog. Copy the Model ID column exactly — IDs are opaque catalog strings, not display names you can reformat. Some models use dots in version segments (openai/gpt-5.6-sol, google/gemini-3.5-flash); others use hyphens (alibaba/qwen-3-14b). Do not kebab-case a version number from the model name: openai/gpt-5-6-sol is invalid even though the product is called “GPT 5.6 Sol”. Unknown IDs fail at build and deploy time. Hosted workers route through the platform automatically, so deployed agents need no provider keys. To run cloud inference on your own provider API keys instead of platform credentials, connect them in Managed services — not as app credentials. You can use thinkingLevel to control the model’s reasoning effort when the provider supports it. It defaults to medium; valid values are provider-default, none, minimal, low, medium, high, and xhigh.

Fallback models

List up to three fallbackModels. When a call to model fails (provider outage, rate limit), the agent retries the same step on the next model in order. Usage is billed to the model that actually answered.

Per-prompt model

A prompt can run on a different catalog model without changing the agent: pass model to agent.prompt(), in the HTTP prompt body, to the SDK, or with luno agents prompt --model. It wins over the agent’s and the mode’s model; fallbackModels still apply. Unknown ids are rejected with 400.

Modes

Modes are named variants of one agent — say, plan that only reads and thinks harder, and build that edits. Each prompt runs in one mode; the session remembers the last one, so later prompts that name none stay in it.
Mode names are lowercase (a-z, digits, -, _). defaultMode defaults to the first mode. defineAgent rejects unknown tool names and malformed model ids, and the build checks mode models against the catalog. A prompt picks its mode with mode: agent.prompt({ message, mode: "build" }), { "message": "…", "mode": "build" } on POST /agents/{slug}, or luno agents prompt coder --message "…" --mode build. The resolution order is the prompt’s mode, then the session’s last mode, then defaultMode; an unknown mode is a 400. In the dashboard, agents with modes show a mode and a model picker in the chat composer.

Guardrails

Processors check or change what goes into and comes out of the model. inputProcessors run on the user’s message before the model sees it; outputProcessors run on the reply. Ready-made ones come from @meetluno/luno/processors; the ones that ask an LLM take model: gatewayModel("vendor/model"), so the check goes through Luno’s gateway and is metered like any other call.
When a guardrail blocks a message, the agent does not call the model; the reply explains it was blocked and the session records why. You can also write your own processor (an object with an id and a processInput or processOutputResult function).

Guardrails inside a workflow step

Text that never reaches an agent (a PDF, an email body, a form answer) can go through the same PII and prompt-injection detectors with guardText, in a workflow step or action:
findings lists what was flagged ({ guard: "pii", type, confidence, start, end } or { guard: "injection", type, confidence, reason }), never the PII values themselves. Injection runs first, so blocked text never reaches the PII check. It throws GuardBlockedError (with findings) when injection: "block" flags the text or flagged PII cannot be redacted, and a plain Error when the detection model fails: text that could not be checked is never passed on. Each enabled guard is one model call.

Structured output

By default agent.prompt() returns conversational text in result.messages. When you call the agent from code (a workflow, action, or script) and need a typed object instead, pass an outputSchema (Zod) on the call. outputSchema is a per-prompt option, not a defineAgent() field, so the same agent can return free text on one call and structured data on the next. Read the parsed, typed result from result.output:
Without outputSchema, result.output is undefined and you read the reply from result.messages.

Structured output over HTTP, the SDK and the CLI

Outside TypeScript, send outputSchema as a JSON Schema object ("type": "object", at most 32 KB) in the prompt body. The prompt is queued as usual (202 with sessionId and runId); once the session completes, the session detail (GET /agents/{slug}/sessions/{sessionId}, with messages included) carries the validated result as output:

Schema design: model the shape precisely

Design the schema around the outcomes you actually expect, not one flat object that tries to cover every case with optional fields. This is both better type safety (each result is exhaustively typed) and it sidesteps a hard provider limit: Anthropic’s native structured output rejects schemas with more than 16 union-typed parameters — every .nullable() / .nullish() field compiles to a T | null union, so a wide flat object blows past the cap and fails at request time with Schemas contains too many parameters with union types. When a result has variants that carry different fields, use a discriminated union keyed on a literal so each branch declares only its own required fields:
Prefer required fields over .nullable()/.nullish(), and reach for discriminated unions over large optional-heavy objects. OpenAI/Azure strict mode requires every property key in required — Zod .optional() / .nullish() omit keys and the API rejects the schema before the model runs. Luno OS rewrites those wrappers to .nullable() on the wire so calls still succeed, but authoring with .nullable() (or a discriminated union) matches what providers return and stays under Anthropic’s union-parameter limit more predictably.

Structured output with tools

When an agent has tools and you pass outputSchema, Luno OS runs a multi-step tool loop: the model calls tools, then returns a schema-validated result. Expect at least two LLM steps (tool call + structured result). See the AI SDK troubleshooting guide for the same step-count rule. Luno OS applies vendor-specific fixes automatically: Gateway model tags (reasoning, tool-use, vision, …) do not indicate structured-output support. Pick models from the models catalog for pricing and capabilities, but rely on the table above for outputSchema reliability. outputSchema works in agent.prompt() and workflow llmStep() steps (agentStep takes output). Over HTTP and the CLI, pass it with a prompt (outputSchema in the request body, or luno agents prompt --output-schema / --output-schema-file); the validated result is returned as output. Agents can read information from the live web through two built-in host tools, injected when Luno OS can resolve a web provider:
  • web_search searches the web by query.
  • web_fetch fetches readable page text from a URL.
In hosted workers the platform can proxy web search automatically. Make the prompt explicit about when to search:

Dashboard overrides

Code holds an agent’s base values. In Studio, the agent’s Configuration tab can override its instructions, model, autonomy, max steps, and turn off tools the code declares. Changes are saved as a draft and published as a new version (needs the project project:deploy permission); the runtime applies the published override on top of the code from the next prompt, including workflow agent steps and triggers. Reset to code drops it. Autonomy is Acts on its own (as_coded: only tools marked needsApproval wait for a person) or Always asks (always_ask: every tool declared in code waits for approval). Before you change an agent’s prompt or tools in code, check its Configuration tab: a published override wins over what you deploy. An override model, like a per-prompt model, must be in the organization’s catalog (Governance → Models); the model in code is not checked against it. A workflow agent step can be overridden the same way for that step only (see there).

Workflow visibility

Deployed agents receive a read-only list_workflows tool that lists project-defined workflows which invoke them, along with the deployed triggers that start each workflow. Trigger details include configured schedules and timezones plus live active, disabled, or completed status. This lets an agent recognize that it may be running as one step in a larger workflow and understand how often that workflow is configured to run. Listing a workflow does not make that workflow callable by the agent; callable workflows must still be included in defineAgent({ tools }). You can inspect the same relationship from the CLI:

Ephemeral triggers

Every agent is given two built-in tools (set_trigger and list_triggers) so it can schedule its own work without a deploy. The agent can create a cron, webhook, or poll trigger on itself, then update, pause, or delete it later. These are ephemeral triggers: the agent manages them at runtime and they live in the database, separate from the triggers you write in src/triggers/. list_triggers also reports project-defined triggers that invoke the agent directly or through a workflow containing it. Workflow triggers are identified by targetKind: "workflow" and include the workflow slug. These tools are injected automatically; there is no defineAgent() option to add them, and they require no configuration. They are how an agent honors a request like “remind me about this in an hour” or “check the deploy every morning and message me if it’s red”: the agent creates a trigger on itself from inside the conversation instead of needing you to write one. Ephemeral triggers support the same three kinds as code triggers: Ephemeral poll triggers run a code mode script on each tick. The script can call the agent’s tools; its last non-empty line of JSON becomes the trigger payload. Empty output or null skips the run. For webhook triggers, pass endpoint plus an optional payload matcher — a shallow map of dot-paths to exact values (e.g. { "type": "invoice.paid" }). Omit payload to accept any JSON body. That matches the role of defineWebhookSource({ payload }) in project code: the matcher is the gate for which deliveries fire the agent. list_triggers returns the compiled payload schema for webhook triggers. The agent can give a trigger a lifecycle so it stops on its own: maxExecutions for a fixed number of runs (a single future reminder is just maxExecutions: 1) or until for an expiry time. When an ephemeral trigger fires it starts a new agent session and appears in History alongside every other run. When you want a sustained, deploy-time automation instead (a schedule or webhook wired to an agent in code), define it in src/triggers/. See run agents from triggers and the triggers section.

Browser use

Browser use means driving a real browser: clicking, filling forms, navigating multi-step flows, and taking screenshots. That goes beyond reading page text with web_fetch.
Native browser automation is coming soon. Until then, wrap browser work in a task-specific action or a workflow step rather than exposing a general browser to the agent.

Sandboxes

Every agent already gets a /workspace with built-in bash, read, write, and edit tools, running in-process with no VM. The workspace has two mounts: Do not put git repositories or package installs under /workspace/agent. That shared filesystem is for files and skills the agent reuses across prompts — not a checkout or node_modules. Clone and install under /workspace/session (or another session path you choose). Env setup installs belong on the root filesystem (see Env setup), not under /workspace/agent. This default workspace handles a surprising amount on its own: manipulating files, processing text and data, and running shell commands and scripts. Many platforms boot a full sandbox VM for any code execution at all; Luno OS gives agents this lightweight bash environment by default, so most agents never need a VM. The workspace starts empty unless you attach content: Use defineSandbox() to attach project file sets or seed specific files directly in code:

Code mode

In the default in-process workspace, an agent can use code mode to call its tools from a JavaScript or TypeScript script. This is useful when the agent needs to call several tools, loop over results, filter data, or combine tool output without sending every intermediate result back through the model. Code mode is available automatically—there is nothing to add to defineAgent(). The agent runs a script with js-exec through its built-in bash tool and calls only the tools already available to that agent:
Tool names containing hyphens require bracket notation (tools["tool-name"]). Tool inputs still use their normal schemas, credentials resolve normally, and a script cannot call tools that are not attached to the agent. Errors from a tool fail the script and are returned to the agent.
The js-exec tool bridge is available in the default in-process workspace, not in VM-backed sandboxes. In a VM, use the installed node or python runtime for scripts and call agent tools directly from the model.
The in-process bash is not a full machine, though. You can easily enable a VM-backed sandbox with defineSandbox({ mode: "vm" }) when your agent needs capabilities the default workspace can’t provide:

Hosted VM resources

Hosted VMs use a small CPU/memory request with no hard limits (they burst as needed). Author size (small / medium / large) is accepted for backward compatibility but ignored on hosted cloud. Local microsandbox (pnpm dev) may still map size presets to guest resources. Billable VM time is charged per second of sandbox wall-clock at a flat rate. Persistent agent files live on the shared filesystem at /workspace/agent; session scratch is ephemeral under /workspace/session. The bash tool accepts optional timeoutMs so long installs/builds can run past the 180s default (hard-capped at 10 minutes). For servers that must keep running, background them (nohup … & + log + health poll) — do not block bash on them.

VM credentials and GitHub

Credential env injection and built-in GitHub clone are VM-only. Attach credentials on the sandbox, map them into env, and optionally bootstrap a repository with git.clone. Pass an app’s credential — for example a GitHub app you authored with defineIntegration (see custom integrations).
With the built-in git.clone helper, Luno OS clones into /workspace/session (default /workspace/session/repo). Clones are shallow (--depth 1) by default for fast startup; set shallow: false for full history. Use branch for a branch/tag tip, or commit for an exact full 40-character SHA (GitHub supports fetch-by-SHA; abbreviated SHAs and git clone --branch <sha> do not). Remounts and later prompts in the same session skip re-clone when the repo already exists. If you clone or install yourself from bash or a skill (instead of git.clone / setup), keep that work under /workspace/session — never clone repos or install packages into /workspace/agent. The shared filesystem is only for shared files and skills across sessions. Secrets are merged into every VM exec (not create-time sandbox env). Tokens are model-visible inside the VM so git (and gh if you install it) can authenticate.

Env setup (setup)

setup is an install-style recipe for the environment root filesystem — clone-independent global and system packages the agent needs every session (CLIs, runtimes, browsers). Prefer it over installing the same tools from scratch on every prompt. Do not use it for long-lived servers or for repo-local npm install that depends on a cloned tree (run those under /workspace/session after clone). Hosted env Images are built from setup without the shared filesystem mounted. After setup runs, Luno OS clears /workspace/agent so session create can attach the shared filesystem. That means:
  • Install onto the root filesystem only (/usr, /usr/local, $HOME, Playwright’s default browser cache, etc.).
  • Do not write under /workspace/agent in setup — those paths are deleted before the env Image is saved.
  • Do not expect deployed files or skills under /workspace/agent to exist during env setup (the shared filesystem is not mounted yet). Put scripts you need during setup inline in the setup commands, or install tools to root-disk paths.
Typical setup jobs: Startup order on the first prompt of a session: create VM → inject env → git bootstrap → setup commands (fail-fast on non-zero exit) → agent tools. Remounts and later prompts in the same session skip setup (and skip git clone when the repo already exists). On hosted VMs:
  • Deploy and luno agents snapshot <slug> build an org-scoped env Image (root filesystem snapshot) from setup (shared across agents with the same setup fingerprint).
  • Cold boots prefer that env Image and skip re-running setup; git clone still runs at session start into /workspace/session.
  • If no env Image is ready yet, the first session runs setup inline (with the shared filesystem already mounted) and enqueues a background build.
  • Deploy also reconciles /workspace/agent files and skills onto the shared filesystem in parallel with env Image builds, so first-prompt file prepare is usually a noop.
What’s already in the VM Built-in git.clone uses the git binary plus a credential helper that reads GH_TOKEN / GITHUB_TOKEN — it does not require gh. If a managed OAuth provider redacts tokens, the dashboard offers a Request access flow (/{org}/integrations?requestAccess={app}). In both modes the agent itself runs in the Luno OS worker and works through its bash, read, write, and edit tools; sandbox.mode only changes where those tools execute. A bash call with mode: "vm" runs the command inside the VM and returns its output to the agent, rather than running in-process. The agent reaches into the VM through tools; it never runs inside it. For everything else, we recommend leaving mode unset on defineSandbox() (the in-process bash is faster to start and saves you money because you aren’t running a VM).

Next steps

Run agents

Prompt agents from the CLI and inspect sessions.

Test agents

Add tests and local prompts before deploying agent changes.

External channels

Route Slack messages to an agent.

Agent runs

Review conversation history, tool calls, traces, and errors.