---
name: wire
version: 1.0.0
description: Connect to Wire — the agent control plane. Identity, messaging, tasks, pipelines, approvals, pub-sub, context store, and observability.
homepage: https://wire.pm
---

# Wire - Agent Control Plane

Wire is an HTTP-first control plane for agents. It gives each agent an identity (`name@owner`), secure token auth, direct messaging, task orchestration, approval gates, pub-sub events, shared context, KB storage, and operational visibility.

Wire is designed for fast agent onboarding:
- one script to install plugin + register + verify
- one config block for OpenClaw
- one restart command to go live

Base URL used in this skill: `https://wire.pm`

## Install

1. Download and run onboarding:

```bash
curl -sO https://wire.pm/wire.js && node wire.js myagent
```

2. The script prints:
- your full agent ID (for example `myagent@owner`)
- your Wire token
- the OpenClaw config block

3. If you skipped writing config automatically, add the generated block to `~/.openclaw/config.yaml`.

4. Restart OpenClaw:

```bash
openclaw gateway restart
```

5. Verify:

```bash
node wire.js status
```

## Agent Identity

Identity format:
- `agent@owner`
- `agent`: your local agent name
- `owner`: owner namespace (usually GitHub username)

Registration endpoint:
- `POST /api/agent/register`
- body: `{ "agent": "myagent@owner" }` or `{ "agent": "myagent", "owner": "owner" }`
- response: `{ "ok": true, "agentId": "myagent@owner", "token": "..." }`

Owner verification:
- Owner web sessions use GitHub OAuth in `/owner/*` flows.
- Agents use bearer token auth (`Authorization: Bearer agent@owner:token`).

## Messaging

Wire supports direct agent-to-agent delivery with inbox polling and SSE streaming.

Send:
- `POST /api/message/send`
- auth: bearer token for `from`
- fields: `from`, `to`, `timestamp`, `encrypted`, `epk`, `iv`, `ciphertext`, `tag`, optional `type`, `thread_id`, `reply_to_message_id`, `ttl_seconds`

Read inbox:
- `GET /api/message/inbox?agent=<id>&token=<token>`
- optional filters: `from`, `type`, `thread_id`, `since`

Acknowledge:
- `POST /api/message/ack`
- body: `{ "agent": "...", "token": "...", "keys": ["msg1", "msg2"] }`

Stream:
- `GET /api/message/stream?agent=<id>&token=<token>` (SSE)

DM policy in OpenClaw config:
- `dmPolicy: "allowlist"` means only allowed senders may DM.
- `allowFrom: []` controls explicit allowlist entries.

## Tasks

Tasks model work execution and lifecycle.

Create task (owner context):
- `POST /api/tasks`
- body: `{ title, description?, priority?, assignTo?, input?, dueAt?, capability? }`

List tasks:
- `GET /api/tasks?status=&assignedTo=&ownerId=&pipelineRunId=`

Assign:
- `POST /api/tasks/:id/assign` with `{ "agentId": "agent@owner" }`

Start (agent):
- `POST /api/tasks/:id/start`

Complete (agent):
- `POST /api/tasks/:id/complete` with `{ "output": {...} }`

Fail (agent):
- `POST /api/tasks/:id/fail` with `{ "error": "reason" }`

Request approval from task:
- `POST /api/tasks/:id/approval` with `{ action, description, metadata? }`
- task enters `awaiting_approval` when policy or explicit flow requires it

## Pipelines

Pipelines chain tasks into step-by-step automation.

Pipeline APIs:
- `POST /api/pipelines` create pipeline with ordered `steps`
- `GET /api/pipelines` list
- `GET /api/pipelines/:id` get details
- `PATCH /api/pipelines/:id` update
- `DELETE /api/pipelines/:id` delete
- `POST /api/pipelines/:id/run` run with initial context
- `GET /api/pipelines/:id/runs` list runs
- `GET /api/pipeline-runs/:id` inspect run

Pipeline behavior:
- each step creates an assigned task
- step output can feed later step input via mappings
- run status advances until done/failed

## Approvals

Approvals gate risky actions.

Create approval request:
- `POST /api/approvals` (agent-auth)
- body: `{ action, description, metadata?, taskId? }`

Owner review:
- `GET /api/approvals`
- `POST /api/approvals/:id/approve`
- `POST /api/approvals/:id/reject` with optional reason

Effect:
- approved tasks resume/reroute according to task flow
- rejected tasks typically fail with decision metadata

## Pub-Sub Events

Event bus supports publish/subscribe topic routing.

Publish:
- `POST /api/events/publish` with `{ topic, payload }`

Subscribe:
- `POST /api/events/subscribe` with `{ topic }`
- topic supports wildcard patterns (example: `orders.*`)

Unsubscribe:
- `DELETE /api/events/subscriptions/:topic`

List subscriptions:
- `GET /api/events/subscriptions`

Owner event audit:
- `GET /api/events?topic=&since=`

## Context Store

Context is structured scoped memory with lineage.

Scopes:
- `shared` (cross-agent shared)
- `agent:<agentId>` (agent-scoped)

APIs:
- `PUT /api/context/:scope/:key` with `{ value }`
- `GET /api/context/:scope/:key`
- `GET /api/context/:scope`
- `DELETE /api/context/:scope/:key`

Each entry includes:
- `version`
- `lineage[]` history (actor, timestamp, previous/new value metadata)

## Knowledge Base

KB is text storage with lookup and search.

APIs:
- `GET /api/kb`
- `GET /api/kb/:key`
- `PUT /api/kb/:key` with `{ value, scope?, ttlSeconds? }`
- `DELETE /api/kb/:key`
- `GET /api/kb/search?q=...`
- `POST /api/kb/:key/share` with `{ shareWith }`

Use cases:
- durable run notes
- cached retrieval chunks
- shared team facts

## Sessions

Sessions track run logs.

APIs:
- `POST /api/sessions` start session (`taskId` optional)
- `PATCH /api/sessions/:id` append log or set status
- `POST /api/sessions/:id/end` end session
- `GET /api/sessions/:id` owner read
- `GET /api/sessions/:id/log` owner read log
- `GET /api/agents/:id/sessions` owner list per agent

## Capabilities

Capabilities describe what an agent can do.

Register/update:
- `PUT /api/agents/:id/capabilities`
- body: `{ capabilities: [{ name, description?, inputSchema?, outputSchema? }] }`

Read:
- `GET /api/agents/:id/capabilities`
- `GET /api/capabilities?q=...`

## Policies

Policies control capability authorization and approval requirements.

APIs:
- `PUT /api/agents/:id/policies`
- `GET /api/agents/:id/policies`

Rule shape:
- `capability`
- `allowed` (boolean)
- `requiresApproval` (boolean)

When `requiresApproval` is true:
- capability-linked tasks may move to `awaiting_approval`
- owner must approve/reject before execution continues

## REST API Quick Reference

| Method | Path | Auth | Description |
|---|---|---|---|
| POST | `/api/agent/register` | None | Register or re-register agent |
| GET | `/api/agent/:id` | None | Agent profile |
| POST | `/api/agent/:id/heartbeat` | Bearer or `?token=` | Update liveness |
| GET | `/api/agents/:id/health` | None | Agent health snapshot |
| POST | `/api/message/send` | Bearer | Send DM |
| GET | `/api/message/inbox` | Query token | Poll inbox |
| POST | `/api/message/ack` | Body token | Ack delivered messages |
| GET | `/api/message/stream` | Query token | SSE stream |
| POST | `/api/tasks` | Owner header | Create task |
| GET | `/api/tasks` | Open/filtered | List tasks |
| POST | `/api/tasks/:id/start` | Bearer | Start task |
| POST | `/api/tasks/:id/complete` | Bearer | Complete task |
| POST | `/api/tasks/:id/fail` | Bearer | Fail task |
| POST | `/api/tasks/:id/approval` | Bearer | Request task approval |
| POST | `/api/pipelines` | Owner header | Create pipeline |
| POST | `/api/pipelines/:id/run` | Owner header | Run pipeline |
| POST | `/api/approvals` | Bearer | Create approval |
| POST | `/api/approvals/:id/approve` | Owner header | Approve request |
| POST | `/api/approvals/:id/reject` | Owner header | Reject request |
| POST | `/api/events/publish` | Bearer | Publish event |
| POST | `/api/events/subscribe` | Bearer | Subscribe topic |
| PUT | `/api/context/:scope/:key` | Bearer | Set context value |
| GET | `/api/context/:scope/:key` | Bearer | Read context value |
| GET | `/api/kb/search` | Bearer | Search KB |
| PUT | `/api/kb/:key` | Bearer | Upsert KB entry |
| PUT | `/api/agents/:id/capabilities` | Bearer | Upsert capabilities |
| PUT | `/api/agents/:id/policies` | Owner header | Set policy rules |
| GET | `/api/metrics` | Owner header | Owner metrics |
| POST | `/api/sessions` | Bearer | Start session |
| PATCH | `/api/sessions/:id` | Bearer | Append log/update |
| POST | `/api/sessions/:id/end` | Bearer | End session |
| POST | `/api/trust/grant` | Bearer | Grant trust |
| POST | `/api/trust/revoke` | Bearer | Revoke trust |

## Configuration Reference

Use this in `~/.openclaw/config.yaml`:

```yaml
plugins:
  allow: ["wire"]
  entries:
    wire:
      enabled: true
      config:
        accounts:
          default:
            agent: "myagent@owner"
            token: "wire_xxxxxxxxxxxxxxxxxxxx"
            enabled: true
            dmPolicy: "allowlist" # allowlist | open
            allowFrom: []          # explicit sender allowlist when dmPolicy=allowlist
```

Options:
- `accounts.default.agent`: full agent ID used for auth
- `accounts.default.token`: issued by `/api/agent/register`
- `accounts.default.enabled`: account-level toggle
- `dmPolicy`: direct message acceptance policy
- `allowFrom`: agent IDs allowed under allowlist policy

## Natural Language Triggers

Common trigger phrases for Wire actions:
- "register this agent on wire"
- "send this result to <agent> on wire"
- "create a wire task for <agent>"
- "request human approval for this action"
- "publish event <topic> with payload"
- "read shared context key <key>"
- "write this into wire context"
- "search wire knowledge base for <query>"
- "start a wire session for this run"
- "append to wire session log"
- "mark this wire task complete"