Skip to main content
In the current UI, Agents are labeled Assistants. This page uses “Agent” for the concept and “Assistant” where it matches current UI labels.

​
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

1

Create the Assistant

Go to Assistants and click Create new.In setup, define:
  • Name
  • Description (optional)
  • Main prompt (required)
  • Privacy: Private or Public (workspace-visible)
  • Built-in tools (for example, Web Fetch)
2

Attach connectors and tools

Add one or more connectors (MCP servers), then select which tools are enabled. This is the core capability boundary for the agent.
3

Configure model + behavior

Open the agent detail page and set:
  • Model (from your workspace-configured model list)
  • Instructions (prompt)
  • Skills
  • Optional env vars (if enabled in your workspace)
4

Choose deployment mode

Use one or more:
  • Playground for interactive chat and testing
  • Schedules for recurring runs
  • Webhooks for event-driven runs
  • Slack integration (if configured)
5

Validate in Activity

Check run history for status, token/cost usage, and execution trace. Tighten prompt/tool scope before broad rollout.

​
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

  • Agent owners can edit core settings
  • 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.”
Mutating Runlayer MCP actions are confirm-gated (for example confirm=true) and permission-gated (admin/owner where required).

​
Agents vs Agent Accounts

  • Agents (Assistants): 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.

Runlayer MCP

Built-in MCP for analytics, audit logs, inventory, governance

Agent Accounts

Programmatic auth + delegated access model

Policies

Control what agents and users can do

MCP Troubleshooting

Debug connector, auth, and permission failures