Adopt relaycast's Swift SDK in relay; retire the duplicate `AgentRelaySDK` participant client

[willwashburn]

Problem

packages/sdk-swift in this repo ships two products:

• AgentRelayBrokerSDK — broker orchestration (legitimate, relay-specific).
• AgentRelaySDK — a hand-rolled reimplementation of the relaycast participant client (its own HostedHTTP, agent registration, channel/DM send, event transport, action handlers).

AgentRelaySDK duplicates the canonical relaycast Swift SDK, which already lives in AgentWorkforce/relaycast → packages/sdk-swift (product Relaycast) and mirrors the TS @relaycast/sdk surface. The duplication is exactly what the TS side avoids — relay depends on @relaycast/sdk rather than reimplementing it.

This surfaced from #1150 (Swift threads parity): the relaycast Swift SDK already has AgentClient.thread(_:options:) -> ThreadResponse and reply(_:text:options:), so the parity gap is already closed upstream. Extending relay's AgentRelaySDK instead (PR #1191) grows the wrong layer, so that PR was closed.

Goal

Have agent-relay consume relaycast's official Swift SDK for the participant surface and remove the duplicate AgentRelaySDK, keeping only AgentRelayBrokerSDK as relay-specific.

Blockers / open questions

1. Distribution. relaycast's Swift SDK is currently consumable only via a local path dependency (.package(path: "../relaycast/packages/sdk-swift")) — there is no git URL, version tag, or standalone/mirrored Swift package repo. relay is a separate repository, so it can't add it as a normal SwiftPM dependency the way it consumes @relaycast/sdk on the TS side. Decide how relay should resolve it:
   • publish/mirror relaycast's Swift SDK as a standalone, versioned Swift package, or
   • depend via a sibling-checkout path dependency, or
   • vendor it.
2. Migration surface. Map current AgentRelaySDK consumers onto the relaycast SDK's AgentClient API (registration/registerOrRotate, channel/DM send, events/inboundMessages streams, registerAction) and provide thin shims or update call sites.
3. Naming/compat. AgentRelayClient is currently a public typealias for the participant client; preserve or deprecate intentionally.

Acceptance

• relay's participant Swift surface is backed by relaycast's Relaycast SDK (no parallel HTTP/transport reimplementation).
• The duplicate AgentRelaySDK sources are removed; AgentRelayBrokerSDK remains.
• Threads/reactions/read-receipts/etc. parity comes for free from the upstream SDK.

Context: PR #1191 (closed), issue #1150.

[willwashburn]

Closing as resolved-by-redesign. The core concern here — relay maintaining a hand-rolled duplicate of the relaycast participant client — is gone: PR #1259 adopted relaycast's official Swift SDK (dependency at 6.0.5) and all transport/registration/event handling now delegates to Relaycast.RelayCast through HostedParticipantCore.

The literal acceptance criterion ("remove AgentRelaySDK, keep only AgentRelayBrokerSDK") was consciously inverted during that PR: retirement was attempted, then reverted in favor of rebuilding AgentRelaySDK as a rich relay-owned facade over the relaycast engine — mirroring how @agent-relay/sdk wraps relaycast on the TypeScript side. That rebuild also delivered the parity surfaces tracked in #1150–#1158 (threads, inbox, deliveries, nodes, triggers, workspace, agents, channels).

So: duplication eliminated, official SDK adopted, facade deliberately kept. Closing; if fully retiring the facade becomes desirable later, that's a new decision against the current architecture.

---

Generated by Claude Code