Configuration
Every agent has a Settings tab, visible to its owner and admins, pinned at the end of the tab strip. A rail on the left lists six panes; the current pane is kept in the URL (?tab=settings§ion=<pane>) and a search box filters panes by keyword (for example timeout or token).
| Pane | Answers | Holds |
|---|---|---|
| General | What this agent is | Display name, ID (Rename…), avatar, tags, runtime, model, funding, execution timeout, parallel capacity, read-only mode, memory and CPU |
| Guardrails | What it may do | Guardrail rules, permissions to change itself, skills that need approval, autonomy, reliability |
| People | Who works with it | Sharing with people and teams — see Users, roles & teams |
| Channels | Where outsiders reach it | Voice replies, public links, Slack/Telegram/WhatsApp channels |
| Integrations | What calls it and what it calls | Expose via MCP, the agent’s access key, Permissions and A2A |
| Storage | What it keeps and shares | Repository and sync, credentials, model sign-in, shared folders, file sharing |
Changes that need a restart — file sharing, shared folders, memory and CPU, guardrail rules, GitHub token, funding — are listed in a single bar at the top of Settings with a Restart now button. Nothing restarts on save.
Settings → General → Model sets the default model for tasks and schedules. Models from providers connected in Settings → Models appear as <connection>/<model>; you can also type a custom model ID. With no override, the instance default applies. Individual chats, schedules and loops can override the model per run.
Execution timeout
Section titled “Execution timeout”How long one run may last: 1–120 minutes (default 60). It applies to chat, tasks, schedules and MCP calls. A schedule or task may set a shorter timeout, never a longer one; you cannot lower the agent timeout below that of an active schedule.
Parallel capacity
Section titled “Parallel capacity”How many tasks the agent may run at once — default 3. Extra work queues and drains as slots free up. Admins set a fleet ceiling (default 10, range 1–32) and owners choose up to it. On ExoHuman Cloud, your plan’s concurrent runs limit applies across the whole instance.
Memory and CPU
Section titled “Memory and CPU”Per-agent container limits: memory 1g–64g, CPU 1–16 cores, or Inherit default. Changes apply on the next restart. Admins set defaults for new agents.
On ExoHuman Cloud, compute is also governed by the agent’s compute profile, which determines the hardware it is scheduled on and the hourly rate; the limits here cannot exceed what the profile provides.
Read-only mode
Section titled “Read-only mode”Stops the agent from modifying source and configuration files (*.py, *.js, *.yaml, *.json, AGENTS.md, .env, …) while still allowing generated output (content/, output/, reports/, exports/, *.log, *.txt). The configuration lives in a root-owned file the agent cannot edit.
Autonomy
Section titled “Autonomy”The master switch for unprompted work. When autonomy is off — the default for a new agent — none of its schedules or reminders fire. Turning it back on restores exactly the schedules that were enabled. Toggle it from the Dashboard or the Autonomy chip in the agent header.
Permissions to change itself
Section titled “Permissions to change itself”An agent’s own key acts for its owner, so platform changes an agent can make are fenced by per-agent permissions that only an instance admin can grant (no agent has any by default):
| Toggle | Permission | Lets the agent |
|---|---|---|
| Change skills | skills.manage | Assign and unassign skills, set skill approval gates |
| Change other agents’ schedules | schedules.manage | Manage schedules of other agents its owner owns |
| Change instructions | instructions.manage | Write AGENTS.md/CLAUDE.md and .claude/ files through the API |
| Manage other agents | agents.manage | Create, deploy and delete agents; change model, resources, timeout, read-only mode and guardrails |
| Start projects | projects.manage | Start a project on its owner’s behalf |
Even with a permission an agent only reaches agents its owner owns, can never lift its own read-only mode or guardrails, and can never change autonomy, capacity or renaming — those stay with a person. Refusals return a 403 naming the missing permission and are audited.
Wake when an ask ends
Section titled “Wake when an ask ends”When an agent asks a person for approval (Inbox & approvals), the answer is read on its next turn. Turn on Wake this agent when an ask it raised ends (Guardrails pane) to start a turn as soon as the ask is answered, cancelled or expires. Each wake-up is a billable run.
Dispatch circuit breaker
Section titled “Dispatch circuit breaker”Optional per-agent protection (off by default). After three consecutive authentication failures — for example an expired API key — new work is rejected immediately instead of queueing runs that will fail. It recovers automatically after a cooldown.
Every setting is available by API: /api/agents/{name}/timeout, /capacity, /resources, /read-only, /autonomy, /guardrails, /runtime, /circuit-breaker. See Agents API.