RedKey Coordination API Platform

Build RedKey as the verified coordination API for parallel agent networks.

The first visible wedge is OpenClaw, but the product is larger than an OpenClaw plugin. The core product is an API that gives any agent framework a shared HCS-backed queue, role-based claim eligibility, durable workflow events, missed-claim awareness, and ledger receipts.

The public line:

``text RedKey gives parallel agents a shared verified queue. ``

The OpenClaw line:

``text OpenClaw gives you agents. RedKey gives them a shared queue. ``

Start with a hosted RedKey Coordination API, not only a GitHub plugin.

The GitHub repo should show how OpenClaw plugs into the API. It should provide the adapter, examples, and developer trust. The hosted RedKey product should own signup, OAuth, API keys, metering, HBAR funding, HCS-backed coordination, and receipts.

This creates a platform shape:

``text RedKey Coordination API | |-- TypeScript SDK |-- OpenClaw adapter |-- Bezel recipe |-- future LangGraph adapter |-- future CrewAI adapter |-- future custom agent clients ``

Real coordination requires HCS.

HCS is not an optional audit trail. It is the claim and queue mechanism. The abstraction is not about making HCS optional. The abstraction is about making HCS invisible to most developers.

Public primitives:

• workspace
• agent
• A2A Agent Card
• role
• queue
• task
• claim
• lease
• workflow
• event
• receipt
• ledger replay

Internal primitives:

• HCS topic
• HCS sequence number
• HCS consensus timestamp
• Hedera transaction ID
• operator account
• topic routing
• mirror-node verification
• HBAR funding

The public API should not expose Hedera SDK usage, topic management, operator keys, or message construction.

``text Public clients | |-- OpenClaw adapter |-- TypeScript SDK |-- REST API | RedKey public API | |-- auth and workspace control plane |-- A2A Agent Card registry |-- role and eligibility model |-- coordination queue API |-- ledger and receipt API |-- usage and billing API | RedKey internal execution | |-- HCS writer |-- HCS reader/projector |-- claim reducer |-- workflow reducer |-- metering service |-- billing reconciliation ``

RedKey should support two execution modes.

The simplest workflow is:

``text put a task on a role eligible agent claims it agent does it agent completes it ``

This path should not require a workflow definition or plan.json.

Example:

``http POST /queues/:queueId/tasks ``

``json { "title": "Research Piers Gorman", "requiredRoles": ["role_researcher"], "input": { "guestName": "Piers Gorman", "sourceHint": "TreviPay podcast planning doc" } } ``

This creates one available task. Any active agent with role_researcher can claim it. The queue/HCS layer resolves the winning claim. The task completes or fails. No workflow engine needs to open follow-on tasks.

Multi-step work should require a structured plan.json.

The plan is the contract between the user, the workflow reducer, and the agents. It prevents vague "do this project" prompts from turning into unmanaged agent activity.

The plan must break work into clear tasks with:

• stable task IDs
• required roles
• required capabilities when needed
• dependencies
• expected inputs
• expected outputs
• completion criteria
• retry policy
• human approval gates when needed
• artifact expectations

The workflow reducer reads ordered events and the plan, then opens the next eligible tasks.

``text HCS ordered events + plan.json -> workflow reducer -> materialized workflow state -> available tasks ``

plan.json is required for multi-step workflows.

Minimum shape:

```json { "version": "1.0", "name": "podcast-production", "description": "Prepare a podcast episode from guest intake through host-approved script.", "roles": { "producer": { "description": "Owns intake, structure, and final packaging." }, "researcher": { "description": "Finds and summarizes relevant background." }, "writer": { "description": "Drafts host-ready copy." }, "reviewer": { "description": "Checks quality, accuracy, and fit." } }, "tasks": [ { "id": "guest_intake", "title": "Summarize guest and topic brief", "role": "producer", "dependsOn": [], "input": { "sources": ["planning_doc"] }, "outputs": ["guest_brief"], "completionCriteria": [ "Guest background summarized", "Target episode angle identified", "Known constraints captured" ] }, { "id": "guest_research", "title": "Research guest and market context", "role": "researcher", "dependsOn": ["guest_intake"], "requiredCapabilities": ["web_search", "source_review"], "outputs": ["research_packet"], "completionCriteria": [

RedKey should validate plans before starting a workflow.

Required checks:

• every task has a stable unique ID
• every task has exactly one primary role
• every referenced role exists
• dependencies reference valid task IDs
• dependency graph has no cycles
• every task has completion criteria
• outputs are named
• approval gates are explicit
• retry policy is explicit
• max parallelism is explicit

Best-practice warnings:

• task is too broad
• task has no concrete output
• task depends on too many upstream tasks
• task has unclear completion criteria
• plan has too much serial work and not enough parallelizable work
• role names are vague
• task asks one agent to both produce and review the same artifact

Validation endpoint:

``http POST /workflow-definitions/validate ``

Start workflow from plan:

Expose the smallest set of surfaces required to run both simple role tasks and planned workflows.

Handles signup, OAuth, API keys, workspaces, and usage visibility.

Endpoints:

``http POST /oauth/token GET /workspaces POST /workspaces GET /usage GET /billing/credits ``

Hosted plans use RedKey-managed HBAR funding. Enterprise plans may use customer-owned Hedera accounts and topics behind a managed setup flow.

Agents should register through A2A Agent Cards.

Primary endpoint:

``http POST /agents/register-card ``

Supported payloads:

``json { "workspaceId": "wk_123", "agentCardUrl": "https://agent.example.com/.well-known/agent.json" } ``

or:

``json { "workspaceId": "wk_123", "agentCard": { "name": "Research Agent", "description": "Finds and summarizes source material", "url": "https://agent.example.com/a2a", "version": "1.0.0", "skills": [], "capabilities": {} } } ``

RedKey ingests the Agent Card and normalizes: