Skip to content

Tools#

Prism Agent has tools and decides when to use them. You don't call tools directly — you talk to the agent, and it reaches for the right tool to get the job done. This page is a tour of what it can reach for. When the agent uses a tool, you can see it: the web UI and terminal UI both show tool calls, with their inputs and outputs, inline in the agent's messages.

Memory#

Manage long-term memory. See Memory for the full picture.

  • Search — recall past entries by meaning, optionally filtered by category and recency.
  • Write — record something worth keeping, with a category (observation, action, decision, or event) and an importance score.
  • Delete — remove entries that are no longer accurate.

Self-management#

The agent can edit its own identity from inside a conversation — this is how "be more concise" or "remember our staging region" take effect. See Agent identity.

  • Rewrite its Soul, User profile, Memory, Vision, Heartbeat config, or Agent Guide.
  • Rename itself.
  • Adjust settings — heartbeat interval, timezone, and chat delivery mode (verbose=true streams every step, verbose=false delivers only the final message).
  • Clear the bootstrap prompt once first-run onboarding is done.

Scheduling#

Create and manage its own scheduled tasks:

  • Schedule a task using natural language ("every weekday at 9am") or cron.
  • List existing tasks.
  • Delete a task.

Shell#

The agent can act on a real shell — this is what lets it do work rather than only talk about it. By default it works inside a workspace directory: the workspace folder of a native install, /prism/workspace when its commands run in a separate container, or /home/node in the published container image. Relative paths resolve from there.

  • Run a command — execute a shell command and get back stdout, stderr, and the exit code. Commands have a timeout (default about 30 seconds, up to 20 minutes) and output is size-capped so a noisy command can't flood the context.
  • Read, write, and edit files — read a file (line-numbered), write a file, or make an exact-string edit. These tools reject paths outside the workspace.
  • Long-running processes — spawn a background process, write to its stdin, drain its stdout and stderr, and kill it with a signal. Useful for servers, watch processes, and interactive tools.

Where commands run#

On a native install with Docker running, the agent's commands run in a separate container, and so does everything the agent works with: the workspace at /prism/workspace, its skills, its plugins and their data, and each coding agent's login. There is nothing to set up. The runtime finds the engine at startup and pulls the ghcr.io/lensapp/prism-agent-exec image the first time. Set EXECUTION_ENVIRONMENT=local to keep commands on the host, or docker to require the container. The published container image, which Docker and Lens Agents run, keeps commands in its own container.

Docker keeps that storage in volumes that outlive the container, so the workspace survives a restart or an upgrade of the agent. To put a file in or take one out, run docker cp on the host. For example, docker cp ./my-skill prism-agent-exec-<ID>:/prism/skills/ installs a skill, which the agent picks up without a restart. docker ps shows the container's name.

When the place where commands run changes, the next start copies the agent's workspace, skills, plugins, and coding-agent logins across, in either direction. A top-level file or folder that already exists at the destination is left as it is, so newer files inside it, such as a new file in a repository that is already in the workspace, have to be copied by hand. Memory, conversations, and identity stay in the agent's database on the host. If you stop using the engine, set EXECUTION_ENVIRONMENT=local; otherwise each start first waits for the engine that the last run used.

Keep work in /prism/workspace. Docker keeps only the workspace, the skills, the plugins and their data, saved tool outputs, the coding-agent logins, and the home directory /prism/home. A file written anywhere else in the container, such as in /tmp or directly in /prism, is gone after the agent restarts. A conversation you start with prism inside a repository runs its commands on the host, because the repository is there; the startup log says so. If the container is removed while the agent runs, commands fail until you restart the agent.

Warning

In the exec container that a native install starts, a command reaches the agent's own storage and nothing else of yours: not your files, your home directory, or the agent's database. Everywhere else, commands run beside the runtime: on the host, or in the published image's own container, which holds the agent's database at /data/agent.db. There the file read, write, and edit tools reject paths outside the workspace, but shell_exec can run anything the runtime's OS user is permitted to, so the workspace is a default working directory, not a security boundary. For a governed boundary around what the agent can reach over the network, run Prism Agent under Lens Agents.

In the published container image, the shell comes with common tooling preinstalled — git, gh, kubectl, aws, jq, yq, and ripgrep — so the agent can do real operational work out of the box.

Skills#

The agent can load an installed skill — a SKILL.md bundle of task-specific instructions — and follow it. It sees each available skill's name and description up front and loads the full instructions on demand when a task matches; you can also list and run skills with the /skills command. Skills come from a global directory and, in the terminal UI, the current repository's .claude/skills.

Plugin tools#

An installed plugin can bring its own MCP servers, and their tools join the agent's toolset alongside the built-in ones. They are namespaced <pluginId>__<serverName>__<toolName>, so two plugins can expose a tool of the same name without clashing and a plugin can never take over a built-in tool's name. This is how the agent gains an integration — a ticket tracker, an internal API — without waiting for a Prism Agent release: drop the plugin folder in, and its tools are there on the next turn.

Voice meetings#

In the container image, with a Realtime credential set, the agent can join a Google Meet call and take part by voice — see Voice meetings. It listens and speaks in the room, keeping every tool above except file sharing, which a meeting cannot deliver. Speaking is its only channel from a call: there is no tool for posting to Slack, to your chat session, or to the meeting's chat panel. The meeting tools are chat-only — a heartbeat or scheduled run cannot dial into a call.

Claude Code sub-agent#

For larger coding tasks, the agent can hand work to Claude Code running as an autonomous sub-agent in the workspace:

  • Start a Claude Code task with a prompt, in edit or plan mode, with a turn budget.
  • Poll the running task for output and completion.

This lets the agent delegate a self-contained engineering job — "refactor this module," "investigate this failing test" — and check back on the result, rather than doing everything in its own turn-by-turn loop.

Sharing files#

The agent can deliver a file from its workspace to you as a downloadable attachment (up to 10 MB). That's how files it produces — a report, an export, a generated artifact — reach you in the web UI, terminal UI, or Slack. In the TUI, save them to disk with /save.