> ## Documentation Index > Fetch the complete documentation index at: https://docs.boat.dev/llms.txt > Use this file to discover all available pages before exploring further. # Agents in your product > Use the integrated agents in your product, or bring your own harness with a daemon in the sandbox. ## Use the integrated agents Before you write an agent loop, look at what the sandbox already runs. * `boat prompt` drives five coding agents: Claude Code, Codex, pi, OpenCode and Prime Agent. * It has memory, parallel conversations, streaming events and a model choice for each prompt. * For most platforms, it replaces the [daemon](#bring-your-own-harness-the-daemon-pattern). [Integrated agents](/integrated-agents) explains how it works and every way to customize it. These tips matter when you build a product on it: * **Use your user's key, not yours.** Create the sandbox with `--no-env`. Pass the user's key as a per-sandbox variable: `-e ANTHROPIC_API_KEY=…`, `-e OPENAI_API_KEY=…`. Every harness reads it. Nothing of your account is on the sandbox. Keys are per sandbox. So users whose keys must stay apart get their own sandbox ([patterns 1 and 3](/platform-guide/patterns)). A sandbox that you pay for can serve many users through conversations ([pattern 2](/platform-guide/patterns#pattern-2-one-always-on-sandbox-per-user)). * **Use one conversation for each user session.** `POST /prompt` with `new: true` returns a `conversationId`. Store it with the session. Send it back as `conversationId` with each later message. Conversations run in parallel on one sandbox, and each one has its own memory. They stay after a stop and resume. So pattern 3 works without changes: resume the sandbox, then prompt the same conversation. * **Add an agent and model picker.** A selector in your UI maps directly to the `provider` and `model` fields of `POST /prompt`. A switch in the middle of a conversation keeps the history. Users can change their choice for each message. * **Stream to your UI.** `GET /events` with a cursor gives structured events for prompts, responses and tool calls. Each event has its `conversationId`. Filter with `conversation` to show each user only their own session. * **Add a stop button.** `POST /interrupt` with `conversation` stops the turn of one user. The other conversations keep running. * **Add house rules, tools and MCP servers.** The agents read usual config files from the sandbox home: `AGENTS.md`, `CLAUDE.md`, MCP registrations and skills. Put yours in the [template](/snapshots/templates) once, and every fork starts with them. Put per-user rules in the prompt or in per-user sandboxes. See [Customize the harness](/integrated-agents/customize). * **Send attachments.** `boat prompt --attach` puts the user's files under `~/attachments` on the sandbox. It sends images inline to vision models. From a backend, write the file with the [file endpoint](/api/reference/agent/write-sandbox-file), and give its path in the prompt. ## Bring your own harness: the daemon pattern You do not have to use the integrated agents. Your harness can run in your own infrastructure, or you can want full control of the agent loop. Then put a small HTTP daemon in the sandbox and talk to it directly: 1. **Install it.** Copy the binary in with `boat scp`, or put it in your [template](/snapshots/templates). 2. **Keep it alive.** Run it as an [always-on systemd service](/long-running-tasks/always-on-services#run-an-always-on-service). It then survives stop, resume and fork. 3. **Expose it.** `host --private` gives it a stable HTTPS URL that a `_token` protects. Use that token as the credential of the daemon. Store it in your backend. 4. **Drive it** from your backend over plain HTTPS. Your harness sends work. The daemon runs it with full access to the machine and streams the results back. ### Without a daemon You can also work without a daemon: | Task | Endpoint | | - | - | | Run any command in the sandbox | [`POST /sandboxes/{sandboxId}/commands`](/api/reference/agent/execute-sandbox-command) | | Read and write data | File endpoints: [read](/api/reference/agent/read-sandbox-file), [write](/api/reference/agent/write-sandbox-file) | | Lifecycle, prompts, events, desktop, snapshots | Dedicated endpoints | | In-sandbox tools such as `host` | Run their commands through the commands endpoint | A daemon is useful when you need streaming, concurrency, or less latency than one-shot commands give. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.