#Agents

An Agent is an AI actor configured to handle work in Anakin. It can receive assigned Tasks, write comments, update Task state through the available workflow, and produce an execution trace.

An Agent is not the execution host. Its work runs through a selected Runtime on a connected Computer.

#Built-in assistants

Besides Agents you create, Anakin provides built-in assistants. They are not created from Create Agent, and they do not appear in ordinary Agent lists.

• Assistant: one per person per Organization. It appears under My Tasks in the sidebar and is created the first time you open it. It has no settings page. The product owns its name and instructions, and it only supports direct chat. Choose its Runtime from the chat composer. It belongs to no Space and does not appear in assignment pickers.
• Slack task assistant: one per Space. Bind it from the Slack integration page: pick a Runtime, then create and install its Slack app. After binding, you can add extra instructions. It works only in Slack. It cannot be used in in-app chat or @ mentions, and it does not appear in Agent lists or assignment pickers. To connect one of your own Agents to Slack, use an Agent bot instead.

Hover an ordinary Agent avatar and use Open Agent settings on the hover card. Built-in assistants do not have that entry.

#What an Agent contains

An Agent can include:

• a name, description, avatar, and owner;
• operating instructions;
• visibility and Space placement;
• a Computer connection and Runtime provider;
• assigned Skills;
• Agent-specific Git repositories;
• plain and secret environment variables;
• additional Runtime arguments;
• Run settings, including the default working directory;
• maximum concurrency for assigned Tasks and for chats, plus a per-Task timeout and a queue timeout.

The Agent follows the Runtime’s model by default, and the Model row lets you pick another one from the catalogue that Runtime reports; the row is read-only when the Runtime pins the model in its launch arguments. It adds a thinking depth choice when the model publishes one; the default follows that model’s own default depth, and a model that publishes no depth shows no selector. To change models, you can also specify one in Custom arguments on the Agent or Runtime, for example specify model: model-name. OpenClaw does not pick a model with --model. You can also still change the Runtime or Computer tool configuration. When assigning a task you can also pick a model for that run, overriding the Agent's default — see Agent task execution.

#Agent types and Space purpose

When you create an Agent, choose the work type that matches its role:

• Code development: for work that needs a repository, working directory, or development tools;
• Daily work: for research, writing, coordination, and other work that does not need a code environment;
• Design & creative: currently unavailable; its availability follows the product UI.

Code development also has three work modes (names follow the product UI):

• Agent automatically pulls Git repositories: each task uses an isolated Git worktree. This is the best practice for AI coding (badged "Best practice" in the dropdown): the Agent stays decoupled from any single Computer and can switch machines easily, Git worktrees keep parallel tasks isolated, and Anakin caches pulled repositories so re-fetching costs no extra time or tokens;
• Manually specify the code directory: use an existing directory on the Computer;
• No repository needed: for generating throwaway code when no Git repository is needed. Choosing it adds no extra fields.

If you have not provided a code source, the form asks you to add a Git repository, or change the work mode to Manually specify the code directory or No repository needed. If you chose a specified directory but left the path empty, it asks you to enter the directory or change to another work mode. Switching work mode clears the previous error.

When you first create an Agent in a Space, Anakin chooses a default from that Space's purpose: Software development defaults to Code development, while other purposes default to Daily work. After you manually choose a type, future Agent creation forms remember your choice.

Daily work does not continue validating or submitting code-specific repository and path settings. Switch back to Code development and provide a usable code source or working directory when the Agent must work on code. An Agent type does not grant extra permissions; Space, Computer, Runtime, and resource access still apply.

#Find your own Agents in the directory

The Agents page has four views: All, Agents, Crews, and Mine. Mine lists only the Agents and Crews you created, so everyone else's are filtered out.

The list groups rows by Pinned and by Space. Every group can be collapsed and expanded, so you can tuck away the ones you rarely open.

Pin the Agents and Crews you use most: choose Pin to top on a row. Pinned entries collect in a Pinned section at the top of the list, and Unpin puts them back.

You can also favorite an Agent or Crew: use the star on a directory card, on the settings page, or in the chat header. Favorites collect in the Favorites group in the left sidebar for one-click access. Favorites are personal — they do not change what anyone else sees.

Favoriting an Agent or Crew also pins it in the directory. Un-favoriting leaves the pin in place; use Unpin separately if you want it gone.

Views, collapsing, pinning, and favorites are all your own list preferences. They do not change an Agent's visibility or permissions and do not reorder anyone else's list. The Agents list inside a Space offers the same filtering, search, and pinning, and pins are shared between the two: pinning an Agent in one place pins it in both. An Agent that is absent from the directory for everyone is usually archived, in another Space, not shared with you, or Crew-only.

#Create an Agent

Open Agents and select Create Agent. A usable Runtime is required before the Agent can execute work.

The create form recommends a set of names drawn from film, literature, and games. Click a name to fill it in. Opening the form again generates a new set.

Choose a focused responsibility rather than a broad name. A useful description tells People what to assign, while the instructions tell the Agent how to work.

Example description:

Reviews small frontend defects, identifies the responsible component, makes a scoped change, and reports the checks it ran.

Example instructions:

Read the Task description and recent comments before editing. Keep changes limited to the requested behavior. Ask for input only when different interpretations would materially change the result. Run the closest relevant checks and report failures without hiding them.

#Agent variants: reuse one Agent across Spaces

An Agent belongs to exactly one Space at a time. To use the same Agent in multiple Spaces (or on different Computers and Runtimes), you don't need to rebuild it: create an Agent variant — it inherits the original Agent's configuration, can override individual settings, and follows the original Agent live for everything it doesn't override.

#Visibility

Every Agent belongs to one Space and uses one visibility:

• Public: available to everyone in the Space; you cannot add individual members, but you can set permissions per member.
• Private: only invited members can use and chat with it; members are added from the Space's members, and permissions can also be set per member.
• If you are not an invited member, opening a private Agent's conversation is no longer blocked outright: the composer shows Request to join instead. Once the Agent's owner approves the request — they are notified by a banner and a notification, adjustable in Settings → Notifications and on by default — you can chat with the Agent. A declined request can be submitted again.

Whether Public or Private, you can set permissions per member: each member can be a Manager or a User, and the owner always retains full permissions.

Below the visible members sits an Advanced settings section (collapsed by default) with four options:

• who can clone the Agent: Managers / Users (default Users);
• who can create variants of the Agent: Managers / Users (default Users);
• whether others may copy environment variables when cloning (default no);
• whether variants may inherit environment variables (default yes).

Visibility also affects whether a person is allowed to assign the Agent, start Agent Chat, or @ mention it in a Task comment. Before making an Agent Public, check which Computer it is bound to — publishing an Agent that runs on your personal machine shares that machine's credentials with the whole Space. See Using Agents and Computers securely.

#Assign Tasks to an Agent

People, Agents, and Crews can all be task Assignees. When an Agent is selected, it becomes the execution assignee.

Choose an Agent in the Task's Assignee control. If the Task is outside Backlog and outside a terminal status category, Anakin can enqueue the initial run immediately. A Backlog Task waits until it moves to a status that is ready for work.

You can also select Assign task from Agent details. Search existing Tasks in that Agent's Space or create a Task in the same Space. The entry excludes Tasks outside the Space, archived Tasks, and Tasks you cannot access. It is available only for an active, non-Crew-only Agent that can execute work.

Assignment through either entry adds the Agent as the execution assignee without removing existing people Assignees. Selecting Assign task does not guarantee an immediate run: Task status, Computer and Runtime availability, concurrency, and default working-directory capacity still determine whether work starts or waits. When the assigned Agent already has chats on the Task and the assignment would start a run right away, Anakin first asks whether to Run in the existing conversation or Run in a new conversation (or cancel, which drops the assignment); a new conversation becomes the Agent's primary chat on that Task. See Chat with an Agent.

The Agent remains the execution assignee until another Agent or Crew is selected or the Agent becomes unavailable. A later comment starts follow-up work only when it @ mentions that Agent or Crew, or when you continue in the task's chat side panel.

See Agent task execution for the full lifecycle.

#Instructions and context

The instructions editor is WYSIWYG: what you type is what the Agent-side rendering shows, and you do not need to write Markdown syntax.

Agent instructions are included in each run. Use them for stable behavior such as:

• scope and role;
• how to inspect a Task before acting;
• when to ask for human input;
• expected checks;
• reporting format;
• actions that require caution.

Put Task-specific requirements in the Task description or comments instead. Put a reusable procedure that several Agents may share in a Skill.

#Computer and Runtime

The Agent's execution target combines a Computer connection with a Runtime provider detected on that Computer.

If the Computer is offline, new runs normally wait for it to reconnect. If the selected Runtime is no longer available, choose another eligible Runtime before expecting new work to run. The Agent's model and thinking depth come from the Model row in Agent settings.

When you create or rebind an Agent, you can select an offline Runtime on an offline Computer so you can finish setup first. Runtimes that are not detected, failed detection, uninstalled, or out of scope stay unselectable. The local Computer is listed first and labeled (local). The default prefers an online Runtime; if none is online, it falls back to an offline Runtime on this computer. Creating an Agent does not start the Computer. Import and run-now pickers still offer online Runtimes only.

When you pick a Runtime, a Runtime on a Computer may still appear in the list even if that Computer does not allow the Agent's selected Space. The option is listed but disabled, with an explanation that includes the Space name. Offline is a connection state; unavailable to the Space is an access limit. Do not treat them as the same kind of disabled option.

Unavailable Computers or Runtimes in the list include View computer after you hover, so you can open the details. The picker lists Runtimes already available on that Computer; it does not mean those are the only supported Runtimes. Use More supported Runtimes to open Computer details and install other supported Runtimes. View computer opens a listed but unavailable Computer; More supported Runtimes is how you find options that are not connected yet.

A single Computer can serve several Agents. Capacity is bounded by the Computer, Agent concurrency, and task-directory availability.

#Default working directory

Agents support two working-directory modes:

• Create temporary directory: each Task gets an isolated directory. Repository-backed runs can prepare a fresh worktree, which supports safer parallel execution.
• Specified: runs use a configured absolute local directory. This is available only for local Computers and reuses the code and tools already present there.

See Agent working directory for how the two modes differ. Invalid or unavailable paths cannot be used for a run.

When you save a Git folder in Specified mode, the product asks How should tasks use this folder?:

• Run in isolated worktrees: the original folder stays unchanged. Tasks can run in parallel. Task results are delivered on <brand-product-id>-agent/<agent>/<task-identifier>; Agent Chat results are delivered on <brand-product-id>-agent/<agent>/<chat-session-id>. For HiFox, the prefix is hifox-agent; for Anakin, it is anakin-agent. Isolated mode supports one directory; Add path is hidden.
• Run directly in this folder: tasks modify this folder directly. Tasks that target this path run one at a time. You can Add path after choosing this option.

A non-Git folder can only run directly in the folder. Isolated mode is not a multi-directory pool.

Default concurrency:

• Specified directories running in place: default concurrency matches the number of configured directories.
• Create temporary directory, or Specified with isolated worktrees: default concurrency is 50% of the Computer limit.

#Skills and repositories

Attach Skills for reusable operating knowledge. Local Runtime Skills remain available automatically on that Computer; shared Space Skills must be assigned to the Agent.

Attach repositories when this Agent needs a narrower code scope than the Space default. The Git repositories & settings section also offers a Repositories from the Space module: enable every repository configured in Space settings at once, or tick a subset (none enabled by default); with all enabled, repositories added to the Space later are enabled automatically. If no repositories are attached to the Agent, Anakin uses the Git repositories configured for the Task's Space.

The Git repositories & settings section also provides Git settings, which configure the author identity and attribution trailer this Agent commits with:

• Commit author name: defaults to Inherit Space settings; it can also use the Agent user name alone, the Agent owner name (with or without the Agent name), the author from the Computer's git config, or a manual value;
• Commit author email: defaults to Inherit Space settings; it can also use the Agent user email, the Agent owner email, the author from the Computer's git config, or a manual value;
• Three-level inheritance: an Agent inherits the Space settings by default, Space settings inherit the Organization settings by default, and the organization-wide default is configured in the Organization settings under Git repositories & settings. Every level can switch to another source or a concrete value, affecting only that level and the levels inheriting from it. When nothing is configured anywhere, the name falls back to Agent user name & Agent name (the member who triggered the run plus the Agent, for example "Jane & Thor") and the email to the Computer's git config. See Repositories for the Space and Organization levels;
• Co-authored-by trailer: enabled by default to append the platform's Co-authored-by trailer to commit messages; the Organization and Space settings can also set this default (a Space inherits the Organization setting, and an explicit Agent pick wins); when turned off, the trailer is omitted and the managed prepare-commit-msg hook in cached repositories is removed automatically;
• when the work mode is Manually specify the code directory, the git config --local author in the first specified directory wins and the sources above are injected only when it is unset; when no email can be resolved at all, the platform's noreply address is the fallback;
• CLI batch configuration: use anakin agent create or anakin agent edit <agent-id> with --commit-name-mode, --commit-name, --commit-email-mode, --commit-email, and --co-authored-by <enabled|disabled|default> to script or batch-update commit identity settings across Agents;
• Commit signing (Verified signature) and scope: Anakin only injects the commit author (GIT_AUTHOR_NAME / GIT_AUTHOR_EMAIL); it does not host signing keys or override the Computer's committer identity (GIT_COMMITTER_*) or Git signing config. To produce Verified commits on GitHub or GitLab, configure SSH or GPG signing in the Computer's global Git config (~/.gitconfig, for example gpg.format = ssh, user.signingkey, and commit.gpgsign = true, with a verified committer email). Because temporary worktrees, isolated worktrees, and specified directories all inherit ~/.gitconfig (without repo-local [user] overrides in the repository cache), global signing settings apply across all working-directory modes and operate independently of the Co-authored-by trailer toggle.

#Run settings

Open Agent settings and go to Run settings. Use them to control:

• Default working directory: create a temporary directory, or specify existing directories on the Computer. A specified Git folder can run in isolated worktrees or directly in the folder;
• Max concurrency (assigned tasks): how many assigned Tasks the Agent can run at once;
• Max concurrent chats: how many chats the Agent can run at once;
• the maximum duration of a normal run;
• Queue timeout: how long a queued run waits at most. It defaults to 24 hours, can be set between 1 and 168 hours, and does not affect the per-Task run timeout.

Chat concurrency can be separate from assigned-task concurrency:

• Default: counted separately;
• Share assigned-task limit: uses the same limit as assigned tasks;
• Manual input: set a chat limit on its own.

Total concurrency is still limited by the Computer cap. You can open the Computer concurrency setting from here. Exact option names and default limits follow the product UI.

Edit environment variables and custom parameters in a table on Agent settings or Runtime detail. Use Add when none are configured. Each row holds an argument and its value. Pasting several arguments creates separate rows. Quote values that contain spaces. Saved arguments keep the line breaks you entered; they are not rewrapped on spaces. Environment-variable values stay hidden by default. A detected Runtime's executable, default additional arguments, and default environment variables provide startup defaults. A matching Agent-specific additional argument or environment variable overrides the Runtime default.

Connecting Cline does not require a Cline account sign-in: configure the provider once on this Computer with cline auth -p <id> -b <base-url> -m <model>, then set CLINE_PROVIDER and CLINE_API_KEY in the Agent's environment variables, and Cline connects with that key.

Default concurrency:

• Specified directories running in place: default concurrency matches the number of configured directories.
• Create temporary directory, or Specified with isolated worktrees: default concurrency is 50% of the Computer limit.

You can switch to a manual value. If the manual value is higher than the directory count, the product warns that writes may collide across tasks. The warning text follows the product UI.

Higher concurrency consumes more CPU, memory, disk, provider capacity, and repository bandwidth. Increase it only after the current Computer and Runtime handle the existing workload reliably.

#Status and activity

The Agent list and detail view can show availability, workload, recent runs, and archived state. Task runs have their own states, including queued, dispatched, waiting for a local directory, running, completed, failed, and canceled.

Agent availability and Task status are different. An online Agent may still have queued work because concurrency or directory capacity is full.

#Run history and usage

Agent details expand to full screen, and the in-page navigation switches between Settings and Run history. Agent details also offer View run history.

Each run is listed as a row showing:

• the run's status;
• its source: a Task, a chat, an Automation, or a workflow;
• who triggered it — an empty trigger reads as Unknown, and an Automation trigger reads as Automation;
• when it ran, and the tokens that run used.

Opening a row slides a single drawer over the list on the right; going deeper does not stack more drawers. Load more appears at the end of the list.

The Token figure on the overview is the total this Agent has used across its history. It shows — when there is no usage data.

#Archive an Agent

Archiving removes an Agent from assignment and mentions and cancels its running work. Its prior Tasks, comments, and run history remain available.

#Restore an archived Agent

Open Agents, choose More, then open Archived Agents. Choose Restore for the Agent you want to use again.

After it is restored, the Agent returns to the list and can be assigned or mentioned again when its Space access and Runtime requirements are met.

Before archiving, check whether Automations or Crews still depend on the Agent.

#How do I set an Agent's model and thinking depth?

Anakin cannot always tell which model a Runtime is actually using, so an Agent follows the Runtime’s model unless you pick another one on the Model row. That row exposes a thinking depth choice for supported Runtimes, and the level you pick is applied when a session starts and again when you continue it:

• if the Runtime does not accept the chosen depth, the run fails with a clear error instead of showing one value on screen and running at the default;
• when you set a thinking depth through Custom arguments and the Runtime cannot apply it before the first prompt, the run is stopped with a clear error;
• a model that publishes no depth shows no selector and runs at the Runtime's own default.

To change models, specify one in Custom arguments on the Agent or Runtime, for example specify model: model-name. OpenClaw does not pick a model with --model. You can also still update the Runtime or Computer tool configuration.