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: If your system can: then you can build an adapter.

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

What you do not need

You do not need to: The host and Core stay inside the bundle. Your code stays outside the bundle and owns only target-specific behavior.

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

Three example shapes

ImpactRoom 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

That is enough to prove you can build your own 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.

What these pages do

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

  • Why build your own adapter
  • What you implement
  • Host, Core, and adapter split
  • A good first adapter
  • Where to go next

What these pages do not replace

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

  • 03 - API Reference
  • 06 - External Adapter Protocol
  • 07 - Build Your Own Adapter
  • 08 - Minimal Target Adapter
  • 01 - StateProvider
  • 02 - PolicyBoundary
  • 03 - WorkOrders, Claims, and Outcomes

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: 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.