MCP hosts, Dify, n8n, agent skills, local agents, and custom services should not each rebuild job state, approvals, audit records, and traces. Independent adapters consume the public BailingHub Client API; BailingHub governs reach and execution, while the business system retains final authority.
Statuses describe public availability or review progress only. They do not imply certification, recommendation, partnership, or security endorsement by an ecosystem platform.
For custom agents, backend services, and any runtime that can make HTTP requests. Submit governed jobs, query state, or wait within a fixed bound without adopting a specific agent platform first.
Submit BailingHub governed jobs and read their state from a Dify workflow or agent. The plugin is listed in Dify Marketplace, providing a searchable and installable upstream entry point.
For agent workspaces that import skills or execute them on demand. The public skill submits jobs, checks status, and waits for up to 60 seconds while the operator retains the BailingHub URL, fixed route, and route-scoped Client Token.
Published to n8n Cloud as a Verified Community Node and available by searching for BailingHub from the canvas. It submits jobs, checks status, waits within a fixed bound, and returns public trace, approval, and audit state. Self-hosted instances may need Verified Community Nodes enabled and a restart.
Let a stdio-capable MCP host submit business actions to a self-hosted BailingHub deployment. Each server process is fixed to one operator-configured route; routes, credentials, acting subjects, approval state, and callback destinations are not exposed as model-controlled arguments.
Let a local or remote OpenClaw instance become an outbound BailingHub executor. The skill is public on ClawHub and can be searched, inspected, and installed directly.
A first integration only needs to prove that one business request receives a stable job identity, enters the governed path, and ends in a traceable terminal state. A successful install, health check, or console view does not prove that loop.
Start: run the Docker Demo, then call POST /run with a dedicated Client Token, retain the returned job_id, and query that same job.
Pass: the job reaches an explainable terminal state. A bounded-wait timeout leads to another query, not a duplicate business action.
Start: install the Marketplace plugin, configure the BailingHub URL and a dedicated Client Token, then run submit_governed_job → wait_for_job against a no-side-effect route.
Pass: Dify receives a stable job_id and terminal state without holding BailingHub administrator or business-system credentials.
Start: obtain the public skill from SkillHub, configure the BailingHub URL, fixed route, and dedicated Client Token through the platform's secret facility, then run a no-side-effect job.
Pass: the same job_id is submitted, queried, or waited on within a fixed bound while the model cannot supply or override the route, token, or governance state.
Start: install n8n-nodes-bailinghub from Community Nodes, create a dedicated credential, and connect Submit Governed Job → Wait for Job.
Pass: the wait node polls the same job and returns its terminal state without resubmitting on timeout. See the installation guide.
Start: launch npx -y bailinghub-mcp-server from an MCP host, with the BailingHub URL, a dedicated Client Token, and one fixed route configured by the operator.
Pass: the host can submit, inspect, and wait on the same governed job while the model cannot change the route, acting subject, approval state, or BailingHub credentials. See the quick start.
Start: run clawhub install bailinghub/bailinghub-executor, review the installation contract, and configure only a target-scoped executor token.
Pass: the executor uses outbound connectivity for heartbeat, claim, and result delivery, opens no inbound port, and does not pass BailingHub credentials to the task agent. See the ClawHub listing.
Keep each platform's orchestration and interaction model.
Translate platform events into the public API contract.
Jobs, approvals, execution, audit, and traces.
Identity, permissions, business validation, and data isolation.
io.github.bailinghub/bailinghub-governance is listed as an independent stdio server in MCP Registry and as a local-only service in ModelScope's MCP directory. It sends MCP tool calls into the BailingHub governance path without making MCP, the model, or BailingHub the final business authorization layer. Directory listings provide discovery and installation paths, not certification, recommendation, a security endorsement, or end-to-end validation.
bailinghub-governed-actions is publicly listed as an independent, on-demand Client API skill on SkillHub. It reuses the same public Client API, does not enter ACC Core or BailingHub Core, and does not become a persistent executor. The listing provides discovery and download only; it does not imply built-in Tencent ADP distribution, Tencent certification, recommendation, partnership, or a production security guarantee.
Marketplace, npm, and community directories provide discovery and installation paths. Production suitability still requires source review, secret configuration, business authorization checks, and runtime validation by the deployer.
Adapters connect to the BailingHub deployment you operate. Whether model inputs leave that deployment boundary depends on the model provider and endpoint you select.
An adapter and the hub can constrain what an agent may reach. They cannot replace the business system's decision about what an acting subject may do right now.
Build an independent adapter against the public Client API first. For industry integration, private deployment, or joint delivery, see Delivery.
Choose a low-risk, verifiable operation. Complete job submission, business authorization, execution, and audit before widening the agent's reach. PASS, partial, and failed reproductions are all useful when the evidence is sanitized.