Agents

​

Why Agents

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

​

Agents for any purpose

• 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
• Code review agent: receive GitHub pull request webhooks, use GitHub MCP tools to fetch the diff, and draft review feedback

​

Set up an agent

​

Allowing an agent to invoke other agents

• Target in Allowed agents: the handoff runs without asking.
• Target not in Allowed agents, you’re in the conversation: you get an approval showing the target, the exact task, and what the agent shares. Choose Approve once to run this handoff only, Approve always to add the target to Allowed agents for this calling agent, or Deny. The same choices appear on the approval card in chats, Slack, and Microsoft Teams; the Inbox offers Approve and Deny only.
• Target not in Allowed agents, nobody is present (schedules, webhooks, event triggers, channel monitors): the handoff is refused. Add the target to Allowed agents first.

​

Cloning an agent

​

Version history

​

Browsing and filtering agents

• Sorting by newest, oldest, most runs, most used (unique users), last used, or alphabetical
• Ownership tabs — All agents, Created by me, or Shared with me
• Inventory tab — every agent you can edit (the whole workspace for agent admins) with its owner, model, runs over the last 8 weeks, and upkeep issues: a model upgrade available, idle (no run in 30+ days), never run, or owner left. Select agents to upgrade their model, move them all to a model you pick (useful for models with no direct successor), or disable them in bulk.
• Status filter to show only active or disabled agents
• Search by agent name or description
• Owner avatar on agent cards showing who owns the agent
• Usage badges on agent cards showing run count and how many people use the agent
• Connector icons on agent cards showing attached connectors
• Failure badge on agent cards when the latest run failed
• A lock badge on private agents you don’t own

​

Runtime capabilities

• Connected MCP server tools and resources selected on the agent
• Built-in local tools for shell commands, file reads, file writes, and edits
• Web browsing (a real Chromium browser for fetching and interacting with web pages; limit what it can reach with the network access policy)
• 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
• Scheduled continuations, when enabled: the agent ends its run and is woken up later to continue the same conversation
• Git access to your GitHub repositories (clone, push, open pull requests) as your organization’s GitHub App, when GitHub access is enabled and granted to the agent

​

Filesystem workspace

​

Artifact publishing

​

Artifact sharing

​

Viewing and deleting artifacts

​

Shell and code execution

​

Network access policy

• Unrestricted (default): the agent can connect to any public host.
• Allow list: the agent can only connect to the listed hosts. Every other connection it opens is blocked; with no hosts listed, the agent cannot connect to any host of its own choosing.
• Block list: the agent can connect to any public host except the listed ones.

​

Environment variables

​

Waiting on external work

• Calling schedule_continuation again replaces the pending wake-up; cancel_scheduled_continuation drops it. Either call is refused if that wake-up is already starting its run, and the tool result says so.
• Files under /tmp/workspace survive only if the runtime session is still warm when the continuation lands (short delays). The tool result tells the agent whether that is the case so it can save what it needs first.
• A continuation is not started if the original run was cancelled, or if the agent was disabled or deleted in the meantime.
• Slack-started conversations continue in the same thread; the agent uses say to post when the thread should hear from it.

​

Runtime limits

• Agent runs are short-lived; long-running services and background daemons are not a good fit.
• Runs are limited to 8 hours (configurable per deployment).
• 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.

​

Runtime enforcement inside the sandbox

​

Human-in-the-loop approvals

​

Usage limits

​

Run limits

​

Cost budgets

​

Budget alerts

​

LLM providers

​

Runlayer Assistant model

​

Recommended model

​

Model settings

​

Agent memory

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

​

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.

​

Memory scopes

• Channel is the safest default for Slack-facing agents: what the agent learns in one channel or DM stays there.
• User is for personal preferences. Because it follows the person, anything the agent saved from a private DM can come up when that person talks to it in a shared channel.
• Agent is global. Use it for facts every user of the agent should benefit from, such as checkpoints or team conventions.

​

Self-improving agents

​

Improving agents over time

​

Subagents

​

Agent policies

​

Error notifications

​

Webhook receivers

import base64
import hashlib
import hmac
import json
import time


def verify_notification(raw_body: bytes, headers: dict[str, str], secret: str):
    event_id = headers["webhook-id"]
    timestamp = headers["webhook-timestamp"]
    if abs(time.time() - int(timestamp)) > 300:
        raise ValueError("Stale webhook timestamp")
    if not secret.startswith("whsec_"):
        raise ValueError("Invalid signing key")
    key = base64.b64decode(secret.removeprefix("whsec_"), validate=True)
    signed = f"{event_id}.{timestamp}.".encode() + raw_body
    expected = base64.b64encode(hmac.digest(key, signed, hashlib.sha256)).decode()
    signatures = headers["webhook-signature"].split()
    if not any(hmac.compare_digest(signature, "v1," + expected)
               for signature in signatures):
        raise ValueError("Invalid webhook signature")
    payload = json.loads(raw_body)
    if payload["event_id"] != event_id:
        raise ValueError("Event ID mismatch")
    return payload

​

Deployment pilot

​

Multi-agent strategy

• 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
• Admins with the Manage Agents capability can transfer an agent to a new owner in the same organization from the Share modal
• 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

​

Sharing an agent

​

Shared agents and user credentials

​

Who does the agent run as?

​

Gradual rollout

1. Create the agent as Private and validate behavior in chat.
2. Share it with a pilot user, group, or role at Can use level and monitor the Sessions tab; tighten prompt and tool scope as needed.
3. Widen general access to Everyone at your organization (or mark the agent Public) when you’re confident.

​

Security and isolation

• Sandboxed execution — each agent runs in an isolated sandbox (see Runtime limits) with a writable workspace at /tmp/workspace. On Kubernetes (sandboxMode: k8s) that is kubernetes-sigs Agent Sandbox with gVisor or Kata Containers on the sandbox nodes — see Runlayer Operator — K8s Agent Sandbox.
• Per-agent filesystem — workspace persistence is scoped by agent ID; other agents do not share those files (see Filesystem workspace).
• Per-agent memory — the optional workbench memory is scoped to a single agent; other agents cannot read it (see Agent memory). Scoped memory separates visibility by user or channel.
• Policy, scanning, and audit on every call — local tools and MCP calls pass through Runlayer policy, ToolGuard scanning, and audit flows, plus any agent policies scoped to that agent.
• Tenant isolation — Runlayer deployments are isolated per tenant: dedicated-account and dedicated-VPC topologies isolate at the AWS account or network boundary, and the multi-tenant Runlayer Operator gives each tenant its own namespaces, database, Redis, and IAM roles on a shared EKS cluster. See the Account Strategy & Isolation section in Deployment Overview.

​

Use Runlayer MCP inside agents

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

• “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.”

​

Manage agents with Terraform

​

Agents vs Agent Accounts

​

Related docs