Agents

​

Why Agents

Runlayer lets you build multiple Agents, each for a different job. Instead of one general assistant with broad access, you create focused agents for specific workflows, teams, or risk levels. Each Agent combines:

• Instructions (main prompt + optional skills)
• A chosen model
• A curated set of MCP connectors and tools
• Optional deployment channels (Slack, schedules, webhooks)

This gives you reusable, policy-governed automation you can scale across use cases.

​

Agents for any purpose

You can create agents for almost any internal workflow, for example:

• Support agent: summarize tickets, query product docs, draft replies
• Incident agent: triage alerts, pull logs, post status updates
• RevOps agent: collect CRM context, prep account briefs
• Security agent: review policy denials, summarize risk events
• Platform ops agent: monitor MCP health and failed tool calls
• Leadership reporting agent: weekly usage + adoption summaries

Pattern: one purpose per agent, minimal tool scope, clear prompt contract.

​

Set up an agent

​

Cloning an agent

Any workspace member can clone an agent from the agent detail page (overflow menu → Clone) or from the agent card on the list page. Cloning copies the agent’s configuration, attached connectors, and tools into a new agent owned by you. Only the agent owner can delete an agent; cloning is available to everyone.

​

Browsing and filtering agents

The Agents list page supports:

• Sorting by newest, oldest, alphabetical, or last used
• Status filter to show only active or disabled agents
• Search by agent name
• Schedule badge on agent cards showing the number of active schedules
• Connector icons on agent cards showing attached connectors

Use these controls to quickly find agents in workspaces with many agents.

---

​

Runtime capabilities

The main prompt you write is combined with Runlayer’s runtime instructions. The runtime prompt tells the agent what tools exist, how to use connected MCP servers, where it can write files, and which environment limits apply. Agents can use:

• Connected MCP server tools and resources selected on the agent
• Built-in local tools for shell commands, file reads, file writes, and edits
• Web fetch when enabled
• Artifact publishing (shareable file URLs)
• Skills attached to the agent
• A persistent SQLite memory database, when memory is enabled
• A persistent workspace filesystem, scoped to that agent
• Subagents, when configured
• Slack message delivery tools, when Slack is connected

​

Filesystem workspace

Agents run in a sandbox with a writable workspace at /tmp/workspace. Files the agent writes there are restored on future runs for the same agent, so recurring agents can keep generated reports, scripts, checkpoints, small datasets, and other working artifacts. Filesystem persistence is scoped by agent ID. Other agents do not share those files, and the workspace should not replace your source-of-truth systems. Use it for working state and generated artifacts, then re-check external systems when current data matters.

​

Artifact publishing

Agents can publish files from their workspace as shareable URLs using the built-in publish_artifact tool. Published artifacts are accessible to anyone with the link and persist beyond the run. Use cases:

• Share generated reports (PDFs, CSVs, HTML)
• Distribute compiled outputs or datasets
• Provide downloadable files to end users in Slack or other channels

The tool accepts a file path under /tmp/workspace, an optional title, optional MIME type override, and a disposition (inline for browser-viewable files or attachment for downloads). The response includes a stable URL you can share. Artifact publishing is enabled by default on new agents. Toggle it from the agent’s advanced settings if you want to disable it.

​

Shell and code execution

Agents can run normal shell commands in the sandbox. This lets them inspect files, transform data, install or use available packages, compile code, run test suites, generate artifacts, and call command-line tools. Common runtime tools include Bash, Git, Node.js, npm, pnpm, TypeScript, Python 3, uv, ruff, ripgrep, jq, yq, SQLite, PostgreSQL client tools, curl, wget, zip, and unzip.

​

Runtime limits

• Agent runs are short-lived; long-running services and background daemons are not a good fit.
• Production sandbox runs have a 15-minute runtime limit.
• Interactive terminal programs that require a TTY are not supported.
• Writes outside /tmp/workspace should be treated as temporary.
• Hidden directories, dependency folders, and common build output directories are not intended for persistent file sync.
• Local tools and MCP calls still pass through Runlayer policy, scanning, and audit flows.
• Network access depends on the runtime environment and the configured connectors, credentials, and policies.

​

Run limits

Agents have daily and weekly run limits to prevent runaway usage. Defaults are set at the workspace level in Settings → General and apply to all agents. To override limits for a specific model within an agent, open the agent’s detail page and configure per-model run limits. Each override sets a separate daily and weekly cap for that model (the weekly cap must be greater than or equal to the daily cap). When an agent reaches its limit, new runs are rejected until the window resets.

​

Budget alerts

When Slack is connected, the agent owner receives a DM when an agent crosses 75%, 90%, or 100% of its daily or weekly run limit. Budget alerts are enabled by default and can be toggled per-agent in the agent detail page under Budget alerts.

​

LLM providers

Agents need at least one LLM provider configured to run. Admins manage providers in Settings → General. When multiple providers are configured, the model picker in the agent detail page shows all available models. Each agent can use a different model.

​

Agent memory

Agent memory is an optional built-in persistent SQLite database an agent can use to save structured notes and state between runs. Enable it from the agent’s advanced settings when the agent should remember information across runs. Use agent memory for things like:

• Durable preferences or instructions specific to that agent
• IDs, checkpoints, or summaries from earlier runs
• Lightweight working state for recurring tasks

The agent can write new rows, update earlier records, and query what it saved in prior runs.

​

Example prompts

• “Remember that Acme prefers weekly status updates every Monday.” The agent can save that preference in its memory and use it in later runs for Acme-related work.
• “Store the last processed Zendesk ticket ID as 18423 and pick up from there next run.” The agent can write that checkpoint, then retrieve it later to avoid starting from scratch.
• “What do you already remember about our Q2 board report workflow?” The agent can query its stored notes, summarize what it finds, and use that as context for the current task.

Agent memory is scoped to a single agent. Other agents do not share it, and it should not replace your source-of-truth systems. Use it to help an agent stay consistent over time, then re-check live systems when current data matters.

​

Subagents

An agent can delegate work to subagents — lightweight child agents that run inside the parent agent’s sandbox with their own name, description, prompt, and optional model override. Subagents inherit the parent’s connectors and tools but follow their own instructions, so you can split a complex workflow into focused sub-tasks without creating separate top-level agents. To add subagents, open the agent detail page and look for the Subagents section. Click Add subagent, then fill in: Each agent supports up to 20 subagents. You can edit or remove subagents from the same section. Subagents can also be managed programmatically through Runlayer MCP tools (add_agent_subagent, update_agent_subagent, delete_agent_subagent).

​

Agent policies

Each agent has a dedicated Policies section on its detail page where you can define access rules scoped to that agent’s connectors and tools. Agent policies work like server-level policies but are managed directly from the agent rather than from each connector individually. To add a policy, open the agent detail page, scroll to the Policies section, and click Add policy. Each policy includes: Agent policies are visible only to the agent owner. Use them to restrict what a specific agent can do beyond the connector-level permissions — for example, allowing an agent to read but not write, or limiting queries to specific tables.

​

Multi-agent strategy

Use multiple agents instead of one overloaded agent:

• Split by business function (Support, Security, Ops, GTM)
• Split by data sensitivity (low-risk vs privileged systems)
• Split by trigger type (human chat vs scheduled vs webhook)
• Keep prompts short and role-specific
• Keep connector/tool permissions narrow per agent

​

Ownership and access

• The agent owner is shown on the agent detail page (below the webhook section)
• Agent owners and admins with the Manage Agents capability can edit core settings (including the enable/disable toggle); advanced settings (model, environment variables, subagents) are visible only to admins and the agent owner
• When you create or update an agent, you automatically receive access to the connectors attached to it
• Public agents are accessible to workspace users
• Non-owners may have read/run access but not edit rights
• All calls still pass through your Runlayer policy model and scanner stack

​

Use Runlayer MCP inside agents

Runlayer MCP is a first-party connector that lets an agent reason about your Runlayer workspace itself (analytics, audit logs, inventory, governance). To use it in an agent:

1. Install/enable the Runlayer server in your workspace.
2. Add that connector to the agent.
3. Test with focused prompts (examples below).

Example prompts:

• “Use Runlayer MCP to export top tools used in the last 30 days and summarize top failure causes.”
• “List recent policy denied events and group by connector.”
• “Show all connectors with low usage but high error rate.”
• “List pending access requests and summarize by team.”

​

Agents vs Agent Accounts

• Agents: UI-managed AI workers with prompt + tool curation
• Agent Accounts: OAuth client identities for programmatic/API access

If you are building machine-to-machine automation, see Agent Accounts.

​

Related docs