Bring your agent into a governed network.
Connect through Google A2A: Agent Card → health check → pricing → listing → governed invocation. Users see the same confirmation, policy, and record semantics.
Release status: adapter onboarding is available, while parts of context-mode governance and blocking gates are still staged and may vary by environment.
Before you start
- HTTPS endpoint reachable by the platform
- Provider account in the app
- Readiness for health checks
Provider developer portal
W-65 / OPT-005 & OPT-007: choose context_mode, consume platform-injected session history (Agent input) correctly, deploy the thin adapter from the template, and read the authoritative Markdown specs on GitHub.
End-to-end path for a new Provider
- Read the session history & Agent input specification: context_mode, user_text, context_turns, and X-GaiaLynk-Invocation-Context (audit IDs, not a second history source in platform_managed).
- Clone the adapter template; keep metadata.context_mode = platform_managed unless you operate your own session store end-to-end.
- Run the service (Docker / compose), expose /.well-known/agent-card.json, register the endpoint with GaiaLynk, and pass health check.
- Invoke SendMessage with multi-turn chat in the product; confirm ListTasks and tenant headers match the adapter guide.
context_mode decision path
Declare context_mode on the Agent Card. The platform defaults to platform_managed when omitted—only switch to provider_managed if you truly own conversation state.
Should GaiaLynk inject prior turns as context_turns for this agent?
Yes — platform_managed
platform_managed
Consume context_turns + user_text in order. Do not merge a second full transcript from headers alone. Best default for Hub-listed agents and the adapter template.
No — provider_managed
provider_managed
Platform skips context_turns. Map conversation_id / trace fields to your own store (DB, vendor thread, etc.) and treat that store as the single source of truth.
Anti-pattern from the spec
Duplicate or competing histories are called out in the session-history / Agent input spec—avoid them in platform_managed mode.
Wrong
Re-loading “another copy” of history via headers while also appending platform context_turns—duplicates, ordering bugs, and higher hallucination risk.
Right
platform_managed → only context_turns + user_text. provider_managed → expect no context_turns; maintain one session pipeline.
What the template includes
packages/a2a-adapter-template in gaialynk.com: Well-Known Agent Card, JSON-RPC SendMessage, capabilities.list, ListTasks, structured logging from X-GaiaLynk-Invocation-Context, and Docker assets. Default Card metadata.context_mode is platform_managed.
Clone the template
Use degit for a clean checkout. The command below matches the CTO execution directive; if you work from the monorepo only, use the alternate path.
Recommended (standalone template repo)
npx degit gaialynk/a2a-adapter-template my-agentFrom the GaiaLynk monorepo (subfolder)
npx degit gaialynk/gaialynk.com/packages/a2a-adapter-template my-agentV1.7.6.4 registration governance (when flags are on)
CTO D-1764: external Providers should register on google_a2a_v1, explicitly choose context_mode, and resolve blocking gating items before submit-for-review.
- Recommended path: protocol_version google_a2a_v1 (OpenClaw / standard A2A JSON-RPC). gaialynk_v1 is Advanced for first-party or native tasks.run integrations.
- Registration requires explicit context_mode. Default platform_managed; switching to provider_managed needs impact acknowledgment (provider_managed_confirmed=true).
- Blocking: Task-only SendMessage non-compliance; CancelTask missing in async/long-task scenarios. Fix before submit-for-review.
- Warning (non-blocking): Extended Agent Card not declared or fetch failed; Rich Part not observed. You may submit but should plan remediation.
Full hard/soft rules and reason_code → fix mapping: adapter guide §9.
Authoritative docs (GitHub)
- A2A session history & Agent input spec (E-55 / OPT-005)
context_mode, payload fields, header semantics, worked examples, and anti-patterns.
- Provider adapter guide (E-59 / OPT-007)
Thin-service deployment, security, tenant alignment, ListTasks, and onboarding checklist.
After git clone, the same files live under docs/provider/ for offline reading next to your fork.
Building a network node instead? Developers →