Examples¶

The examples live under examples/ and are meant to be copied.

Echo worker¶

Both examples:

Define a typed payload.
Define a typed output.
Subclass the language worker base.
Supply shallow input/output schemas.
Subscribe through the SDK in-memory transport.
Publish a TaskMessage.
Print the resulting TaskResult.

Run them:

dotnet run --project examples/dotnet/EchoWorker/EchoWorker.csproj
swift run --package-path examples/swift/echo-worker EchoWorker

Moving from example to live runtime¶

Replace the in-memory transport with a broker-backed transport:

Example mode	Live runtime mode
Build a `TaskMessage` in `main`	Receive `TaskMessage` from the Heddle router
Use `InMemoryHeddleTransport` / `InMemoryTransport`	Use a shared broker transport, usually NATS. The shipped .NET NATS adapter is live-runtime ready; the shipped Swift NATS adapter builds the real binding on macOS.
Call `RunAsync(...)` / `run(transport:)`	Keep the same worker run-loop call
Print the result from a local subscriber	Publish to `heddle.results.{parent_task_id}`

The worker subclass does not change. See NATS Transports for the shipped adapter packages.

Worker config in Heddle¶

Foreign workers still need a Heddle worker config so the router knows where to send tasks:

name: echo
worker_kind: processor
default_model_tier: local

input_schema:
  type: object
  required: [text]
  properties:
    text: {type: string}

output_schema:
  type: object
  required: [text, length]
  properties:
    text: {type: string}
    length: {type: integer}

implementation:
  runtime: swift
  entry: ./bin/EchoWorker

The implementation block is informational today. Heddle's router cares about the worker name, kind, tier, and schemas.