Migrate from Runlayer to Guild

Runlayer is a commercial AI control plane: an MCP gateway, a catalog, runtime security, agent identity and governance, and Runlayer Agents. You create those agents in its UI or from clients your teams already use, such as Slack, Claude, Cursor, ChatGPT, and Codex. A Runlayer agent is a prompt, a model, a set of MCP connectors, optional skills and env vars, and triggers. Each of those has a Guild counterpart, and the Guild version lives in files you can review, version, and share on the Hub.

Who this is for

Teams with Runlayer Agents who want agents as code: reviewable files, semver versions, forks from a Hub, and triggers managed from a CLI.

Concept map

Guild	Runlayer
`PROMPT.md` (Native) or `AGENTS.md` (OpenClaw)	Main prompt and instructions
`guild.yaml` `models` fallback list	Model
`guild.yaml` `integrations` with a `tools` list	MCP connectors with per-tool selection
Integrations	Catalog and MCP Gateway servers
OpenClaw `skills/<name>/SKILL.md`	Skills
Credentials or workspace variables	Env vars
OpenClaw’s built-in shell, files, and git	Code mode, and the sandbox shell, files, and browser
Schedule trigger	Cron schedules
Event or API trigger	Webhooks and API
Slack `app_mention` event trigger	Slack mentions
Slack `message` event trigger	Slack channel monitors
Member-scoped or agent-scoped credentials, plus identity mapping	Agent Accounts (on-behalf-of or machine)
Credential policies	Policies
A credential policy scoped to the agent (who can call it), plus a `ui_prompt` confirmation (sign-off on each call)	Guarded tool calls
`guild agent save` with semver	Version on every save
Workspaces and Hub visibility	Share with Can use / Can edit
Guild Evaluations and `guild agent test`	Agent Evals

Before you start

guild auth login
guild workspace select

Inventory

Runlayer agents live in Runlayer, so collect their definition from the UI or from a runlayer_agent Terraform resource. Terraform covers the prompt, model, connectors, skills, env var names, and built-in tools. Read triggers, sharing, and approvals from the agent’s page in the app, and check its version history in case it was edited there.

Name, main prompt, and instructions.
Model and any fallback.
Each MCP connector and the tools selected on it.
Skills and env var names (never values).
Built-in tools in use: memory, code mode.
Triggers: schedules, webhooks, API, Slack mentions and channel monitors, Microsoft Teams, iMessage, audit-event triggers.
Subagents and allowed agents, the network access policy, GitHub access, and memory scopes.
Guarded tools and who approves them.
Whether the agent acts on behalf of users or as its own account.

Steps

Pick the agent type and scaffold

Text in and out with tools: Native. Code mode turned on, or a prompt that relies on shell commands, files, the browser, or GitHub access: OpenClaw. Typed input or deterministic steps: TypeScript. Every Runlayer agent has a sandbox, so decide by what the prompt actually uses.

guild agent init --name incident-scribe --agent-type GUILD_NATIVE \
  --category <category> --owner <owner>

--category and --owner stop the CLI from prompting, which a script or coding agent can’t answer. List categories with guild agent categories.

Move the prompt

PROMPT.md

You are Incident scribe. When asked about an incident, collect the timeline from the Slack channel
and the PagerDuty incident, then draft a postmortem page in Notion. Ask before creating the page.

“Ask before creating the page” relies on the ui_prompt built-in in the next step: the agent confirms with the user, and the run pauses until someone answers. That covers the sign-off half of a Runlayer guarded call. For the other half, which agents can call the operation at all, add a credential policy rule scoped to the agent and workspace.

Map connectors to integrations

guild integration list
guild integration operation list <owner~integration> --json

guild.yaml

models:
  - provider: anthropic
integrations:
  - name: <owner>~pagerduty
    version: ^1.0.0
    tools: [pagerduty_incidents_get]
  - name: <owner>~notion
    version: ^1.0.0
    tools: [notion_pages_create]
builtins:
  - name: ui
    tools: [ui_prompt]

For a connector with no Guild integration, create one from the service’s OpenAPI spec or MCP server with guild integration create.

Set the agent's settings

Move each non-secret Runlayer env var, such as a channel name or a Notion parent page, into a workspace variable. A Native prompt reads it as {{env.KEY}}.

guild workspace variable set INCIDENT_CHANNEL=incidents --workspace <owner~workspace>
guild workspace variable set NOTION_PARENT_PAGE=<page-id> --workspace <owner~workspace>

Workspace variables can appear in chat logs and model instructions, so recreate secrets as credentials instead.

Test

git add -A
guild agent test

guild agent test uploads only the files git tracks, so git add -A stages new files such as logic.ts first. Without it, the cloud build fails with “Cannot find module ’./logic.ts’”.

Publish and recreate triggers

guild agent save --message "Port from Runlayer" --wait --publish
guild workspace agent add <owner~agent> --workspace <owner~workspace>
guild trigger create --workspace <owner~workspace> --type webhook --agent <owner~agent> \
  --integration slack --event app_mention \
  --input '{"type":"text","text":"{webhook_payload}"}'

This recreates a Slack mention trigger. For a Slack channel monitor, use --event message and invite the Slack agent to the monitored channels.For a Runlayer cron schedule, use a CRON trigger. It accepts a timezone, such as Europe/Athens, and Guild converts the schedule to UTC:

guild trigger create --workspace <owner~workspace> --type time --agent <owner~agent> \
  --frequency CRON --cron-expression "0 9 * * 1-5" --cron-timezone Europe/Athens \
  --input '{"type":"text","text":"Post the daily incident summary."}'

The first guild agent save --wait --publish after guild agent init fails with “No saved state… use —force” because of the .gitignore the scaffold writes. Add --force to that first save for now.

You can also publish with the Publish Agent to Guild GitHub Action instead of guild agent save --publish. The Action needs an account API key with the agents:write scope:

guild api-key create --owner <owner> --name "Publish migrated agent" --scopes agents:write

Credentials and policies

Runlayer Agent Accounts become Guild credentials:

An agent that acts on behalf of the invoking user uses member-scoped credentials, with identity mapping so Slack- or GitHub-started runs act as the right person.
A machine-to-machine agent uses a credential dedicated to that agent.

Runlayer policies on servers and tools become credential policies on operations and resources.

What doesn’t map 1:1

Runtime security scanners

Runlayer’s ToolGuard and AgentGuard scanners, argument-level policies, and Shadow AI discovery go beyond Guild credential policies. Both products restrict agent egress: Runlayer with a per-agent network access policy, Guild by cutting container network access before the agent runs, so only Guild proxies can reach out.

Requester approvals

Runlayer guarded calls are approved by the requester and expire after set windows; a pending request lapses after 24 hours. Guild has no requester-only approval with an expiry window. It splits a guarded call into two controls. To control which agents can call the operation at all, add a credential policy rule scoped to the agent and workspace that allows or denies that operation. DENY wins. To have a person sign off on each call, have the agent confirm with ui_prompt first. The run pauses until someone answers.

Audit-event triggers and continuations

Runlayer audit-event triggers with semantic conditions, and schedule_continuation, have no direct Guild equivalent. Use a schedule trigger instead.

Microsoft Teams and iMessage triggers

Runlayer agents can start from Microsoft Teams or iMessage. Guild has no trigger for either. Check guild integration list for the service first.

Self-hosted runtimes

Runlayer offers customer-hosted runtimes on ECS or Kubernetes. Guild is hosted only.

Three ways to migrate

guild-migrate skill

Paste the Runlayer agent’s fields into your coding agent and ask: “Rebuild this Runlayer agent on Guild.”

Publish Agent to Guild Action

Commit the port to your repository, then publish it from GitHub Actions with an account API key.

Migration agent

Commit the agent spec to a repository and point Migrate to Guild at it. The guild-migrate skill ships in the same package.

A worked example (Runlayer agent spec, then a Guild Native agent) lives in examples/migrations/runlayer/ in the guild-migrate repository.

Native agents

PROMPT.md, guild.yaml, and constraints.

Credential policies

ALLOW/DENY rules by operation, resource, agent, and workspace.

Overview

The Smith

The Factory

Platform

Agent SDK

Migrations

Migrate from Runlayer to Guild

Who this is for

Concept map

Before you start

Inventory

Steps

Credentials and policies

What doesn’t map 1:1

Three ways to migrate

guild-migrate skill

Publish Agent to Guild Action

Migration agent

Native agents

Credential policies

​Who this is for

​Concept map

​Before you start

​Inventory

​Steps

​Credentials and policies

​What doesn’t map 1:1

​Three ways to migrate

guild-migrate skill

Publish Agent to Guild Action

Migration agent

​Related pages

Native agents

Credential policies

Who this is for

Concept map

Before you start

Inventory

Steps

Credentials and policies

What doesn’t map 1:1

Three ways to migrate

Related pages