Capability and configuration map
BailingHub configuration is not a collection of unrelated switches. Start with where the user expresses a goal, which trusted business identity is acting, and which capabilities are allowed. Then decide where orchestration runs and which context it needs.
Find the path from your goal
Section titled “Find the path from your goal”| Goal | Primary configuration objects | Continue with |
|---|---|---|
| Submit a job from a business backend | Client and route | Client API |
| Embed chat in an existing admin | Chat Entry, route, and business identity ticket | Widget and SSE |
| Let an agent read or update business data | Tool Provider, ACC declaration, and final backend authorization | Business Tools |
| Add knowledge, page, or conversation context | Route, model credential, knowledge base, page context, and memory policy | Routes, models, and context |
| Let a local agent plan and operate the business | Client App, Agent Session, and Agent Client workspace | Agent Client |
| Run a Hub-created job in a local or private environment | Target and Executor Token | Executor versus Agent Client |
| Receive enterprise messages on a route | Inbound Channel, route, and platform identity mapping | Inbound channels |
| Connect an existing commerce, SaaS, CRM, or ERP system | Business SDK, adapter, or community recipe | Business adapters and recipes |
| Investigate a job, approval, or failure | Job, trace, approval intent, and change audit | Approvals and recovery |
How the core objects relate
Section titled “How the core objects relate”| Object | Its responsibility | Do not mistake it for |
|---|---|---|
| Route | Compose a scenario’s target, tools, knowledge, memory, delivery, and runtime rules | A single API or model |
| Client | Limit which server-side caller can invoke which routes | An end-user business identity |
| Target | Send the job to an in-hub LLM, executor, or another runtime | A source of business authority |
| Model Credential | Store model endpoint, key, default model, and purpose | A business scenario |
| Tool Provider | Compile explicitly declared business actions into agent-visible tools | Unrestricted exposure of the entire backend API |
| Knowledge Base | Retrieve explanatory material for selected routes | Live business facts or permissions |
| Chat Entry | Publish one route as an embeddable web entry | Business login itself |
| Agent Client | Give an authorized local agent a limited capability projection | An executor or universal business credential |
| Executor | Claim a Hub-created job and report its result | An interactive signed-in business user |
| Job and trace | Record runtime status, tools, approval, result, and errors | Hidden chain of thought |
Minimal closed loop
Section titled “Minimal closed loop”- Choose one action whose result can be verified in the source system.
- Declare it with OpenAPI and ACC, then re-check subject, tenant, and current business state before execution.
- Create a route limited to that action and select a web, Client API, local-agent, or channel entry.
- Correlate request, approval, invocation, and final result with
request_id,job_id, and trace. - Add capabilities only after the first path is proven; do not expose the whole admin at once.