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

​

Duplicating an agent

Any workspace member can duplicate an agent from the agent detail page (overflow menu → Duplicate) or from the agent card on the list page. Duplicating clones the agent’s configuration, attached connectors, and tools into a new agent owned by you. Only the agent owner can delete an agent; duplication 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.

---

​

Run limits

Agents have daily and weekly run limits to prevent runaway usage. Defaults are set at the workspace level in Settings → Workspace 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 → Workspace. 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

Each agent includes a built-in persistent SQLite database it can use to save structured notes and state between runs. You do not need to attach extra storage for this — it is available automatically. 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 Agents section. Click Add agent, 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