What changes in 0.7.0, and how to upgrade
This release pairs BailingHub Core 0.7.0, MCP / Agent Client SDK 0.5.0, and DSH 0.5.0. It extends the 0.6 authorization and conversation model so developers can use several connected systems in one controlled conversation.
Start with a business request
Section titled “Start with a business request”“Check flask stock. If available, set the store price to CNY 59 and publish it. Otherwise, leave it unpublished.”
First select “Inventory · East warehouse” and “Commerce · Flagship store.” The agent knows to search inventory for stock tools and commerce for pricing and publishing. The product relationship must be confirmed, and both systems must expose these operations. Original permissions, validation, and approvals remain in force.
| Change | Problem it solves |
|---|---|
| Select several systems in one conversation | Check inventory and update a listing without changing the whole conversation’s default authorization. Every action retains its own system and account. |
| System descriptions before capability search | The model knows which system to search. “Not loaded” does not mean no capabilities exist. |
| Real authorization subject names | Users recognize the store, warehouse, or account supplied by a trusted backend. Renaming does not change identity. |
| Consolidated Agent Client setup | Review authorization URL, workspace, system metadata, tools, and approvals in one management flow. |
| Better lifecycle and trace links | Backends can query and revoke their own authorized sessions. Administrators follow the original conversation into each system’s calls. |
“Price updated, publication awaiting approval” remains two distinct outcomes, not a claim that everything succeeded. A selected but unused system is not marked as executed. A failed step does not automatically roll back an earlier change in another system.
Who needs to do what
Section titled “Who needs to do what”| Role | Upgrade work |
|---|---|
| Hub operator | Back up data and configuration, inspect the migration ledger, apply pending migrations, then start Core 0.7.0 and verify health. |
| Local-client developer | Update SDK/DSH to 0.5.0 and integrate system and subject display. Preserve original fixed scopes, Sessions, and archive acknowledgement progress. |
| Business-backend developer | To display real names, update the business SDK/API integration and provide subject_display.name during trusted approval. Add query and revoke integration where lifecycle control is needed. |
| Existing business-tool developer | Existing APIs, capability declarations, and approvals continue to apply. Pricing and stock services do not need rewriting for this release. |
For self-hosting, upgrade Core before the client SDK/DSH. These are independent projects; upgrading only one component does not complete the integration.
An upgrade from Core 0.6.1 applies pending migrations 058 and 059; older deployments also need preceding migrations. Do not rerun applied files. Runtime startup does not migrate automatically. Follow the complete Core upgrade steps, retaining backups and rollback material.
Verify the upgrade
Section titled “Verify the upgrade”- Recheck original same-system A/B conversations and confirm unselected authorizations receive no business requests.
- Authorize test commerce and inventory systems, select both before the first message, and confirm the model can describe their purposes.
- Read stock, then make a permitted low-risk change to a confirmed matching product. Compare approval, native result, and original call traces.
- Update the name on an existing authorization and confirm its original identity, conversation, and archive links remain intact.
- Recover the original conversation after a connectivity failure without repeating writes. Revoking any original member must block the whole selected scope.
Scope of this release
Section titled “Scope of this release”Multi-system conversations stay within one Hub and audit domain. They do not grant cross-Hub transcript transfer. System and subject descriptions are not permissions and do not promise a tool is enabled. Old scopes never expand to every authorization; missing names remain explicit. Business systems retain final authority, and ACC remains independent.
Sources: Core v0.7.0, SDK v0.5.0, and DSH v0.5.0. Continue with the multi-system walkthrough or developer integration guide.