Desktop app

Home: the chat surface

Full guide: Chat and runs

The app opens to a centered product mark above "What should we build in your workspace?", with the composer beneath it and a few suggested prompts. Type a goal and press Enter; that starts a run.

While the agent works, progress reads as quiet lines: "Ran command or tool" one per line, then everything collapses into a one-line summary above the answer: "Worked for 15s", expandable to the full timeline of that turn. Consecutive tool calls fold into "Used N tools" with the dominant tool named; one click expands the compact list with inputs, durations, and status.

A turn that changed files appends a summary block: a header row with the file count and added and removed line totals, an Undo affordance, then one row per file expandable to its diff.

The composer

• Permission pill. A compact selector inside the field switches the run between auto, manual, and plan. See Safety and permissions for what each means.
• Reasoning pill. Sets the run's reasoning depth, from low to max. Higher levels buy more planning steps and retries within bounded budgets; only max enables the extra evaluator and final-review passes.
• / opens the skill palette. Rows of name, one-line description, and scope, keyboard navigable, filter as you type. /<skill-name> runs an enabled skill as its own recorded run.
• @ references connectors and files. The same anchored palette, for attaching context.
• /goal sets a session goal. See Goals below.
• Below the field, compact selector pills choose the workspace, branch, and where the run executes.

Approvals

Full guide: Approvals

When a run hits an action that needs your decision, it parks and the request appears in the Approvals surface: what the agent wants to do, the tool, the risk level, and the input summary. Approve and the action proceeds; deny and it never executes. Every decision is recorded in the run's event log. Forgotten prompts can expire, which fails closed.

Hive: the live swarm view

Full guide: Swarm mode

During a run, toggle Hive from the chat header for the full-canvas graph. Nodes are compact chips showing each agent's status, role, name, and current tool; edges animate only while data flows. Selecting a node opens its notebook with findings, claims, evidence, budget usage, and recent events. A top strip tracks run stats: agents active and done, tool calls, elapsed time, and the current stage.

The graph renders the planner's actual structure. Plans are staged: plan, execute, verify, synthesize, and final review, with parallel work bounded by the run's concurrency limit. The planner uses the smallest team that fits the goal; the 300-agent cap exists for explicitly large jobs, not as a default.

Goals

Full guide: Goals

A goal is a completion condition that outlives a single run: "the report exists and cites three sources". Type /goal <condition> and the agent keeps starting turns until a separate evaluator, a fresh no-tools completion, judges the condition met from the conversation alone. The worker's own claim never decides. Each "not met" reason feeds the next turn as guidance.

While a goal is active, a slim bar docks above the composer showing the condition, elapsed time, and pause, edit, clear, and expand controls. Pause stops after the current turn; resume continues with counters reset; one goal per session, and a new one replaces the old. Goal turns obey the run's permission mode, so approvals still gate every risky action.

Skills

Full guide: Skills

Skills are saved, parameterized runs. The Skills view lists them grouped as Personal and From plugins; the detail pane shows the name, who added it, the trigger ("Slash command + auto"), the description, the skill body, and an enable toggle.

Enabled skills are available two ways: you invoke them with /<skill-name>, or runs invoke them through the policy-gated skill.invoke tool, with the same approvals and the same event log. A skill's declared permissions are validated against the tools it uses, so a skill is never silently more privileged than its steps require.

Dreams: reviewed memory

Full guide: Dreams (memory)

After a run finishes, Anymo may propose memories. The Dreams view lists proposals and approved items; you approve or reject each one. Approved memories flow into future runs; rejected ones are dropped; nothing is remembered without your review. The full pipeline, including namespaces and the knowledge graph behind it, is covered in Self-learning.

The learning loop after every run

When a run completes with proposals, the thread appends one quiet panel: From this run, with a row per proposed memory and skill, a content preview, and Approve and Reject controls, plus the verifier outcome when present. After you act, a one-line receipt confirms it ("Memory saved · view in Memory"). Decisions are reversible from the Memory and Skills views.

Automations

Full guide: Automations

The Automations view lists scheduled runs as rows: name, schedule chip, last run, and an enabled toggle. "Create automation" opens a modal with a name, projects, a prompt (skill chips render inline), and a Daily or Interval schedule. Automations run while a host is alive (the desktop app or an app-server); missed schedules are skipped rather than replayed, and repeatedly unsuccessful automations auto-archive. Scheduled runs use a deliberately narrower permission posture, and sensitive actions still go through approvals.

Plugins and connectors

Full guide: Plugins and connectors

The Plugins view manages both plugin bundles and MCP connectors. A plugin's detail shows its source, version, author, skills as chips, and "Try asking" example prompts. A connector's detail shows the provider mark, connection state, and one Connect or Disconnect button; sign-in opens your system browser and resolves when the callback lands. Details in MCP and plugins.

Local actions and open in editor

Related: Worktrees and isolation

A split button in the chat header runs the workspace's default action; its menu lists the actions you define per workspace (Run, Build, and so on) plus "Add action". Actions are your own commands, persisted per workspace, and they execute through the guarded process path with an interactive approval, like any tool.

File and folder references get an Open affordance listing only applications actually detected on your machine: editors, the file manager, terminals. A Settings row sets the default.

Runs and search

Past runs are rows with the goal, status, relative time, and duration. Selecting one replays it read-only in the chat surface with a "Viewing history" banner and a learning summary of what was proposed and approved from that run. Replay is exact: the UI is a projection of the run's event log, so what you saw is what replays.

Settings

• Providers. Saved provider profiles as rows with a health dot and a check button. Keys are sealed at rest in the OS keychain. See Model providers.
• Permissions. The three modes as a radio group with descriptions. There is no bypass option, by design.
• Appearance. Light, Dark, or System; per-mode theme editors with presets, accent, background, and foreground colors, UI and code fonts, a translucency toggle, and a contrast slider. Your themes persist locally.
• Plugins, Hooks, Advanced. Plugin trust, hook configuration, and diagnostics.