twining-dispatch

Twining Dispatch — Subagent Coordination Protocol

When you dispatch subagents via the Agent tool, use this protocol to make every dispatch visible in the Twining coordination dashboard (Agents, Delegations, and Handoffs tabs).

Requires the full tool surface. twining_register, twining_delegate, twining_query, twining_decide, and the deprecated twining_handoff / twining_acknowledge exist only when the project sets tools.full_surface: true in .twining/config.yml. On a default install, dispatch is still worth recording — use twining_post with a need or status entry naming the subagent and its scope, and twining_record for decisions — but the Agents and Delegations dashboard tabs will stay empty, which is expected rather than a bug.

Subagents may not inherit Twining tools. A spawned subagent only has Twining tools if its agent definition declares no restrictive tools: allowlist and the MCP server reached that process. Tell each subagent to locate the tools with ToolSearch (query twining) and to report plainly if they are absent, rather than assuming its posts landed.

When to Invoke

• Before dispatching any subagent via the Agent tool
• When coordinating multiple parallel subagents
• When you want delegation and handoff history for traceability

Full Protocol (4 calls)

Pre-Dispatch (before Agent tool call)

1. Register the subagent

twining_register({
  agent_id: "descriptive-agent-id",    // e.g. "test-runner", "code-reviewer"
  capabilities: ["relevant", "caps"],   // what it can do
  role: "worker",                        // or "reviewer", "researcher", etc.
  description: "What this agent does"
})

2. Post a delegation

twining_delegate({
  summary: "What the subagent should accomplish",
  required_capabilities: ["relevant", "caps"],
  scope: "src/affected/area/",
  urgency: "normal",                     // "high", "normal", or "low"
  agent_id: "orchestrator"               // who is delegating
})