Company Runtime
03 · Official adapters

Runtime Adapters

Boundary translators that implement protocol capabilities on concrete systems — model APIs, team chat and issue trackers — built with the Runtime SDK.

How to use itView on GitHub
At a glancePublic

github.com/Company-Runtime/runtime-adapters

Adapters
5 packages
Built with
@runtime-protocol/sdk
Verified by
Provider harness PC-001–PC-010
Runtime
Node.js ≥ 22.18
Maturity
Experimental
License
Apache-2.0
What it is

Official adapters.

An adapter sits between runtime semantics and a vendor API, an MCP server or a local system. Callers never name an adapter: they request an intent — communication.send, work.create — and the runtime's resolver selects an eligible provider deterministically.

Swapping Slack for another chat system, GitHub for GitLab or one model vendor for another changes configuration, not callers. Every adapter here runs the SDK provider harness against a simulated vendor API, and a substitution test runs the same intents through interchangeable adapters.

Install one to give your runtime a real system to act on, or read them as the template for an adapter of your own — which does not have to live here.

Swap without touching callers
  1. OpenAI ↔ Anthropic
  2. Slack ↔ another chat
  3. GitHub ↔ GitLab
  4. REST ↔ MCP
The adapters

Five systems, three intents.

Each adapter's README lists its profiles, traits, credentials, evidence and failure mapping.

  • adapter-openai

    ai/openai — reasoning.generate and reasoning.classify on any OpenAI-compatible Chat Completions endpoint. The operator chooses the model; callers never do.

  • adapter-anthropic

    ai/anthropic — reasoning.generate and reasoning.classify on the Messages API, with structured answers through a forced tool call.

  • adapter-slack

    communication/slack — communication.send with the chat profile. Reconciles uncertain deliveries from message metadata.

  • adapter-github

    engineering/github — work.create, work.assign and work.complete on issues. Reconciles from a hidden idempotency marker and issue state.

  • adapter-gitlab

    engineering/gitlab — the same three work capabilities on gitlab.com or self-managed GitLab issues.

How to use it

5 steps, from zero to running.

Commands and code come from the repository's own README and examples. Replace <commit> with the commit you pin.

  1. 01

    Install the SDK and an adapter

    Until the packages are published, install both from Git at a commit — the adapter through its directory — and allow their build scripts.

    terminal · package.json
    pnpm add "github:Company-Runtime/runtime-sdk#<commit>" \
  "github:Company-Runtime/runtime-adapters#<commit>&path:/communication/slack"

// package.json
{
  "pnpm": {
    "onlyBuiltDependencies": [
      "@runtime-protocol/sdk",
      "@runtime-protocol/adapter-slack"
    ]
  }
}
  2. 02

    Register it as a provider

    Configuration maps identities to vendor IDs; unmapped identities are refused, never guessed. The token stays in RUNTIME_SECRET_ORGANIZATION_PROVIDERS_SLACK; bindings hold only references.

    runtime.ts
    import {
  createRuntime,
  EnvCredentialBroker,
  GrantAuthority,
} from "@runtime-protocol/sdk";
import { createSlackProvider } from "@runtime-protocol/adapter-slack";

const runtime = createRuntime({
  providers: [
    createSlackProvider({
      conversations: { "identity://team/support": "C0123456789" },
    }),
  ],
  authority: new GrantAuthority([
    {
      id: "support",
      authority: "authority://company/support-manager",
      subjects: ["identity://agent/support-agent"],
      capabilities: ["communication.send"],
    },
  ]),
  credentials: {
    bindings: [
      { provider: "slack", ref: "secret://organization/providers/slack" },
    ],
    broker: new EnvCredentialBroker(),
  },
});
  3. 03

    Request the intent

    The caller asks for communication.send; it never says Slack. Replace the provider with another chat adapter and this call does not change.

    runtime.ts
    await runtime.execute({
  capability: "communication.send",
  profile: "chat",
  actor: "identity://agent/support-agent",
  input: {
    recipients: ["identity://team/support"],
    content: "Version 42 is live.",
  },
});
  4. 04

    Run it where it fits

    In process, as above; behind the http/0.1 provider API in a sidecar or container (createProviderHttpHandler from @runtime-protocol/sdk/http); or as tools of an MCP server. The container form is what Company Runtime's connector marketplace runs: each organization installs it separately, pinned by image digest.

  5. 05

    Build your own adapter

    Check that the capabilities already exist in the protocol registry — an adapter never invents vocabulary. Build with defineProvider, test against a simulated API with the provider harness, and publish it in your own repository, e.g. acme/runtime-erp-adapter. Shipped as a container image, the same adapter can run in Company Runtime's connector marketplace without a change to Company Runtime.

    terminal
    git clone https://github.com/Company-Runtime/runtime-adapters
cd runtime-adapters
pnpm install     # installs the pinned SDK and builds every package
pnpm run ci      # format, types, build, tests — no test calls a real vendor
The five rules

What every adapter must do to be admitted.

They apply to adapters here and anywhere else, and are enforced by tests.

  • 01

    Handle secrets transparently

    Consume only CredentialRefs, materialized at dispatch through ctx.credential(). Never store, log, hard-code or return a key.

  • 02

    Prove, not assert

    Return evidence for every claim: a provider_receipt for what the vendor answered, a state_observation for state read back.

  • 03

    Be honest about uncertainty

    Never sent is provider_unavailable; refused is failed; a timeout or server error after sending is unknown.

  • 04

    Respect the schemas

    Input is validated against the capability input schema before any call; output matches the output schema exactly.

  • 05

    Keep the core pure

    Proprietary behaviour goes under vendor.<vendor>.* or community.<author>.*, never into core identifiers.

Good to know
  • Mutating capabilities declare idempotency or implement reconciliation, so an unknown outcome is settled without repeating the effect.
  • Absence of a change counts as a proven failure only after a settle window past the deadline (settleAfterMs, five minutes by default).
  • Official adapters are few on purpose. Anyone may maintain one elsewhere, as long as it implements the protocol and passes the provider requirements.
Next guideRuntime ProtocolSource of truthAll repositories