Agent Client browser authorization and local orchestration

Agent Client lets the local agent understand, plan, and choose business tools while BailingHub governs business identity, capability scope, approvals, idempotency, invocation, and audit. Core v0.10.0, together with the independent SDK and DSH plugin v0.8.0, can use authorized accounts from multiple systems in one Hub and audit domain, linking synchronized visible text to each original action.

Start with Accounts and conversation records. Upgrading the Hub alone does not add a scope selector to an older client or recover missing historical text.

It does not replace /run, embedded chat, Client API, or the Executor Protocol.

Optional model services and shared allowance

Core 0.10.0 and SDK/DSH 0.8.0 can opt into conversation models, generation tools and USD plans. Hosts preserve original request IDs and handle generated results separately from pending settlement. Periodic sale price and allowance are independent; use summary presentation for Credits or remaining percentage. A plan does not widen business authorization. See Model services and plan billing.

On-demand tool guidance and knowledge

SDK/DSH 0.8.0 can explicitly negotiate on-demand knowledge for Agent clients: receive bounded hints, then search and read knowledge within the current authorization. Complete tool guidance is also read when needed. Required rules, tool schemas, permissions and approval stay in place; knowledge does not expand execution rights. Older clients retain bounded inline content. Native and embedded chat keep their existing knowledge assembly.

Tool arguments are measured as the UTF-8 bytes of JSON.stringify(arguments), up to 1 MiB; the full HTTP envelope is bounded at 2 MiB. Business APIs may impose smaller limits. Business objects such as source remain objects. See the Agent knowledge API.

Long tasks, original calls and attachments

In Agent Clients → Task Control, administrators can fix task members, tool scope, cumulative write-call allowance, and concurrent dispatch permits. The host persists task bindings and original call records, then establishes execution context for later turns. Task allowance counts business writes; model costs settle separately under the plan.

Check progress: read the original invocation receipt for execution and approval state without triggering a business action.
Continue the original call: require an explicit user action and retain the original authorization, arguments, and invocation ID. Inspect unknown results first to avoid duplicate writes.
Pause or cancel a task: pausing prevents later dispatches; in-flight calls may still finish. Cancellation stops later dispatches without rolling back completed actions.

DSH retains valid tools within a turn. Adapted hosts can explicitly enable declaration reuse across messages of the same living Session, with current-turn target checks. Reusing declarations does not automatically resume an entire task. Task enrollment persists for the original Agent Session after cancellation. Check host compatibility before enabling it, and retain a Core version that enforces that marker.

See Task Control and read-only invocation receipts for the APIs. Generated images can use the attachment space as needed; ordinary chat does not automatically upload files or create business runs.

Continuing truncated generation without repeating effects

A model’s per-generation output budget is separate from an Agent task’s lifetime. After confirming an output-budget finish reason, a host can save progress and prepare a bounded new model operation. A missing receipt, pending operation or unknown outcome must first be inspected under the original ID. Reuse completed tool invocations and results; never execute partial tool arguments or use continuation to bypass approvals or uncertain writes.

Core and SDK supply budget, response and recovery contracts. The host implements the task loop, continuation/time/cost limits, cancellation, restart checkpoints and no-progress detection. Updating Core or a package does not automatically add this behavior to every client. See continuation and original-request recovery.

Responsibilities

Party	Responsibility
Business system	Login, account/tenant selection, trusted subject derivation, final permissions and state checks
BailingHub	Client App, workspace, capability projection, approval, invocation, revocation, and audit
Local agent/plugin	PKCE initiation, secure credential storage, local planning, tool selection, and user interaction

Setup flow

The business system exposes an account- and tenant-neutral agent_authorize_url and derives identity from the current login session;
select the client in Agent Clients and review the authorization entry, workspace, system description, tools, and approvals together;
create or reuse the Client App and obtain its public clientAppId; choose exact writable operation IDs—system descriptions never grant tool access;
the plugin starts browser + PKCE authorization; the user signs in, selects an account/store, and confirms;
start a conversation and select its authorized accounts before the first message; an empty or unset scope means ordinary chat;
the agent selects an account for each action within that scope and reads its rules and tools; the Hub and business system still check permissions;
administrators inspect synchronized conversation text, open each account’s original execution records, and may revoke individual Agent Sessions.

Credentials and content

Keep the following on the Hub server rather than sending them to the local agent:

model-provider credentials configured in the Hub; the host manages credentials for its own configured models;
Tool Provider Secrets, Client Tokens, and admin tokens;
internal business API URLs and full target_config.

Conversation archives accept visible text and exclude hidden reasoning. Synchronized text enters the Hub’s audit domain for administrators with task-read permission.

Writes and approval

Routes store exact writable operation IDs, not wildcards. Local planning never weakens ACC approval declarations; additional forced approval may only tighten them. The business endpoint still reauthorizes immediately before a write.

Select accounts before starting the conversation

A plugin may save several connections. One DSH conversation may select authorizations with different clientAppId + workspace bindings inside the same Hub and audit domain. Every member retains its original connection key, Agent Session, and target identity. Cross-Hub scopes are unsupported. Each account requires browser authorization; a local connectionName or display name cannot forge an identity.

Run /bailinghub connections list to obtain fixed connection keys. Before the first message in a new conversation, run:

/bailinghub scope set <connection-key-A> <connection-key-B>
/bailinghub scope

Replace the placeholders with fixed keys, not aliases. One key permits only that account; /bailinghub scope none or an unset scope means ordinary chat. Wait for a successful response before sending a message. connections use does not select the current conversation’s scope.

The scope freezes after the first message. Start a new conversation to change accounts. Reopening a started conversation validates its original scope; reopening an unstarted draft requires selection again. If any selected authorization is revoked or its identity changes, the whole original scope is blocked rather than silently narrowed. Other independent conversations continue to validate their own scopes separately.

System descriptions and authorization subject names

Controlled system metadata lets the model distinguish commerce from inventory before its first capability search. It describes product purpose without granting tools or creating a business run for every target.

The backend supplies subject_display.name through a trusted authorization flow. It may identify an organization, account, project, warehouse, or store. SDK/DSH uses it in lists and target descriptions. Existing sessions can receive updates; a missing name remains explicitly unknown. Renaming never changes connection keys, authorization identity, or archive links.

Records and connectivity failures

Open Tasks → Conversations → Client conversations to read synchronized visible text, then inspect each account’s original execution, approval, and tool trace within a turn. Authorization-scoped records remain available. Older or unsynchronized text may be missing; execution summaries cannot replace it.

After reconnecting, retry validation and synchronization in the original conversation. Every original authorization must pass before saved events can be uploaded. Upload retries do not repeat business writes. Original-call recovery uses a separate trusted persistent record; it cannot be inferred from conversation text. See the host integration requirements above. “Synced” means the saved events were uploaded; unsaved-event counts and history gaps still matter.

The current pairing is Core v0.10.0 with SDK/DSH v0.8.0. Upgrading public 0.9.4 adds no SQL migrations. Earlier versions still apply outstanding migrations, including 068, to each actual state/configuration database. Preserve configuration, original operations, approvals and data. Startup does not migrate automatically, and applied files must not be replayed. See the upgrade guide.

Read the host integration guides in this order:

SDK 0.8.0 paired upgrade: confirm the Core 0.10.0 / SDK 0.8.0 / DSH 0.8.0 pairing and recovery requirements.
Browser authorization and business-tool basics: implement authorization and governed calls, using the paired upgrade guide for installation versions.
Optional model-service integration: integrate model catalogs, generation tools, allowance summaries, and original-request recovery.

Core provides the Hub-side protocol and administration audit; the business system retains final authority. ACC describes tool governance requirements as an independent capability contract.