[Protocol] Publish an API + node-protocol spec (OpenAPI 3.1 + NODE_PROTOCOL.md) so community SDKs (Rust, …) can be built against it

[pocesar]

Summary

Adding a Rust SDK with feature parity to the Go SDK would be great. Go is great for efficient code that would otherwise fail hard on Python SDK but not everyone is comfortable with Goland or to understand AI generated code for correctness.
Async first, tokio-powered on top of axum, configuration using macros and/or traits, handles concurrency and parallelism using the sync primitives (mpsc, oneshot, non-blocking only).

Needless to say, Rust is the first choice when you need raw power with amazing memory management without a GC and handles heavy I/O with grace.

Proposed solution

Alternatives considered

Additional context

[AbirAbbas]

Triage

Classification: feature ✓
Suggested labels: enhancement

Likely affected files:
(none identified)

---

Triage by github-buddy

[AbirAbbas]

Not committing to a maintained first-party Rust SDK — three SDKs already stretch the release process. What would actually unblock a community Rust SDK (or any other language) is the thing that doesn't exist yet: a protocol spec. Concretely, an OpenAPI 3.1 document generated from the existing apicatalog registry (85 endpoints, already served live at GET /api/v1/agentic/discover) plus a hand-written docs/api/NODE_PROTOCOL.md for the half the catalog can't describe — the node-side contract the control plane dispatches to (POST {BaseURL}/reasoners/{name}, /skills/{name}, GET /status, POST /shutdown), registration and heartbeat/lease, the status-callback and workflow-event payloads, and the header conventions for run/parent/session ids.

@santoshkumarradha OK to retitle this as the protocol-spec tracking issue and label it roadmap? If a Rust SDK does happen, I'd rather it be built against that spec than by reading Go.

[santoshkumarradha]

@AbirAbbas I agree, and can you update the issue labels as well and we can latter add it to sdk enhancement milestone