OpenClaw App Integration and Platform Composition v1

Purpose

• Define how OpenClaw can run as an app on the GPUaaS platform using a local LLM backend (vLLM) for private, self-hosted AI assistant capabilities.
• Use OpenClaw as a stress test for the app platform's composition model — specifically, the ability for one app instance to discover and call another.
• Identify the platform primitives that OpenClaw needs and that other composed workloads (Open OnDemand + Slurm, Rancher + K8s, ML pipelines) will also need.

Related: - doc/architecture/App_Platform_Gap_Tracker_v1.md - doc/architecture/App_Runtime_External_Worker_Contract_v1.md - doc/architecture/App_Developer_Starter_Pack_v1.md - doc/architecture/App_Control_Plane_v1.md - doc/architecture/App_Platform_Primitive_Boundary_v1.md - doc/architecture/Launchable_OCI_Workload_Profile_Contract_v1.md - doc/architecture/Hierarchical_Placement_and_Node_Scheduler_v1.md - doc/product/Navigation_Redesign_App_Platform_v1.md — embedded UI pattern - doc/product/Slurm_UI_Options_v1.md — embedded UI gateway contract dependency - packages/services/appruntime/service.go — runtime dispatch and launchable OCI path - packages/web/src/lib/apps/extensions.ts — frontend extension registry

---

Status and Review Decision

OpenClaw should be treated as a reference composed app, not as a special platform feature. The integration must reuse the app catalog, app instance, launchable OCI, artifact, secret, endpoint, audit, and lifecycle contracts.

Implementation priority:

1. run OpenClaw and vLLM in one launchable compose workload on one allocation;
2. promote endpoint reporting and dependency selection into generic app primitives;
3. add platform proxy and webhook ingress after the private/local flow works;
4. defer CPU-only and cross-allocation composition until the scheduler/resource model can place CPU, memory, storage, network, and GPU resources uniformly.

Non-goals:

1. no OpenClaw-specific routes in the core API;
2. no OpenClaw-specific scheduler logic;
3. no user-supplied compose templates in v1;
4. no unauthenticated public webhook ingress without a signed-token, rate-limit, and audit model.

---

1. What Is OpenClaw

OpenClaw is an open-source (MIT) personal AI assistant. It is a Node.js gateway that routes conversations across 25+ messaging channels (Slack, Discord, Telegram, WhatsApp, email, etc.) to LLM backends.

Key facts: - public project and documentation describe it as a local-first personal AI assistant with a gateway security boundary - TypeScript/Node.js project with CLI, daemon, channel ingress, automation, and plugin/tool surfaces - LLM-agnostic — supports Anthropic, OpenAI, Gemini, local servers (Ollama, vLLM, SGLang, LMStudio) - Does not run LLMs itself — it is a gateway/proxy that calls LLM APIs - Lightweight — Node.js >= 22 is the commonly documented baseline, and no GPU is required for OpenClaw itself - Docker support — Dockerfile and docker-compose.yml included - MCP (Model Context Protocol) support for tool use - Persistent memory, voice, vision, Canvas workspace, cron/webhook automation

Sources reviewed April 18, 2026: - https://github.com/openclaw/openclaw - https://openclawlab.com/en/

---

2. Why OpenClaw Matters for the Platform

OpenClaw is the first app that tests app composition: it does not want to run alone. It wants to call another running app instance (vLLM) for private LLM inference. This is the same pattern that:

• Open OnDemand needs (calls Slurm for job submission)
• Rancher needs (manages downstream K8s clusters)
• ML pipelines need (training app → inference app → serving app)
• Any monitoring stack needs (Grafana calls Prometheus on the same cluster)

If the platform can support OpenClaw + vLLM cleanly, it can support composed workloads generally. If it cannot, every future multi-app integration will hit the same gaps.

The design test is not whether the platform can hardcode OpenClaw. The test is whether an app developer can express:

1. required images and artifacts;
2. runtime parameters and secrets;
3. private endpoints;
4. dependencies on another app endpoint;
5. persistence mounts;
6. access mode;
7. lifecycle and health reporting.

These are platform primitives. OpenClaw-specific channel setup, agent behavior, tool plugins, and LLM provider configuration remain app-owned concerns.

---

3. Target Deployment Model

┌─────────────────────────────────────────────────────────────┐
│ Project: my-ai-lab                                           │
│                                                              │
│  App Instance: vllm-llama (vllm-openai)                      │
│    ├── Allocation: gpu-alloc-01 (H200, 1 GPU slice)          │
│    ├── Container: vllm serving Llama-3-70B                   │
│    ├── Endpoint: openai-api @ 10.100.0.12:8000               │
│    └── Status: running                                       │
│                                                              │
│  App Instance: my-openclaw (openclaw)                        │
│    ├── Allocation: gpu-alloc-01 (same) or cpu-sidecar        │
│    ├── Container: openclaw gateway                           │
│    ├── Config: OPENAI_API_BASE = http://10.100.0.12:8000/v1  │
│    ├── Endpoint: gateway @ 10.100.0.12:18789                 │
│    ├── Endpoint: bridge @ 10.100.0.12:18790                  │
│    └── Status: running                                       │
│                                                              │
│  User accesses OpenClaw via:                                 │
│    - Slack/Discord/Telegram (webhook to gateway)             │
│    - Browser (embedded UI in platform shell)                 │
│    - CLI/TUI (via SSH tunnel to allocation)                  │
│                                                              │
│  OpenClaw routes queries to vLLM (local, private LLM)        │
└─────────────────────────────────────────────────────────────┘

The user gets: a private AI assistant backed by a private LLM, accessible from any messaging platform, running entirely on their own GPU allocation.

---

4. Deployment Options

4.1 Option A: OpenClaw + External LLM API (works today)

OpenClaw as a standalone OCI workload on a GPU allocation. Configured to call an external LLM API (Anthropic, OpenAI). No local LLM, no composition.

slug: openclaw
profile:
  kind: gpuaas.launchable_oci_workload
  launch_mode: existing_allocation
artifacts:
  primary_image:
    source: platform_registry
    artifact_name: openclaw-gateway
execution:
  default_engine: node_agent
  container_env:
    OPENCLAW_MODEL: "anthropic/claude-sonnet-4-20250514"
network:
  endpoints:
    - name: gateway
      port: 18789
      protocol: http
    - name: bridge
      port: 18790
      protocol: http
resources:
  gpu: { count: 0 }

Platform changes required: None.

Limitations: - No private LLM — queries go to external APIs over the internet. - exposure_mode: private only — user must SSH-tunnel to reach the gateway. Messaging platform webhooks (Slack, Telegram) cannot reach it. - Running on a GPU allocation wastes GPU resources (OpenClaw is CPU-only). - API keys are in plain-text env vars (no secrets injection).

Value: Low. This is "run a Docker container on a GPU node." It does not demonstrate platform value.

4.2 Option B: OpenClaw + vLLM on Same Allocation (compose, preferred v1)

Both containers on one GPU allocation. OpenClaw calls vLLM at localhost:8000.

Platform changes required: - Generic compose template path (see §5.2) - Secrets injection into container env for external providers and messaging channels (see §5.5). The local vLLM-only smoke can use a non-secret local API key placeholder.

Manifest shape:

slug: openclaw-local-llm
profile:
  kind: gpuaas.launchable_oci_workload
  launch_mode: existing_allocation
execution:
  default_engine: docker_compose
  compose_template: |
    services:
      vllm:
        image: "{{artifact.vllm_image}}"
        ports: ["8000:8000"]
        deploy:
          resources:
            reservations:
              devices:
                - driver: nvidia
                  count: all
                  capabilities: [gpu]
        command: >
          --model {{param.model_id}}
          --tensor-parallel-size {{param.gpu_count}}
          --host 0.0.0.0 --port 8000
      openclaw:
        image: "{{artifact.openclaw_image}}"
        ports: ["18789:18789", "18790:18790"]
        environment:
          OPENCLAW_MODEL: "openai/{{param.model_id}}"
          OPENAI_API_BASE: "http://vllm:8000/v1"
          OPENAI_API_KEY: "not-needed"
        depends_on:
          vllm: { condition: service_healthy }

Advantages: - Single allocation, both containers share Docker network (localhost or compose service names resolve). - No service discovery needed — containers see each other by compose service name. - One deploy action from the user's perspective. - Avoids cross-allocation networking and CPU-only placement before those primitives are ready.

Limitations: - Still needs the generic compose template path (§5.2). - GPU is shared between vLLM and OpenClaw — but OpenClaw uses zero GPU, so this is fine in practice. - If vLLM needs the full GPU and OpenClaw needs only CPU, the allocation shape is driven by vLLM's requirements.

4.3 Option C: Two Separate App Instances (production direction)

vLLM and OpenClaw as independent app instances. OpenClaw discovers vLLM's endpoint through the platform API.

User deploys vLLM app instance (existing flow — already works)
  → vLLM starts, reports endpoint: { "openai-api": "10.100.0.12:8000" }

User deploys OpenClaw app instance
  → Deploy dialog: "Select LLM backend" → picks running vLLM instance
  → Platform resolves vLLM endpoint
  → Injects OPENAI_API_BASE into OpenClaw env
  → OpenClaw starts, calls vLLM at resolved address

Platform changes required: - Service discovery API (§5.1) - App instance dependency declaration (§5.3) - Secrets injection (§5.5)

Advantages: - Independent lifecycle — upgrade vLLM without restarting OpenClaw, and vice versa. - Different allocations possible — vLLM on a 4-GPU slice, OpenClaw on a 1-GPU slice or even a CPU-only allocation (if supported). - Multiple OpenClaw instances can share one vLLM backend. - The service discovery primitive is reusable for all composed workloads.

Limitations: - Requires the service discovery API to exist. - Network routing between allocations on the same node (or across nodes) must work — both need to be on the same management network. - Requires the hierarchical placement model to understand app-level locality intent without leaking node-local PCI, fabric, or storage details into the app contract.

---

5. Platform Primitives Needed

These are ordered by value — the first two unblock OpenClaw and every other composed workload.

5.1 Service Discovery API

What: A typed API to query the runtime endpoints of a running app instance.

GET /api/v1/projects/{project_id}/app-instances/{app_instance_id}/endpoints

Response:
{
  "endpoints": [
    {
      "name": "openai-api",
      "host": "10.100.0.12",
      "port": 8000,
      "protocol": "http",
      "status": "healthy",
      "allocation_id": "...",
      "node_id": "..."
    }
  ]
}

Where the data comes from: The launchable OCI reconcile loop already reads container status, declared endpoints, health probes, and port bindings. Endpoint info may be stored in app_instances.runtime_state or a future typed read model, but callers should consume only the contract response.

Who needs it: - OpenClaw (calls vLLM) - Open OnDemand (calls Slurm controller) - Grafana (calls Prometheus) - Any future app that composes with another app

Contract-first: Add to openapi.draft.yaml before implementing.

Scope for v1: Read-only and same-project only. The platform should populate endpoints from app manifests plus runtime reconcile data. Apps should not be allowed to publish arbitrary reachable addresses directly into discovery.

5.2 Generic Compose Template Path

What: Allow app manifests to carry an admin-approved compose template with bounded platform variable substitution, instead of requiring a hardcoded named renderer per app.

Current state: renderLaunchableComposeNodeTaskParams in service.go hard-rejects any renderer other than "vllm_openai". The platform generates compose YAML server-side using renderVLLMOpenAIComposeYAML. There is no generic template path.

Proposed model:

# In app manifest
execution:
  default_engine: docker_compose
  compose_template: |
    services:
      inference:
        image: "{{artifact.primary_image}}"
        ...
      gateway:
        image: "{{artifact.gateway_image}}"
        environment:
          API_BASE: "http://inference:8000/v1"
          API_KEY: "{{secret.llm_api_key}}"
        ...

The platform renders the template at launch time from validated launch values, substituting: - {{artifact.<name>}} — resolved digest-pinned image refs from app_version_artifacts - {{param.<name>}} — user-supplied parameters from the deploy dialog - {{secret.<name>}} — secrets from the runtime secret bundle - {{dependency.<role>.<endpoint_name>.host}} — resolved service discovery endpoints (requires §5.1) - {{allocation.node_ip}}, {{allocation.username}} — allocation context

Security constraints: - Templates are stored in the manifest (admin-approved, not user-supplied at deploy time). - The render step runs server-side, not on the node. - All image refs must be digest-pinned after rendering. - Secret values are injected at render time and passed to the node-agent task; they are not stored in the manifest. - Rendered compose YAML must not be accepted from tenants as free-form input in v1; app teams iterate through artifact/version publication. - The rendered task payload must be redacted in logs and audit details.

What this replaces: Named renderers (vllm_openai). The existing vLLM-OpenAI renderer becomes a manifest with a compose template instead of a hardcoded Go function. New apps never need a platform code change for their compose layout.

5.3 App Instance Dependency Declaration

What: Allow an app instance to declare a runtime dependency on another running app instance in the same project.

# In launch values or placement intent at deploy time
dependencies:
  - role: llm_backend
    instance_id: "uuid-of-vllm-instance"
    required_endpoint: "openai-api"

Platform behavior: 1. At deploy time, validate the referenced instance exists, is running, belongs to the same project, and exposes the required endpoint. 2. Resolve the endpoint address and inject it into the new instance's environment (via the compose template or OCI env vars). 3. If the dependency instance stops or is decommissioned, surface a degraded state on the dependent instance (not auto-stop — just a warning).

Scope for v1: Soft dependency only. The platform resolves and injects at deploy time. It does not enforce the dependency at runtime (no automatic restart if the backend goes down). The dependent app is responsible for handling backend unavailability.

Cross-project or tenant-shared backends are deferred. They need explicit attachment, IAM, billing attribution, and network policy, not an implicit endpoint lookup exception.

5.4 Exposure Mode: Platform Proxy

What: Allow app instances to expose HTTP endpoints through the platform's reverse proxy, making them reachable without SSH tunneling.

Current state: exposure_mode: platform_proxy exists in the manifest schema and node-agent code but is not wired in any seeded app or the UI. Only private works today.

Why OpenClaw needs it: Messaging platform webhooks (Slack, Telegram, Discord) need to reach OpenClaw's gateway endpoint over the internet. With private mode only, the user must maintain an SSH tunnel or external proxy — defeating the purpose of a hosted assistant.

Dependency: This is the same reverse proxy / embedded UI gateway contract from doc/architecture/Embedded_UI_Gateway_Contract_v1.md. The same proxy that would embed Grafana or Rancher can expose OpenClaw's webhook endpoint.

Scope for v1: Expose HTTP endpoints through the platform proxy with project-level auth for browser access. Webhook endpoints need a separate signed ingress contract with route-level rate limits, request-size limits, audit correlation, and optional source allowlists. They must not become unauthenticated raw tunnels to the allocation.

5.5 Secrets Injection

What: Inject secrets (API keys, tokens) into app container environments without storing them in plain text in the manifest or node_tasks params.

Current state: IssueAppInstanceRuntimeSecretBundle exists in the API (POST .../runtime-secrets), but the launchable OCI launch path does not use it. Container env vars in the manifest are plain text.

What OpenClaw needs: - ANTHROPIC_API_KEY (if using Anthropic as fallback) - SLACK_BOT_TOKEN, SLACK_APP_TOKEN (Slack integration) - DISCORD_BOT_TOKEN (Discord integration) - TELEGRAM_BOT_TOKEN (Telegram integration) - Various other provider API keys

Proposed model:

1. User stores or references secrets through an app secret contract. Reuse the runtime-secret bundle path where possible; add a first-class instance secret endpoint only if the current contract cannot represent user-managed channel tokens.
2. At launch time, the platform resolves {{secret.<name>}} template variables from the secret store.
3. Secrets are passed to the node-agent task as encrypted params (using the existing task signing infrastructure).
4. Node-agent injects them as container env vars or mounted secret files at docker run / compose time.
5. Secrets are never stored in app_instances.runtime_state or node_tasks.params in plain text.

5.6 CPU-Only Workload Support (deferred)

OpenClaw does not need a GPU. Running it on a GPU allocation wastes an expensive resource. Options:

1. Sidecar on the same allocation as vLLM (compose approach) — no platform change needed. OpenClaw shares the allocation but uses only CPU. This is the pragmatic v1 answer.
2. CPU-only allocation shape — new capacity shape that schedules onto non-GPU nodes or onto GPU nodes with available CPU. Larger platform change. Defer unless there is demand for many CPU-only workloads.
3. Run on a 1-GPU slice — wastes one GPU but works today. Acceptable for dev/lab; not ideal for production cost.

Recommendation: Use the compose approach (Option B) for v1. Defer CPU-only allocations until the region/cluster/node scheduler split can safely place non-GPU workloads without weakening GPU slice isolation and billing.

---

6. OpenClaw-Specific Integration Details

6.1 LLM Provider Configuration

OpenClaw configures its LLM backend via a simple config:

{
  "agent": {
    "model": "openai/meta-llama/Llama-3-70B"
  }
}

When pointed at a vLLM instance, it uses the OpenAI-compatible API: - OPENAI_API_BASE=http://{vllm_host}:8000/v1 - OPENAI_API_KEY=not-needed (vLLM doesn't require a key by default)

The platform's deploy dialog should surface this as: - LLM backend: [Select running vLLM instance] or [External API] - Model: [auto-populated from vLLM instance's model]

6.2 Messaging Channel Setup

After deployment, the user configures messaging channels through OpenClaw's own setup flow (CLI or web UI). The platform does not need to mediate this — it is OpenClaw's responsibility.

However, the platform should surface the gateway endpoint URL in the instance detail page so the user can configure webhooks: - Slack: https://{proxy_url}/api/v1/app-proxy/{instance_id}/slack/events - Telegram: https://{proxy_url}/api/v1/app-proxy/{instance_id}/telegram/webhook

This requires the platform proxy (§5.4) to be active.

6.3 Persistent State

OpenClaw uses SQLite for state and LanceDB for memory/vector search. These must survive container restarts.

Mount requirements: - /home/openclaw/.openclaw → persistent volume on the allocation

The existing OCI workload mount model (/workspace or subdirectories) covers this. The manifest declares:

storage:
  mounts:
    - name: openclaw-data
      path: /home/openclaw/.openclaw
      host_path: workspace/openclaw-data

6.4 Frontend Extension

The UI should use the same launch wizard components as other launchable OCI apps. OpenClaw should not add a bespoke deploy page. Its app manifest should declare the additional dependency picker and secret/channel fields that the generic wizard renders.

const openClawExtension: AppShellExtension = {
  slug: "openclaw",
  runtimeBackend: "openclaw",
  deploy: {
    requiredInputs: {
      controllerAllocations: "single",
    },
    missingInputsMessage:
      "OpenClaw deploy requires a target allocation.",
    summaryMessage:
      "Deploy OpenClaw AI assistant. Optionally select a running LLM "
      + "backend instance for private inference.",
    serviceAccountEmptyStateMessage:
      "No active service accounts exist in this project yet.",
    serviceAccountHelpText:
      "Optional machine identity for webhook automation.",
    accessCredentialHelpText: "",
    buildPlacementIntent: ({ controllerAllocationIDs }) => ({
      target_allocation_id: controllerAllocationIDs[0] ?? "",
    }),
    isPlacementComplete: ({ controllerAllocationIDs }) =>
      controllerAllocationIDs.length > 0,
  },
};

If the deploy dialog gains a "dependency picker" (§5.3), the OpenClaw extension would add a field for selecting the LLM backend instance.

Near-term UI recommendation:

1. for same-allocation compose, use one OpenClaw + local vLLM launch card with model, GPU count, storage, and access steps;
2. for independent instances, add a generic platform.app_instance_dependency wizard component that filters to running same-project instances exposing a compatible endpoint;
3. keep channel setup as post-launch configuration in the app detail page until the secret and webhook ingress contracts are complete.

6.5 Instance Detail Tabs

┌── my-openclaw (OpenClaw) ────────────────────────────────────┐
│                                                               │
│  Overview │ Chat │ Config │ Channels │ Logs                   │
│                                                               │
│  Overview  = status, LLM backend connection, endpoint URLs    │
│  Chat      = embedded OpenClaw web UI (platform proxy)        │
│  Config    = model selection, agent settings                  │
│  Channels  = connected messaging platforms, webhook URLs      │
│  Logs      = container logs                                   │
└───────────────────────────────────────────────────────────────┘

The "Chat" tab is the embedded OpenClaw web interface. This depends on the embedded UI gateway contract and platform proxy being active.

---

7. What OpenClaw Teaches About Platform Extensibility

7.1 Current Extensibility Assessment

Pattern	Rating	Notes
Single-container app (OCI)	Good	JupyterLab and vLLM prove it works
Multi-node distributed app (controller)	Good	Slurm and RKE2 prove it works
Multi-container single-node app (compose)	Poor	Hardcoded to one renderer
App-to-app composition	Not supported	No service discovery
Apps with web UIs	Not supported	Platform proxy not wired
Apps needing secrets	Partial	Secret API exists, not used by OCI path
Third-party catalog registration	Poor	SQL-only, static frontend
CPU-only workloads	Not supported	Everything needs a GPU allocation

This assessment is about platform product completeness, not whether OpenClaw can be forced to run manually on a node. Manual Docker/SSH success does not satisfy the app-platform contract unless lifecycle, identity, secrets, endpoints, status, audit, and billing attribution flow through GPUaaS.

7.2 The Composition Gap Is the Most Important

OpenClaw is a symptom. The real issue is that the platform treats every app instance as independent. There is no concept of:

• "App A depends on App B"
• "App A can discover App B's endpoint"
• "If App B goes down, App A should know"

Every composed workload — OpenClaw + vLLM, Open OnDemand + Slurm, training pipeline → inference server → monitoring — will hit this same gap. Solving it for OpenClaw solves it for all of them.

7.3 The Generic Compose Template Is the Second Priority

The hardcoded renderer pattern means every new multi-container app needs a platform code change. This contradicts the "app developers build against platform primitives" model from the app platform design discussions. A template-based compose path lets app developers define their own container topology without touching platform code.

7.4 Exposure Mode Is the Third Priority

Private-only apps are useful for batch workloads (training, inference serving behind an API). But interactive apps — OpenClaw, JupyterLab web UI, Grafana, Open OnDemand — need to be reachable from a browser or from external webhooks. The platform proxy is the gating primitive.

---

8. Implementation Phases

Phase 0: External LLM Lab Smoke (optional, minimal platform change)

Work	Owner
Build OpenClaw container image, publish to platform registry	App developer
Add openclaw catalog entry and version to seed.sql	Platform
Add openClawExtension to extensions.ts	Platform
User deploys OpenClaw, configures external API key via env	User
User accesses via SSH tunnel	User

Outcome: OpenClaw works but is limited. Proves the OCI path handles a Node.js app. No composition, no local LLM.

Do not treat this as the product milestone. It is only a lab smoke test because it does not prove private inference or app composition.

Phase 1: Same-Allocation OpenClaw + vLLM Compose

Work	Owner
Implement generic compose template path (§5.2)	Platform
Build OpenClaw + vLLM compose manifest	App developer
Add manifest-driven launch wizard fields	Platform
Report both OpenClaw and vLLM endpoints on the app instance	Platform

Outcome: User launches one app instance that runs vLLM and OpenClaw on the same allocation. Private LLM inference works without cross-allocation networking or service discovery.

Phase 2: Typed Endpoints + Dependency Picker

Work	Owner
Implement read-only app instance endpoints API (§5.1)	Platform
Implement same-project dependency declaration (§5.3)	Platform
Add generic dependency picker to launch wizard	Platform
Allow OpenClaw to target an existing vLLM app instance	Platform

Outcome: User can deploy vLLM first, then deploy OpenClaw against that running vLLM endpoint. This proves reusable app-to-app composition.

Phase 3: Platform Proxy + Embedded UI

Work	Owner
Wire exposure_mode: platform_proxy for OCI workloads	Platform
Embed OpenClaw web UI in instance detail page	Platform
Add signed webhook ingress for selected endpoints	Platform
Add route-level rate limits and request-size limits	Platform

Outcome: Users can access OpenClaw through the platform shell and can opt in to signed webhook URLs for messaging channels.

Phase 4: Cross-Allocation and CPU-Aware Composition

Work	Owner
Cross-allocation dependency enforcement beyond deploy-time injection	Platform
Cross-allocation networking (same node or routed)	Platform
CPU-only workload support (optional)	Platform
Scheduler locality hints that remain region/cluster/node boundary-safe	Platform

Outcome: vLLM on a 4-GPU slice, OpenClaw on a 1-GPU slice (or CPU). Independent lifecycle, independent scaling. Multiple OpenClaw instances share one vLLM backend.

---

9. Decisions and Open Questions

1. Decision: compose templates are manifest-owned and admin-approved in v1. User-supplied compose is deferred because it creates a node execution surface, makes audit/redaction harder, and bypasses artifact trust controls.

2. Decision: endpoint discovery is same-project in v1. Cross-project or tenant-shared LLM backends require explicit attachment, IAM, billing, network policy, and audit semantics.

3. Open: exact webhook ingress contract. Slack/Telegram send unauthenticated HTTP to the webhook URL. The platform proxy cannot require a bearer token on these paths. The preferred direction is signed URL plus rate limits, request-size limits, source allowlist where feasible, and per-route audit correlation.

4. Open: backup and persistence policy. If the allocation is released, OpenClaw's conversation history and memory are lost. This is the same storage ephemerality problem as the Slurm UI doc's OOD filesystem analysis. Same recommendation: warn on decommission, offer platform storage mount as opt-in persistence.

5. Open: shared LLM backend product mode. One vLLM instance serving multiple app instances across a project or tenant. This is analogous to the shared Slurm runtime model. If yes, the shared runtime pattern already exists — vLLM could be registered as a shared runtime type.

6. Decision: messaging channel setup remains app/user-owned in v1. Pre-configuration such as Slack app manifests can be added later as app-specific onboarding helpers, but the platform primitive should be secret delivery plus signed endpoint exposure.

7. Open: OpenClaw image curation level. Because assistant/channel plugins can execute tools and touch sensitive services, platform-curated images should pin versions, run security scans, and document supported plugin/channel boundaries before this is exposed outside dev.