Layer 2: capability metadata for routing/teaming (deferred design)

[laulpogan]

Problem

Layer 1 (discovery + zero-paste pairing across sister sessions) tells you WHO is reachable. It does not tell you WHO IS GOOD FOR WHAT.

For agents to pick a teammate dynamically ("I need a Rust reviewer", "find an idle planner") they need structured capability metadata published on each peer's agent card.

Proposal (sketch, NOT yet scheduled)

Extend wire profile set and the agent-card schema with optional fields:

{
  "did": "...",
  "handle": "alpha",
  "profile": {
    "role": "reviewer",
    "stack": ["rust", "axum", "tokio"],
    "working_on": "wire/dual-slot",
    "availability": "idle",
    "expertise": ["protocol design", "tls"],
    "updated_at": "2026-05-18T..."
  }
}

New surfaces:

• wire profile set --role reviewer --stack rust,axum --availability idle
• wire profile get [<peer>]
• wire peers --role reviewer filters pinned peers by tag
• wire suggest "review my rust diff" — local-only lexical match against pinned peers' profiles; ranks by capability overlap and availability. Local-relay peers first.

Why this is deferred

Three open questions need real-usage data before committing:

1. Taxonomy fight: who picks the role vocabulary? "planner / executor / reviewer / explorer" is plausible but might not match how operators actually deploy claudes. Premature standardization will get fought.
2. Freshness clock: profiles rot fast — a claude flips from "working on X" to "working on Y" every conversation. Need a TTL or auto-derivation (from cwd basename + git branch?). Without freshness, profiles drift into lies within hours.
3. Auto vs operator-set: if the agent itself sets working_on, every prompt update churns the agent card. If only the operator sets it, it's stale by design. Hybrid (auto for working_on, operator for role/stack) needs a clean split.

Adjacent: in-prompt vs profile

For paired claudes in the same project, role is usually already in the prompt or system instructions ("you are the reviewer"). The profile is mainly useful for cross-project sister-session discovery, where two claudes were never briefed about each other.

That subset is small enough that the value of Layer 2 is uncertain. Worth building Layer 1 first and see whether anyone asks for filtering.

Status

Deferred — no implementation work scheduled. Tracked here so the design is captured. Will revisit when Layer 1 ships and we have usage data.

Related

• #list-local — Layer 1A
• #pair-all-local — Layer 1B