Use multiple systems and accounts in one conversation

You have authorized a commerce system and an inventory system. You want to say:

“Check how many flasks are in stock. If available, set the store price to CNY 59 and publish the product. Otherwise, leave it unpublished.”

BailingHub 0.10.0, with SDK and DSH 0.8.0, allows one conversation to use both selected systems. The agent learns what each system is for before searching for tools. It uses the inventory authorization to check stock and the commerce authorization to update the listing. Each system retains its permissions, validation, and approval rules.

Both systems must expose the required operations, and the product relationship must be confirmed. BailingHub does not infer a reliable product mapping or treat a conversational reply as proof that every action succeeded.

What this changes

Previous problem	Current behavior
One conversation could select accounts only within one system	Explicitly select different systems in the same Hub and audit domain. Existing same-system A/B scopes continue to work.
The agent did not know which system to search first	Controlled system names, purposes, and boundaries describe selected targets before the first capability search.
A successful authorization showed only a local label	A business backend can supply the real subject name, such as “Flagship store” or “East warehouse.” Existing sessions can receive it without reauthorization.
Separate actions were difficult to match to the conversation	Follow synchronized visible text into each system’s original calls, approvals, and results. A selected but unused system is not marked as executed.

A system description explains what the product typically does. A subject name identifies the object this authorization belongs to. Neither grants permission. “Not loaded” means tools have not been searched yet, not that no capability exists.

Before starting

Deploy BailingHub 0.10.0 and use dsh-bailinghub 0.8.0 with the independent bailinghub-mcp-server 0.8.0 SDK. Custom clients integrate fixed conversation scopes, system descriptions, subject display, and visible archives. Upgrading only the Hub does not change an older client’s interface.

Both systems must already be integrated, and each account must complete browser authorization. A conversation currently stays within one Hub and audit domain; it does not combine arbitrary Hubs or transfer transcripts across their boundaries. The public Docker demo teaches reads, approvals, and execution using its own synthetic scenarios; it does not connect your commerce and inventory systems automatically.

A complete session

1. Start a conversation and select both authorizations. For example, “Commerce · Flagship store” and “Inventory · East warehouse.” Selecting only commerce permits only commerce. Selecting nothing means ordinary chat. See the DSH commands.
2. Name the product and requested changes. The agent checks flask stock first. It requests repricing and publication only after the product mapping and availability are confirmed. Ambiguity needs clarification.
3. Inspect each result. Stock lookup and repricing may be complete while publication awaits approval. Pending publication is not success. A failed step does not automatically roll back completed steps in another system.
4. Check the backend and original call. A Hub administrator opens Tasks → Conversations → Client conversations, then follows each system’s calls and approvals. Verify the final listing in the commerce backend.

Names are display-only. Duplicate names or renaming do not change the connection key, original identity, or archive links. An older authorization without a subject name should show “Authorization subject name awaiting sync,” not a guessed label.

Scope freezes after the first message. Start a new conversation to change systems or accounts. Reopening an existing conversation validates its original scope; it never substitutes the default or all accounts. An unstarted draft can reconfirm its selection.

When something goes wrong

Situation	Meaning and next step
Pending synchronization	Business may already be complete. Reconnect and retry sync in the original conversation; do not repeat a write to repair its record.
Authorization cannot yet be verified	Business tools remain closed. Retry in the same session after reconnecting. Every original member must pass validation.
Any original authorization is revoked or changes identity	The entire selected scope stays blocked, without falling back to other accounts or a subset.
Local storage failure or missing history	A saved prefix is not the full history. Show unsaved counts and gaps; never invent missing text.
Unsupported version	Check Core, SDK, and plugin compatibility. Existing same-system flows do not gain a wider scope.

“Synced” means the currently saved events were uploaded. Archive retries preserve original events and execution links without resending business messages or repeating writes. Reopening an original invocation relies on separate trusted persistent records, not reconstructed conversation text; see long tasks and original-call recovery.

Who sees the records, and who upgrades

Visible text enters this Hub’s administration audit domain for administrators with task-read permission. Identities, approvals, and memory remain separate; the combined response is not copied into each account’s model memory. Hidden reasoning, attachments, and arbitrary local tool output are outside the archive.

• Hub operators: back up first, check the actual migration ledger against the 0.10.0 upgrade guide; 0.9.4 adds no SQL and earlier versions apply only outstanding migrations. Then upgrade the service and check health.
• Business-backend developers: provide subject_display.name through the trusted authorization flow when automatic subject names are needed. Existing sessions can receive name updates; own-client session query and revoke APIs support lifecycle management. Existing business tools and approvals do not need rewriting.
• Client developers: update SDK/DSH, integrate scope and display fields, and preserve original connection keys, Sessions, events, and acknowledgement progress. Do not erase history or recreate every authorization to upgrade.

Continue with Agent Client and this release’s changes. ACC remains an independent, implementation-neutral contract.