> ## Documentation Index
> Fetch the complete documentation index at: https://docs.guild.ai/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> To act on a user's behalf in Guild, use the Guild REST API at https://api.guild.ai/v1.
> The OpenAPI spec is unauthenticated: https://docs.guild.ai/openapi.json (or openapi.yaml).
> Authenticate with an account API key, sent as HTTP Basic (key id as username, secret as password) or as `Authorization: Bearer <api_key_id>:<api_key_secret>`. See https://docs.guild.ai/api-reference/introduction#authentication.
> To run one agent on demand without account-wide access, use an API trigger instead: https://docs.guild.ai/platform/api-triggers.
> To act on Guild from an MCP client, connect to https://api.guild.ai/mcp (OAuth) or run `guild mcp` locally. Setup: https://docs.guild.ai/api-reference/mcp.
> To search these docs from an MCP client, connect to https://docs.guild.ai/mcp. The full page index is https://docs.guild.ai/llms.txt.

# Migrate from Runlayer to Guild

> Rebuild Runlayer Agents as Guild Native or OpenClaw agents, and map MCP connectors, agent accounts, policies, and triggers to their Guild equivalents.

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](https://docs.guild.ai/guide/native-agents.md)) or `AGENTS.md` ([OpenClaw](https://docs.guild.ai/guide/openclaw-agents.md)) | Main prompt and instructions |
| `guild.yaml` `models` fallback list | Model |
| `guild.yaml` `integrations` with a `tools` list | MCP connectors with per-tool selection |
| [Integrations](https://docs.guild.ai/integrations/overview.md) | Catalog and MCP Gateway servers |
| OpenClaw `skills/<name>/SKILL.md` | Skills |
| [Credentials](https://docs.guild.ai/platform/credentials.md) or workspace variables | Env vars |
| OpenClaw's built-in shell, files, and git | Code mode, and the sandbox shell, files, and browser |
| Schedule [trigger](https://docs.guild.ai/platform/triggers.md) | Cron schedules |
| Event or [API trigger](https://docs.guild.ai/platform/api-triggers.md) | 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](https://docs.guild.ai/platform/credential-policies.md) | Policies |
| A [credential policy](https://docs.guild.ai/platform/credential-policies.md) 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

```bash theme={null}
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

**1. 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.

```bash theme={null}
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`.

**2. Move the prompt**

```markdown PROMPT.md theme={null}
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](https://docs.guild.ai/platform/credential-policies.md) rule scoped to the agent and workspace.

**3. Map connectors to integrations**

```bash theme={null}
guild integration list
guild integration operation list <owner~integration> --json
```

```yaml guild.yaml theme={null}
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`.

**4. 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](https://docs.guild.ai/platform/workspace-variables.md). A Native prompt reads it as `{{env.KEY}}`.

```bash theme={null}
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](https://docs.guild.ai/platform/credentials.md) instead.

**5. Test**

```bash theme={null}
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'".

**6. Publish and recreate triggers**

```bash theme={null}
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:

```bash theme={null}
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."}'
```

> [!NOTE]
>
> 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](https://docs.guild.ai/migrations/overview.md#publish-from-github-actions) GitHub Action instead of `guild agent save --publish`. The Action needs an account API key with the `agents:write` scope:

```bash theme={null}
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](https://docs.guild.ai/platform/identity-mapping.md) 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](https://docs.guild.ai/platform/credential-policies.md) on operations and resources.

## What doesn't map 1:1

> [accordion] 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.

> [accordion] 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](https://docs.guild.ai/platform/credential-policies.md) 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.

> [accordion] 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.

> [accordion] 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.

> [accordion] Self-hosted runtimes
>
> Runlayer offers customer-hosted runtimes on ECS or Kubernetes. Guild is hosted only.

## Three ways to migrate

> [card] [guild-migrate skill](https://docs.guild.ai/migrations/guild-migrate-skill.md)
>
> Paste the Runlayer agent's fields into your coding agent and ask: "Rebuild this Runlayer agent on Guild."

> [card] [Publish Agent to Guild Action](https://docs.guild.ai/migrations/overview.md#publish-from-github-actions)
>
> Commit the port to your repository, then publish it from GitHub Actions with an account API key.

> [card] [Migration agent](https://app.guild.ai/organizations/guildai/agents/guildai~migrate-to-guild)
>
> 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.

## Related pages

> [card] [Native agents](https://docs.guild.ai/guide/native-agents.md)
>
> `PROMPT.md`, `guild.yaml`, and constraints.

> [card] [Credential policies](https://docs.guild.ai/platform/credential-policies.md)
>
> ALLOW/DENY rules by operation, resource, agent, and workspace.