Self-host Agenta

AGENTS.md

Workflow (follow in order)

1. Understand, then propose a plan before doing anything. In a few sentences, state your understanding of what they want and how you would set it up (local machine or remote server), and name the decisions you need from them. Do not run commands yet.
2. Surface the decisions, then ask. Each decision below gets one line of context and a sensible default. If your harness has a question/choice UI (an AskUserQuestion-style tool), use it so the user just picks. For a decision with a default, phrase it as "I'll default to X unless you want to change it." Do not dump every option as prose. Detail and per-decision doc links: resources/decisions.md.
3. Get approval on the plan, then execute. Follow the OSS docs for the actual commands (the routing table below). Work from a checked-out clone of https://github.com/Agenta-AI/agenta;

   run.sh

   resolves paths relative to its root.
4. Test in levels, and let the user pick the depth. Always run the quick sanity check (API health, runner reachable, sign-up reaches the studio). Then ask whether they want to go further: a quick functional check (run one prompt, a few minutes) or a full end-to-end check (tool call, durable mounts, and where the run executed, about 15 to 20 minutes). Do not run the deeper levels without asking. Troubleshoot and retry on any failure. Steps: resources/test.md.
5. Point out folder mounts (local sandbox only). Once setup is done, and only if they chose the local sandbox, tell them in one sentence that they can give an agent access to a host folder by mounting it, and link customize the agent runtime. Skip this for Daytona.
6. Offer feedback. At the end, or when something breaks, ask the user: "May I send anonymous setup feedback to help the Agenta team improve this?" Send only if they agree, and never send secrets. Thank them either way — the team is grateful. How: resources/send-feedback.md.

The decisions (OSS)

• Where — local machine (default), or a remote server.
• Model auth — a managed provider API key (works anywhere, the default), or your own Claude/Codex subscription (local only).
• Sandbox (where agent code runs) — local (fast, shares the runner container, single trusted user; default for a first local setup), or Daytona (isolated per run, needs a Daytona API key).
• App tools and triggers (optional) — to connect third-party apps as tools, or use event triggers (a third-party app firing your agent), the deployment needs Composio, which needs a free Composio account and

  COMPOSIO_API_KEY

  . Ask whether they want to set this up now or skip it; the default is skip. Built-in tools, MCP servers, and schedule (time-based) triggers work without it. This is separate from schedule triggers.
• Exposure — only if remote: plain

  IP:port

  , or a domain with TLS.

Routing table: "I want to X" -> OSS doc

Resources

• resources/decisions.md — the questionnaire in depth: each decision, its context, default, what it changes, and the doc page with the how-to.
• resources/test.md — tiered tests: the always-run sanity check, then the optional functional and full end-to-end levels.
• resources/troubleshoot.md — field-verified failures keyed to the exact error text.
• resources/harden.md — OSS remote hardening, for a public host.
• resources/send-feedback.md — how to send the optional, user-approved setup feedback. Public topic; never include secrets.

Ground rules

• The docs are the source of truth. If a resource file and a doc disagree, the doc wins.
• Verify every command before handing it to the user; these run against a real deployment.
• Never print or send secrets (API keys, tokens, passwords, DB creds).