initializdocs
DeveloperAgent SDK

Agent SDK

The initializ SDK for Claude Agent SDK agents — the governed loader that brings audit, policy enforcement, and platform identity to your image without code changes, and the optional @initializ/a2a-kit library for exposing typed skills over A2A.

Agents built on the Claude Agent SDK in your own repository run on the platform as governed claude-agents. The initializ SDK is what makes that work, and it is deliberately split into two pieces that solve two different problems. Keeping them apart is the key to understanding what you actually need to do — which is usually very little.

The two pieces

The governed loader — always present, never imported. Every governed claude-agent image carries the initializ loader. It wraps the Claude Agent SDK's query() to audit every model and tool call, applies runtime policy checks, carries the agent's platform identity, pins model traffic to the platform-managed gateway, attributes token usage, and serves and routes inbound traffic. You never import it in application code and never write the line that activates it — it reaches the image one of two ways:

  • Platform-built images: the platform's build bakes the loader in automatically. Nothing to do.
  • CI-built images (bring your own image): your CI wraps the application's unchanged image with a small governance wrapper Dockerfile — a copied /opt/initializ layer plus a NODE_OPTIONS import flag. Zero application-code changes; a vanilla agent that uses no initializ package at all still gets fully governed. See Build a governed image in CI.

Inbound authoring — optional, @initializ/a2a-kit. A zero-dependency library of types and two helpers (defineAgent, skill) that shape your code into the executor contract the loader consumes. It performs no injection and no governance itself — the already-present loader discovers your executor through a package.json pointer, serves the A2A Agent Card from your skills, and routes inbound tasks to your handlers under the same governance as query(). See Enable A2A on a claude-agent.

The two axes compose but never depend on each other:

QuestionAnswer
How does the loader get into the image?Platform build → automatic. Your own CI → the governance wrapper Dockerfile
How is the agent reached inbound?A2A (a2a.enabled: true in the deploy spec) — typed skills via a2a-kit, or the loader's built-in chat passthrough — or a plain http invoke route your own server serves

Which piece you need

You wantYou need
Govern an existing Claude Agent SDK service — audit, policy, managed model gateway — with no code changesThe CI governance wrapper only
Expose your agent's real capabilities to other agents and workflows as typed skillsThe wrapper plus an @initializ/a2a-kit executor
Keep serving your own webhook or trigger route instead of A2AThe wrapper plus the deploy spec's http block — no a2a-kit

With a2a.enabled: true and no executor of your own, the loader still serves A2A with a single generic chat skill that bridges each message to the governed query() — a2a-kit is only needed when you want tasks routed to your own typed handlers instead.

Inbound A2A authentication

A2A calls are bearer-authenticated by default: the caller presents a platform-issued token, the loader verifies it against the platform, and only callers from the agent's own workspace are accepted — an unreachable verifier or an unknown token fails closed. Authentication can be explicitly disabled with a2a.auth: none (for local development). The Agent Card advertises the bearer scheme so callers know to send a token. Details in CI-deployed agents.

Guides

On this page