Atomic Agent: Advanced features

This page covers five power features that go past the everyday setup: add-on tools, skills, the settings file, several agents at once, and tuning a local model. It is the seventh of the eight Atomic Agent pages, so come here only after Fixes and your first jobs feel routine.

Each feature below says what it is for, how the official docs turn it on, and what you trade for it. The commands match v0.7.0 and the desktop app 0.0.8, checked on 14 November 2026, and the docs warn that names and settings still move between releases.

Add-on tools through MCP servers

MCP is a common way for programs to hand tools to an agent. Point Atomic Agent at an MCP server, such as one for GitHub or a database, and that server's tools show up next to the built-in ones, named like mcp.github.search_issues. The shared Skills and MCP page compares skills and MCP across every agent in this guide and explains how to choose safe ones.

How to turn it on. In the desktop app, open Settings › Connections › MCP servers, where the desktop 0.0.5 notes say you can paste a server's command line, its web address, or its JSON. In the terminal version, type /mcp and press n to add one, or add an entry to the mcp.servers list in config.json and restart.

By default, every MCP tool asks for approval before it runs, and it keeps asking at every level below 5. A server you mark pure_read, and any single tool that the server labels as read-only, skips the prompt. The MCP page also says that once you connect any server, servers can ask your local model to write text with no approval prompt at all.

The docs disagree on what a server started from a command can see. The MCP page says it inherits every setting the agent holds, including keys, while the v0.6.11 release notes say it now gets only basic system settings plus its own.

• You gain: new abilities without waiting for the project, such as reading issues or a database you use every day.
• You risk: a server is someone else's program running as you, and it may see your keys. A server you mark pure_read skips approval, so its answers reach the model unchecked, and that is a route for prompt injection.
• Makes sense when: the server comes from a maker you trust, you have read what it does, and you leave its trust setting on the default so each call still asks.

Skills

A skill is a saved playbook: a folder with a SKILL.md instruction file and, sometimes, small scripts. The agent sees a one-line summary of each skill and loads the full playbook only when your request matches it. The README says 18 starter skills come built in, or 15 outside macOS.

How to turn it on. List what you have with atomic-agent skill list, and read one before you trust it with atomic-agent skill show followed by its name. Install a skill folder you made with atomic-agent skill install ./my-skill, or one from the ClawHub catalog with atomic-agent skill install @owner/slug. Hide one without deleting it with atomic-agent skill disable followed by its name.

Every download from a catalog passes a security scan, and a skill flagged as dangerous is blocked unless you add --acknowledge-risk. A skill's script asks for approval at levels 1 to 3 and runs without asking at levels 4 and 5. If you would rather not use the catalog at all, run atomic-agent config set skills.clawhub.enabled false.

• You gain: the agent follows the same steps every time for a job you repeat, and other people's skills save you writing your own.
• You risk: the skills page says scripts run with the agent's full permissions and are not sandboxed. It also says the scan "cannot catch a script that is merely well-written and hostile," so a clean scan proves little.
• Makes sense when: you have read the skill's SKILL.md and its scripts yourself, it comes from an author you trust, and you never use --acknowledge-risk to get past a warning you do not understand.

The settings file and saved rules

Everything you can set lives in config.json inside the .atomic-agent folder, and saved approval rules live next to it in approval-rules.json. A few settings make the agent safer, and a few make it far riskier.

How to turn it on. Read the whole file with atomic-agent config get, and change one setting with atomic-agent config set followed by the setting's name and its new value. Some useful ones:

• http.approvalMode set to always makes every raw web request ask first, which settles the disagreement in the docs in your favor.
• In the terminal version, /mode plan makes the agent read and propose only, and the docs say every tool that would change something is refused for that session.
• agent.smartApproval set to true turns on an optional risk check, where a small model rates each action and lets the low-risk ones through without asking. It never covers dangerous commands, secrets, or email. If it gives no answer within 8 seconds, you are asked as usual.
• agent.approvalLevel raises the level. The approvals page uses atomic-agent config set agent.approvalLevel 3 as its example, which stops asking about file writes in your home folder and about Trash moves.

Saved rules can also make the agent stricter. The approvals page says a deny rule wins over an allow rule, and a project's own rules file can only add ask and deny rules, never allow ones.

Never use atomic-agent config set with a whole block of JSON, because the CLI reference warns that it replaces the entire file and resets every setting you leave out, including your providers and a usage-report opt-out.

• You gain: control the desktop app does not show, from stricter web requests to a read-only mode for planning.
• You risk: one wrong value, such as level 5, turns off every approval on your real computer. A risk check on a cloud model also sends each checked action to that company as a paid call.
• Makes sense when: you change one setting at a time and check it afterward with atomic-agent config get. The safer settings, http.approvalMode set to always and /mode plan, suit a beginner, while a higher agent.approvalLevel does not.

Several agents at once with Fusion

Fusion splits one job between two models. An orchestrator plans the work and checks the results, while workers do the parts, up to four at the same time on a cloud model but one at a time on a local model unless you raise workers. Either side can be a local model or a cloud model.

How to turn it on. You need two providers, usually one cloud provider with a key and one local model that is already downloaded. In the desktop app, pick Fusion in the composer. In the terminal version, type /runmode fusion, then /runmode status to see which models it picked, and /runmode local to leave.

Approving one fan-out lets the workers write files and run commands in the folders you approved, without asking again for each step. The approvals page says that approval never covers dangerous commands or the agent's secret files.

• You gain: big jobs that split into many small parts can finish faster with cloud workers, and pairing a cloud planner with local workers keeps most of the work on your computer.
• You risk: one yes covers many actions you will not see one by one, and anything sent to a cloud seat leaves your computer and may cost money. The docs also say worker spend is not counted against an overnight run's budget.
• Makes sense when: the job works only inside a folder made for it that holds copies, and you have a spend limit set at the cloud provider. It is not a first-month feature.

Tuning a local model

If you stay with a local model, a few commands help it fit your computer. They work in the terminal version, and the desktop app uses the same recommendations.

How to turn it on. Run atomic-agent models recommend, which reads your RAM, graphics memory, and free disk space and suggests a fast, a balanced, and a quality pick. Then atomic-agent models upgrade downloads the quality pick in the background without switching, and atomic-agent models use followed by the model's name switches once it has landed. If the wrong graphics chip was picked, list them with atomic-agent models devices and choose with atomic-agent models use-device auto, or cpu to skip the graphics chip.

The desktop 0.0.2 notes also add an embedding model under Settings › Models › Embedding models, which lets memory find notes by meaning rather than by matching words. The notes say this works only while a local chat model is active.

• You gain: a bigger model that still fits makes fewer mistakes on long jobs, and everything stays on your computer at no cost per use.
• You risk: a model that barely fits can slow the whole computer or fail to load. Even the best model for an 8 GB or 16 GB laptop stays weak at jobs with many steps.
• Makes sense when: your prompts must stay private, the jobs are short, and you have checked the shared local models page for what your RAM can carry.

Shared advanced topics

These shared pages cover ideas that apply to every agent in this guide. This guide could not find official steps for running Atomic Agent inside a container or virtual machine. The approvals page only says levels 4 and 5 belong "ideally in a sandbox," with no steps.

• Local models: Atomic Agent's default is a local model, so this explains what your RAM can run.
• Mixing models: Fusion and the fallback chain both mix a local model with a cloud one.
• Host access and unattended runs: Atomic Agent always runs on the host, so this covers what an overnight run or a higher approval level puts at risk.
• An always-on machine: schedules run only while Atomic Agent is running, so the computer has to stay on.
• Subscription sign-ins: Atomic Agent can run on a Claude or ChatGPT plan through Claude Code or Codex.
• Relays: Atomic Agent accepts any OpenAI-compatible web address, so a relay plugs in the same way a provider does.

Sources

Checked 14 November 2026.

• Atomic Agent research notes.
• Atomic Agent README (starter skills, providers).
• MCP client (desktop Settings › Connections › MCP servers, /mcp, mcp.servers, approval by default, pure_read, read-only tools, sampling without approval, environment inheritance).
• Release v0.6.11 (servers started from a command get only basic settings).
• Desktop v0.0.5 release notes (MCP smart add).
• Skills (SKILL.md, skill commands, ClawHub, security scan, --acknowledge-risk, scripts ask at levels 1 to 3, not sandboxed).
• Approval gates (levels, /mode plan, risk check, saved rules, Fusion fan-outs, "ideally in a sandbox").
• Configuration (http.approvalMode, config set).
• CLI reference (config get, whole-file config set warning).
• Fusion run mode (two providers, desktop composer, /runmode commands, up to 4 cloud workers at once and local workers one at a time unless you set workers).
• Overnight runs (Fusion workers are not counted in spend).
• Models and cloud providers (models recommend, models upgrade, models use, devices, OpenAI-compatible endpoints, fallback chain).
• Desktop v0.0.2 release notes (embedding models in Settings › Models, finding notes by meaning only while a local chat model is active).

Next

Next: Persona and rules.