• Mounting a volume
• Commands
• The Setup terminal
• Importing a ZIP archive
• Bundled volumes
  • The volumes Cerb ships
  • cerb-agents
  • cerb-docs
• Records API
• Search Query Fields

An agent filesystem is a named volume of agent files that AI agents and workers can both read and write. Each volume caches its file count and total size.

A volume's name must start with a letter, followed by letters, digits, or dashes.

Mounting a volume

There are two ways a volume reaches an agent, and most installations only ever need the first.

On the agent record. An AI worker's AI tab has a filesystems field, so giving an agent a volume is a picker rather than a script. Volumes chosen under Everywhere come with the agent wherever it runs, and a surface adds to that rather than replacing it – an agent's filesystems are the union of the two. Nothing else is required: an agent that names no chat of its own runs the one Cerb ships, so a new volume, a new AI worker, and one surface turned on is enough to ask it a question.

In an automation. For a script that composes its own agent turn, an automation makes volumes available by listing them under mounts: on llm.agent::

llm.agent:
  inputs:
    agent: @researcher
    mounts:
      handbook:
        mode: read-only
      scratch:
        mode: read-write
        create@bool: yes

Writing mounts: at all is what enables the agent_terminal tool. Because one tool covers every mounted volume, adding or removing a mount doesn't change the tool's schema – which means it doesn't invalidate the provider's cached prompt prefix.

An empty mounts: block is a valid configuration: it mounts no volumes, but the agent still gets a /tmp scratch area.

The same volume can be mounted twice using a <name>@<suffix> key.

However a session's mounts: resolved on the day it ran, its transcript records the result. A Filesystem Mounts panel sits directly below Tools, naming each mountpoint, the volume behind it, that volume's file count and size, and the mode the agent had. /tmp appears alongside them as per-run scratch, without a linked record or a file count:

This is worth knowing about because a mount that can't resolve – a volume since deleted or disabled – is skipped silently at run time rather than failing the turn. One unresolvable entry never costs the agent the volumes that do resolve, so a session can have had fewer volumes than its automation asked for, and the transcript is the only place that says so.

Commands

Agents and workers use the same command set. The tool description is generated from the same source as the terminal's help output, so what an agent is told and what a worker sees can't drift apart.

Command output can be piped through a Twig filter chain in place of Unix pipes. Output too large to return inline is spooled to /tmp and referenced by path.

The Setup terminal

Workers browse and edit volumes from Setup » Developers » Agent Filesystem Terminal, which is restricted to administrators.

Importing a ZIP archive

A ZIP archive can be uploaded to a volume and imported in the background as a queue job. Progress appears on the filesystem record, and the 'Agent Filesystem' card widget shows the volume's file count, total size, and a history of past imports.

Bundled volumes

Some volumes ship with Cerb and import themselves on /update, so an agent has reference material without anyone uploading an archive. They stay current for whatever version you're running, with no maintenance.

Each bundled volume carries a manifest, and only its hash is read at runtime: an update where nothing changed does no work at all, while a changed volume runs through the same import job an admin upload uses. That job is drained inline, so when /update finishes, the content is there.

Setup » Developers » Platform has a Reload button that reconciles every bundled volume against its rows without waiting for a version change.

The volumes Cerb ships

Cerb ships two bundled volumes of its own:

cerb-agents

Each skill is one file an agent reads when it needs it, covering a domain a capable model is most often subtly wrong about – the agent terminal, KATA, automations, scripting, search queries, records, data queries, icons, mail replies, and the documentation itself.

Skills compose, which is the point. An agent asked for a chart of open tickets by group reads automations for the command shape, data-queries for the source and its aggregation, scripting for the Twig in between, and search-queries for the filter grammar – four short reads on the turn that needs them, rather than one prompt large enough to hold all four being re-sent on every turn of every conversation.

Nothing is loaded up front. An INDEX.md says what each skill covers and when to reach for it, and the agent reads from there.

The same volume serves every agent, so a skill improved once is improved for all of them. A new agent chat mounts it by default.

cerb-docs

The cerb-docs volume carries the complete Cerb documentation as Markdown – the reference manual, guides, worked solutions, tips, workflows, and release notes. Mount it and an agent can look a feature up rather than recall it, which matters most exactly where a capable model is subtly wrong: search query syntax, KATA keys, API endpoints, and automation commands.

It's over a thousand files, so it's a volume to search rather than browse. An INDEX.md at the volume root says what lives in each directory, which paths are predictable enough to read directly, and what each page's front matter carries – enough to orient an agent that mounts the documentation and nothing else. The docs skill in cerb-agents covers the same ground in more depth for an agent that has both.

Records API

These fields are available in the Records API and packages:

Search Query Fields

These filters are available in agent filesystem search queries: