Call Orka Agents through A2A.
Orka Gateway A2A connects an A2A client to an
Orka Agent through Orka's generic gateway.
Send a text message, let Orka run the Task, then read the result with GetTask.
The adapter runs separately from the controller and uses Orka's durable gateway
ledger — no second task queue, database, or execution engine.
official A2A client → TLS adapter → Orka gateway event → real Orka Task
↑ GetTask ← durable gateway delivery ← result
Important
Orka Gateway A2A is experimental and under active development. APIs and behavior may change without notice between releases, and it is not yet recommended for production use. It implements a text-only A2A subset, not full protocol conformance. Feedback, bug reports, and feature ideas are welcome — please open an issue.
Note
The organization and repositories are intended to be donated to a community-governed foundation at the appropriate time. Until then, the project is governed by Microsoft policy, and external contributors are required to sign the Microsoft Contributor License Agreement (CLA).
- Official A2A SDK — Agent Card discovery, JSON-RPC, text messages, and a small Go client using
a2a-go/v2v2.5.0. - Orka-owned execution — Tasks, retries, Sessions, retention, and cleanup stay in Orka.
- Retry-safe requests — Stable message IDs deduplicate admission; Task IDs fence the original admission across restarts and retention expiry.
- Pull results —
GetTaskreads owned, correlated final/error deliveries from the durable ledger. - Explicit trust boundary — TLS and four separate file-backed credentials; one configured caller domain per deployment, not per-user or multi-tenant authorization.
Use Go 1.25 or newer. From the repository root:
make test
make buildThis builds bin/orka-gateway-a2a and bin/a2a-client. Tests use an HTTP fixture
at the Orka boundary; no cluster, credentials, or model service is needed.
You need a working Agent, the gateway resources, and access to Orka's operator API. Native Agents without a runtime are supported on upstream Orka builds containing merged PRs #564 and #565; runtime-backed Agents keep their existing path. See Compatibility for the tested revisions and merged-code live proof, rather than assuming a published release includes them.
Follow Getting started to review
config.example.json, provision the four credential files
and TLS certificate/key, and set up the route. The example manifests are wiring,
not a complete cluster installation. With those files available at the paths in
your non-secret config:
./bin/orka-gateway-a2a -config /path/to/non-secret-config.jsonFor a container, build locally and mount the files at runtime. There is no published adapter image or release install command here.
Use your adapter's HTTPS origin and the external caller token file, not a
Gateway or operator token. For a private CA, add -ca-file /path/to/ca.crt.
./bin/a2a-client -url https://agent.example.com \
-token-file /path/to/client-token -message-id example-question-1 \
-text 'What is 17 times 23?'The client waits for a result by default and prints the returned Task as JSON. For nonblocking calls, polling, and same-Session messages, see Using the client. Retry with the identical message ID and payload. A timeout does not cancel work. Everyone sharing the caller token can read every Task in its configured domain.
| Getting started | Credentials, RBAC, TLS, container mounts, and client commands |
| Protocol | Supported calls, identity, ownership, results, callbacks, and retention |
| Compatibility | SDK and Orka versions, native-AI prerequisites, and verification limits |
| Orka Gateway API | Upstream ingress, delivery, and operator APIs |
| Operating Orka gateways | Upstream durability, TLS, recovery, and cleanup |
See CONTRIBUTING.md for the CLA, commit sign-off, and build/test commands. Please follow the Code of Conduct and report vulnerabilities through SECURITY.md, not public issues.
MIT, copyright Microsoft Corporation.