Adapter guide

Build your own adapter

Your team may have a system that an agent should work with: a database, API, workflow, local tool, or internal service. An adapter lets that system participate in the boundary. The agent can propose work, the Core decides what may continue, and your adapter only carries out work that has already been admitted.

Implementation guide / preview path

Build your own adapter

Three small pieces. One admitted-only path.

submit-intent.ts
policy.go
worker.ts

The 2-minute proof

This is the smallest real shape:

client
  -> POST /v0/intents

Adapter Host
  -> POST /state
  -> POST /policy

worker
  -> POST /v0/adapter/work-orders/claims
  -> apply target-side effect
  -> POST /v0/adapter/outcomes

If your system can:

  • read current target state,
  • decide admitted versus blocked for one bounded action,
  • and perform one bounded effect after claim,

then you can build an adapter.

What you do not need

You do not need to:

  • import Core packages
  • import Adapter Host packages
  • reimplement decision validation
  • invent WorkOrders
  • invent leases
  • build a browser-facing ingress API

The host and Core stay inside the bundle. Your code stays outside the bundle and owns only target-specific behavior.

Three example shapes

Adapter shape/state reads/policy decidesworker does
Repository adapterbranch, file, or pull-request statewhether one repository action is allowed nowopen or update one pull request
Ticket adapterticket workflow statewhether one transition is allowed nowmove one ticket or add one note
Impact Room-style reference adapterroom or turn statewhether one room-side effect is admissible nowmaterialize one room-side effect after claim

Impact Room is a useful reference shape because it is concrete and easy to picture. It is not part of this shipped bundle. The bundle includes the generic minimal fixture, not a room-specific adapter.

The fastest path to your first adapter

  • Pick one narrow target and one narrow operation.
  • Implement POST /state for that target.
  • Implement POST /policy with one admitted path and one blocked path.
  • Start a worker that claims only for your target_adapter.
  • Submit one intent and watch the full flow complete.

That is enough to prove you can build your own adapter.

What these pages do

This section is not only orientation. It is the build-your-own path:

What these pages do not replace

Once you need exact field names and wire shapes, move into the main docs:

The main framing

The point of "build your own adapter" is not to fork the system. It is to keep your target-specific logic in your own code while still requiring the explicit path:

intent -> state -> policy candidate -> Core validation -> claim -> effect -> outcome

That is why this bundle is useful even without public Core source. The adapter contract is HTTP. Your implementation can be Go, TypeScript, Python, Rust, or anything else that can speak the protocol.