Supported Agents

Ktesio runs agents as adapter-backed processes: the built-in hermes native adapter targets the Hermes gateway, and any other agent integrates through a manifest adapter.toml (the manifest reference). This page records which agent versions the shipped adapters were validated against — an adapter's honesty is only as good as its last validation, because agent upstreams move fast.

Hermes (--kind hermes)

The hermes builtin is compiled into the engine and declares a FIXED launch — hermes gateway run --external-supervisor — so Ktesio supervises a foreground gateway process instead of the agent's own service manager. What the adapter declares:

• Config mapping: only the reserved memory.dir key → env HERMES_HOME (attaching a filesystem Memory Backing gives the gateway its per-instance home; with no backing attached the gateway receives NO HERMES_HOME and falls back to its own default home — see the command reference). The unified model key is a documented no-op for hermes.
• Capabilities: pause best-effort and interaction guaranteed on every OS; metering self-reported.
• PATH requirement: the launch's exec is the bare word hermes, resolved through the operator's PATH at start. Ktesio does not bundle, install, or pin the Hermes binary — you install it (per Hermes' own docs), keep it on the PATH of the environment kt runs in, and kt agent start resolves it like any other program. A start whose hermes cannot resolve fails with the engine's launch-failure diagnostic naming the executable.

Validation pin: the adapter's behavior was verified against Hermes at v0.20.5, commit 41447a6d7063b2772b0c2f26a5b22d9bd444fb43 (verified 2026-08-25). CI never launches the real gateway: the conformance passes run under the recorded hermes_shim PATH-sim sandbox (an isolated stand-in that re-execs a test helper), so the suite is deterministic and network-free — the real-binary validation is the pinned manual pass recorded above it.

opencode (paper-validated)

opencode has no builtin adapter: it integrates as a manifest adapter whose [lifecycle.start] points at its serve command, declaring interaction: http (the additive documentary channel) with XDG_DATA_HOME + XDG_CONFIG_HOME as its isolation levers. Its contract behavior was validated on paper only — a primary-source characterization of the v1.18.27 sources plus a conformance mapping that shaped the Adapter Contract v1 freeze. Nothing in this repository has launched opencode; treat its adapter shape as a starting point and re-validate before relying on it.

The re-validation duty

Both upstreams move fast (opencode ships multiple releases per week; Hermes merges near-daily). Every version pin on this page is a stale-the-moment-it-is-written snapshot by design: the pins make the validation auditable, not permanent. Whoever touches an adapter — or ships a release that leans on one — re-validates against the pinned release before trusting agent-specific behavior, and moves the pin forward with fresh evidence. The contract's honor-system duties (the {env:VAR} render guarantee, self-update pinning, config-layer disclosure — see the Adapter Contract) are exactly the parts re-validation must cover, because no automated section can.

Troubleshooting: hermes won't launch

Launch failures (hermes: command not found, immediate failed, or behavior drift after a Hermes upgrade) are diagnosed in the canonical troubleshooting section — kept in one place so the two pages cannot drift. This page owns the validation pins and the re-validation duty; that page owns the failure surfaces.