Skip to content

Business adapters and community recipes

A business adapter does not move an entire vendor backend into BailingHub. It creates a thin, explicit boundary on the source-system side: declare the operations an agent may use, verify Hub signatures, restore a trusted subject, and call the existing service layer for final authorization and business validation.

Form Where it lives Best fit
Business-side SDK Inside the business-system codebase Generate tool specs, verify calls, issue identity tickets, or call the Hub
Independent adapter A separate repository or business plugin A product has a stable extension point and the integration should be installed and upgraded independently
Community recipe Documentation, sample specs, and verification scripts Teams need a reference structure but must implement it for their own version and permission model

The business-side SDK is not the Agent Client SDK. The former supports declarations, verification, and identity establishment in the business backend. The latter supports browser authorization, connections, and tool calls from a local agent.

  1. Choose one result-verifiable read and one reversible write.
  2. Give each operation a stable operationId, parameter schema, and ACC governance declaration.
  3. Verify the signature, subject, tenant, resource ownership, and current business state in the business backend.
  4. Publish only the required tool specs to the Hub, then restrict them again at the route.
  5. Test success, unauthorized denial, duplicate requests, and approval recovery with fixed test accounts.
  6. State the adapter version, compatible business-system versions, and maintainer responsibility.

Community distributions, connectors, and recipes can be named, released, and maintained independently. Public discoverability is not an official quality warranty, security audit, or proof of customer adoption. General improvements can be contributed upstream while industry-specific logic remains in an independent project.