OpenClaw is an open-source AI executive assistant that connects to your tools (email, calendar, Slack, etc.) and automates workflows. It's built for teams who want AI that actually does work, not just answers questions.

Do I need technical knowledge?

Not at all. That's the whole point of SetupOpenClaw — we handle every technical detail. You just tell us what you want your AI assistant to do.

Can you set this up remotely?

Yes. Our Hosted Setup and Mac Mini Remote tiers are fully remote. We can deploy for teams anywhere in the UK (and worldwide). Only the Mac Mini In-Person tier requires Leeds & West Yorkshire proximity.

Is this related to the OpenAI acquisition?

No. OpenClaw is an independent open-source project. It uses various AI models and is not owned by or affiliated with OpenAI.

Can I set up OpenClaw myself?

Absolutely — it's open source. But most teams find that security hardening, integration configuration, and ongoing maintenance take significantly more time than expected. We do it in hours with enterprise-grade security.

What if something goes wrong?

During the 14-day hypercare period, we actively monitor and fix any issues. After that, we offer support packages. Plus, every installation includes audit trails and monitoring.

What infrastructure do I need?

For Hosted Setup: nothing — we deploy to a cloud VPS (~£5-10/mo). For Mac Mini tiers: a Mac Mini (~£500). We handle all software configuration.

Can I have multiple agents?

Yes. Each additional agent is £350. Teams often run separate agents for different departments or workflows.

Yes. We use Docker sandboxing, Composio middleware, OAuth token management, audit trails, and read-only defaults. Your data stays on your infrastructure — we never store it.

What about ongoing maintenance?

OpenClaw requires minimal maintenance after setup. We provide documentation for common tasks. For hands-off operation, ask about our maintenance packages.

What is the most important file in an OpenClaw workspace?

SOUL.md is the foundational file. It defines the agent’s core identity, values, communication style, and behavioural boundaries. Every other workspace file builds on the personality and constraints established in SOUL.md. Without it, the agent has no consistent character or guardrails.

How long does it take to configure all 8 workspace files?

A complete workspace configuration typically takes 4–8 hours for a DIY setup, covering SOUL.md, IDENTITY.md, AGENTS.md, USER.md, TOOLS.md, MEMORY.md, HEARTBEAT.md, and BOOT.md. With SetupClaw’s managed service, configuration is completed during the same-day deployment as part of the setup package.

Can I configure workspace files myself without SetupClaw?

Yes — all workspace files are standard markdown that you can edit in any text editor. Our documentation covers every field across all 8 files. SetupClaw’s managed service is for teams who want expert configuration, security hardening, and 14-day hypercare included.

OpenClaw IDENTITY.md Configuration: Agent Name, Role & Platform Routing

What This File Controls

IDENTITY.md is the agent’s public-facing metadata card. While SOUL.md defines how the agent thinks, IDENTITY.md controls how the agent presents itself to the outside world — its display name, role description, visual identifier, platform binding, and operational context.

In single-agent deployments, IDENTITY.md may feel redundant. Its true importance emerges in multi-agent environments: when several agents share a Slack workspace or a Feishu group chat, IDENTITY.md is how the OpenClaw runtime routes incoming messages to the correct agent. The idPlatform and idContext fields act as routing selectors — if two agents share the same platform and context, messages are routed ambiguously and you get routing chaos.

IDENTITY.md is parsed immediately after SOUL.md in the boot sequence. The idName field often mirrors the SOUL.md name field, but they serve different audiences: name is how the agent thinks of itself; idName is how it appears in platform UIs. For hybrid deployments spanning multiple platforms, you can create platform-specific identity overrides using a directory structure pattern.

Why it matters: In group chats or multi-agent setups, this is how messages get routed to the right agent.

Field-by-Field Breakdown

5 fields that shape your agent

idNameRequired

The public-facing name shown to other agents and users.

idName: "e.g. Atlas Support Bot"

idRoleRequired

A one-line description of this agent's function.

idRole: "e.g. Customer Support Agent"

idEmojiOptional

Visual identifier used in multi-agent chat interfaces.

idEmoji: "e.g. 🤖"

idPlatformRequired

The primary platform where this agent operates.

idPlatform: "e.g. Slack, Feishu, WeChat"

idContextOptional

Additional context about the agent's operating environment.

idContext: "e.g. Operates in #support channel, responds to @atlas..."

Real-World Examples

FinleyManchester · 8 people · Accounting

## idName
Finley — Tax & Compliance Assistant

## idRole
Financial research and HMRC compliance assistant for Whitfield & Associates

## idEmoji
📊

## idPlatform
Slack

## idContext
Operates in #tax-queries and #client-research channels. Responds to @finley mentions and direct messages from all partners and associates.

Common Mistakes

Making idName identical to SOUL name

They serve different audiences. The SOUL name is how the agent thinks of itself internally; idName is the public display name shown in platform UIs. The idName often needs additional context (e.g., ‘Finley — Tax Assistant’) that would clutter the internal self-reference.

Setting idPlatform incorrectly during staging

Agents tested on Slack with idPlatform set to ‘Slack’ are then deployed to Microsoft Teams without updating the field. The routing metadata is stale, causing silent message delivery failures or misrouted conversations.

Using confusable emojis in multi-agent deployments

When multiple agents share a workspace, each needs a visually distinct emoji. Using similar icons (e.g., two different robot emojis) makes it difficult for team members to identify which agent responded at a glance.

Using idContext as a freeform comments field

idContext is parsed by the runtime for routing logic — it is not a notes field. Stuffing it with aspirational descriptions or historical context dilutes the routing signal and wastes prompt tokens.

How SetupClaw Handles This

IDENTITY.md is generated automatically during channel connection. Our deployment specialist configures the routing metadata during the platform integration step, then runs a routing smoke test to verify message delivery before handover.

£770

Platform connection + routing smoke test + idContext configured per channel

£1,100

All above + multi-platform identity overrides for hybrid deployments

£2,200

All above + automated routing regression tests on each deployment

All 5 fields configured per deployment platform
Routing smoke test passed
idName aligned with SOUL.md name
Platform-specific overrides if applicable
Emoji uniqueness verified across agent fleet

Configured during platform integration (day 1). Smoke test within 2 hours of deployment.

Advanced Topics

Platform-specific identity overrides for hybrid deployments

For agents operating across multiple platforms (e.g., Slack internally + web widget externally), use a directory structure pattern with platform-specific IDENTITY.md files. OpenClaw resolves the correct file based on the incoming message’s platform metadata. This avoids bloating a single IDENTITY.md with conditional logic.

workspace/
  IDENTITY.md          # default (Slack)
  platforms/
    web/IDENTITY.md    # web widget override
    teams/IDENTITY.md  # MS Teams override

Example Configurations

Persona A — MeridianChief of Staff

# IDENTITY.md -- Public Metadata & Routing

## idName
Meridian

## idRole
Chief of Staff Agent

## idEmoji
💼

## idPlatform
Slack / Executive Dashboard

## idContext
Executive layer; decomposes directives into delegatable tasks for specialist agents

Persona B — Axiom (Veteran Growth Hacker)

# IDENTITY.md -- Public Metadata & Routing

## idName
Axiom

## idRole
Growth Intelligence Agent

## idEmoji
🚀

## idPlatform
Slack / Growth Analytics Dashboard

## idContext
Growth intelligence layer; surfaces experiments, prioritises backlog, monitors funnels

Persona C — Lumen (Scientific Researcher)

# IDENTITY.md -- Public Metadata & Routing

## idName
Lumen

## idRole
Research Intelligence Agent

## idEmoji
🔬

## idPlatform
Research Portal / Notion / Obsidian

## idContext
Primary literature synthesis and evidence evaluation engine

Persona D — Narrative (Senior Content Creator)

# IDENTITY.md -- Public Metadata & Routing

## idName
Narrative

## idRole
Content Strategy & Creation Agent

## idEmoji
🎯

## idPlatform
Notion / CMS / Social Scheduler

## idContext
Primary content intelligence; handles strategy, ideation, drafting, SEO, performance

Persona E — Architect (Chief Engineer)

# IDENTITY.md -- Public Metadata & Routing

## idName
Architect

## idRole
Principal Engineering Agent

## idEmoji
🔧

## idPlatform
GitHub / Terminal / Engineering Wiki

## idContext
Principal engineering adviser; design review, code quality, incident post-mortems

IDENTITY.md — Public metadata & routing