A complete operating path, not another chat box
Connecting an Agent to an existing system involves more than calling a model. You need entry points, identity, context, business tools, permissions, approvals, audit records, delivery, and troubleshooting. BailingHub extracts those concerns into an independent A2B control plane.
Keep business boundaries
Your system triggers jobs through HTTP, exposes only selected tools, and receives results. BailingHub does not import your business code or depend on your database schema.
Govern reach, keep authority
BailingHub controls routes, tool allowlists, risk policies, rate limits, approval intent, and audit. Your backend still decides whether the acting subject may perform the operation.
Run multiple scenarios
Support, operations analysis, knowledge assistance, inbound channels, web chat, and scheduled tasks can be configured as separate routes in the same complete open-source hub.
Trace failures
Every run has a job, trace events, tool calls, knowledge references, approval intent, and explicit errors, so teams can separate model, configuration, permission, and business API problems.
Break the requirement into eight decisions
llm target, a local model, a remote executor, a custom agent, or another Agent tool.What each console area solves
| Area | Purpose | Output | Developer handoff |
|---|---|---|---|
| Runs | Inspect input, route, status, tools, knowledge, approval, trace, and errors. | job_id, trace, debug report. | Job id, exact error, and debug report. |
| Routes | Define one business scenario and its runtime policies. | route_key, input policy, tool allowlist. | Route key, trigger code, and required metadata. |
| Clients | Control which business system may trigger which routes. | app_id, token, route allowlist. | Server-side token and allowed routes. |
| Targets | Register the model or executor that handles jobs. | Target name, kind, timeout. | Target name, executor token, and startup command when needed. |
| Model credentials | Register model endpoints, keys, models, and intended capabilities. | Credential name and verification result. | Usually the credential name, never the secret itself. |
| Tool providers | Turn selected business APIs into governed Agent tools. | Signing secret, tool list, scopes, authz probe result. | ACC/OpenAPI declaration, HMAC verification, and business authorization rules. |
| Knowledge | Make policies, manuals, and FAQs retrievable. | Knowledge base id and retrieval test. | Data source endpoint or sync rules when content comes from another system. |
| Web chat | Embed a route into an existing website. | entry_key, script snippet, ticket rules. | Embed code, visitor ticket signing, and page-context requirements. |
| Inbound channels | Receive messages from external communication platforms. | Callback URL, platform settings, route binding. | Callback setup, reply windows, and delivery limits. |
| Media storage | Store image, audio, and file attachments locally or in object storage. | Storage name, attachment URLs, input policy. | Only needed when the business owns the CDN or storage domain. |
| Diagnostics | Validate routes, tools, executors, routing rules, dead letters, and smoke checks. | Errors, warnings, smoke results. | The exact object and original diagnostic message. |
Choose a small first scenario
Read-only business assistant
Start with model credentials, read-only tools, one route, and one client. Good examples include orders, customers, tickets, inventory, and device status.
Web support assistant
Combine support knowledge, order or ticket tools, a route, and a web entry. Signed visitor tickets carry authenticated user identity.
Create a refund request
Expose a reversible “create request” action before a direct refund operation. Declare high-impact operations with high risk or explicit confirmation.
Internal knowledge assistant
Configure an embedding model, knowledge base, ingestion, and a route. Add source synchronization only when documents come from another system.
Backend-triggered job
Call POST /run when a business event occurs. Use a business-unique request_id and receive the result through callback or polling.
Local model or Ollama
Register an OpenAI-compatible base URL such as http://host.docker.internal:11434/v1. Business callers still target the same route contract.
Local coding or operations Agent
Register an executor target and issue an executor token so a local or private-network Agent can claim outbound jobs without exposing the machine to inbound access.
Images, audio, and files
Choose local or object storage, then configure each route to forward, recognize, transcribe, extract, or reject supported media types explicitly.
Turn the configured scenario into an implementable contract
Do not hand developers a vague request to “add an Agent.” Provide the route, client, metadata, tool provider, acting subject, signature, and business authorization requirements.
Scenario: order inquiry assistant Route: order-query Client: commerce-backend Trigger: backend POST /run Required metadata: operator_uid and order_id Tool provider: order-tools Allowed scopes: order.read / shipment.read Signature: verify BailingHub sha256 HMAC on every tool call Authority: reuse the business permission table for operator_uid Troubleshooting: start with job_id, trace, and debug report in Runs
Continue with the API contract, business tools, SDK, and operations guide. This guide defines the business intent; developer docs define the integration details.