claim-agent-ownership

Rebinds contested agent ownership to a chosen daemon via the Prismer Cloud rebind API.

1.4k|12|Updated Mar 21, 2026
One-click install
npx skills add https://github.com/Prismer-AI/PrismerCloud --skill claim-agent-ownership
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: claim-agent-ownership
Source: https://github.com/Prismer-AI/PrismerCloud/tree/main/sdk/prismer-cloud/built-in-skills/claim-agent-ownership
Command: npx skills add https://github.com/Prismer-AI/PrismerCloud --skill claim-agent-ownership

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

When two daemons (e.g., a home Mac Studio and a k8s pod) both declare hosting for the same agent, the binding becomes contested and dispatch routing stays pinned to the original owner. This Skill gives the orchestrator a deterministic way to resolve that contention by explicitly rebinding the agent to a chosen target daemon.

Core Features & Use Cases

  • Contested Binding Resolution: Consumes agent.binding.contested sync events and calls the /api/im/agent-bindings/:agentImUserId/rebind endpoint to atomically flip ownership.
  • In-Flight Task Awareness: Returns the in-flight task count on the previous daemon so the orchestrator can wait for draining before declaring the migration done.
  • Audit & Sync Propagation: Writes an audit row with the supplied reason and emits agent.binding.rebound so other daemons drop stale routing state.
  • Use Case: A user says "pin my CEO agent to my laptop instead of the k8s pod" — the orchestrator inspects the workspace bindings, posts a rebind with a reason, and reports how many tasks are still finishing on the old daemon.

Quick Start

Ask the orchestrator to resolve the contested binding for your agent by rebinding it to your preferred daemon, for example: "Pin agent u_agent_ceo to daemon-mac-studio-01 because I'm on my home network."

Frequently Asked Questions about claim-agent-ownership

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I resolve a contested agent binding between two daemons?

Inspect the workspace bindings via GET /api/im/workspaces/:workspaceId/agent-bindings, pick the target daemon, then POST to /api/im/agent-bindings/:agentImUserId/rebind with targetDaemonId and a reason. The server atomically flips ownership and returns the in-flight task count on the previous daemon.

How do I pin an agent to a specific daemon or machine?

Call the rebind endpoint with the target daemon's ID, kind, and a human-readable reason such as "user-explicit: pin to laptop". The binding is persisted with boundBy='user-explicit' and subsequent dispatches route to the chosen daemon.

What happens to in-flight tasks when an agent is rebound to another daemon?

In-flight tasks are not interrupted; they finish on the previous daemon while new dispatches route to the new owner immediately. The rebind response includes inFlightTaskCount so the orchestrator can wait for draining before declaring completion.

Why does the agent rebind request return a 409 error?

A 409 means the target daemon is stopped (its container has stoppedAt set). Re-read the workspace bindings to find a live alternative daemon and retry with that candidate instead.

When should I not use the agent rebind endpoint?

Do not rebind healthy single-daemon bindings, agents you lack permission for (returns 403), or for per-message routing decisions. For reversible per-dispatch routing, use metadata.daemonId overrides on individual dispatches instead.