SDKs

The ctxmesh SDKs are optional. Everything the platform offers an agent — memory, tools, the model gateway, feedback, knowledge, deep tracing, on-behalf-of credentials — is a language-agnostic localhost plane served by the launcher. The SDK is typed sugar over that plane, not a gateway to it. A framework agent in any language is fully governed and deeply traced with zero ctxmesh imports.

So the real question is: when do you want the SDK?

When you need an SDK

You’re writing a no-framework agent loop. A hand-rolled loop won’t be auto-instrumented, so its internal steps won’t show up in the trace tree. The SDK’s step-tracing helpers let your loop emit the same step → tool → model spans an auto-instrumented framework produces. This is the single most common reason to reach for it — see Custom agent loop.
You want typed ergonomics over the localhost plane: client.memory, client.tools, client.model, client.knowledge, client.feedback — instead of hand-writing HTTP to localhost.
You want the managed loop. run_managed_loop (Python) / runManagedLoop (TypeScript) is the stock, bounded, traced tool-calling loop — system prompt in, tools from the manifest, max_steps guard, structured output — so you don’t reimplement the ReAct pattern.
You need in-loop platform features like pause_for_approval (human-in-the-loop) or the synthetic delegate_to / handoff_to tools for multi-agent work.
You’re driving runs from outside a pod — a client, a test, a CI job — with the RunsClient.

When you don’t

A framework agent (LangChain, LlamaIndex, and friends) is already deeply traced and fully governed by the launcher. Import the SDK only if you additionally want its typed clients or the managed loop.
Any language with no ctxmesh SDK still gets the full contract — the plane is plain HTTP. You lose the typed clients and the step-tracing helpers, nothing else. Six languages now have one; the rest lose only the sugar.

The six packages

Every package is named ctxmesh, and they come at two tiers. The tier tells you what you get:

Language	Install from	Tier
Python	PyPI	authoring
TypeScript	npm	authoring
Go	pkg.go.dev	plane client
Rust	crates.io	plane client
Ruby	RubyGems	plane client
Java	Maven Central	plane client

Plane client — every launcher route reachable with typed clients, typed errors, config read from the injected environment, and offline testing stubs. This is the floor every SDK meets.

Authoring — the plane client plus the managed agent loop, tool dispatch, the model client, serve, step tracing and record/replay. Python and TypeScript only; adding a language here is a separate decision per language.

So a Rust or Java agent reaches memory, knowledge, skills, feedback, delegation and handoff through typed calls, and writes its own loop. A Python or TypeScript agent can hand the loop to the SDK.

Python — bundled in the base-python agent image. See Python SDK.
TypeScript — bundled in the base-node agent image, with async parity across the surface. See TypeScript SDK.
Go, Rust, Ruby, Java — each SDK’s README carries its install snippet and full surface.

The shape of an SDK agent

Every SDK entry point starts by constructing a Client from the launcher-injected environment — it never takes credentials, because there are none to take:

from ctxmesh import agent

client = agent.from_env()          # reads MODEL_GATEWAY_URL, MEMORY_PORT, ... from the launcher
answer = client.model.chat(model="my-route", messages=[{"role": "user", "content": "hi"}]).text

From there you either serve a handler (serve), run the managed loop, or write your own traced loop. The per-language pages cover each.