A shop operator asks an AI assistant:
Check inventory for these three products. Update the descriptions for the ones in stock. Leave prices and stock levels unchanged, and keep the usual approvals.
The assistant knows how to query inventory and edit a product. Each API works. The user has authorized both systems.
Now the interesting problems begin.
The assistant searches for an inventory tool and loses access to the editing tool it found earlier. The user sends a follow-up, and discovery starts again. One edit times out. Then the user says, “Pause—we need to change the campaign.”
What has actually stopped? Which edit succeeded? How much work can the assistant still perform?
These questions concern the whole assignment. A collection of working tool calls is only part of the answer.
This article uses a synthetic shop-and-inventory example to explain the design choices we have been working through in BailingHub, an open-source control plane for business actions. The goal is useful continuity: an assistant that can keep working within a clear, enforceable boundary.
Keep useful tools available
Real work moves between capabilities. An assistant might edit a description, check a stock figure, inspect the product, and return to editing.
Replacing its entire tool set after each search makes that ordinary sequence unnecessarily difficult. It also creates confusing failures: “tool not loaded” can sound like “the system cannot do this,” even when another search immediately restores the capability.
A bounded cache can retain recently discovered declarations and their original targets. The assistant still needs access to the full parameter schema when using them. Remembering a tool name is insufficient grounds for guessing its arguments.
There are two useful lifetimes here:
- A declaration can remain useful across searches and user messages.
- An execution context belongs to the current operation and its authorization checks.
Reusing the first must not accidentally reuse an ended run from the second. A fresh edit needs the current target context. Recovering an existing edit needs its original execution record.
Target identity must also survive caching. Two systems can expose a tool named update_product; two shops can both have a product numbered 42. Neither name nor number identifies the authorization to use. Resolve the intended system, authorization, and business object before dispatch. A cross-system product mapping needs an explicit business basis, such as a verified SKU mapping.
Ordinary conversation should remain ordinary conversation. Saying “thanks” should not start business runs across every connected system merely to refresh cached tools.
Give the assignment a durable boundary
A conversation can span many messages. A business task needs a boundary that survives them.
For our example, that boundary could include two selected authorizations, inventory reads, product-content edits, a cumulative write-call allowance, and an in-flight limit.
These controls answer different questions:
Control Question Selected authorizations and allowed tools Which targets and operations belong to this task? Rate limit How quickly may requests arrive within a time window? Cumulative write-call budget How many writes may this assignment attempt? In-flight limit How much work may remain outstanding at once?A new message should not silently replenish the task budget. Neither should another tool search or a host restart. Ordinary business permissions and per-operation approval requirements still apply.
For the example, an administrator might allow six write calls for three test products. That is a call budget, not a three-product guarantee. One batch API can change many objects in one invocation; one product may require several invocations. A request rejected by the business system can still consume a call. Reads do not use this write allowance, but they can occupy in-flight capacity.
The instruction “leave prices unchanged” also needs an enforcement owner. If the available API can edit every product field, a sentence in the prompt does not turn it into a content-only API. Use a suitably restricted operation or server-side checks on permitted objects and fields. The business backend remains responsible for those constraints.
Clear units and ownership make the controls understandable to developers and to the people assigning work.
Make pause an execution control
When a user asks an assistant to stop, a reassuring sentence is easy to produce. Stopping future dispatch requires a control in the execution path.
The host or control surface needs to translate that request into an actual task pause. The model remembering “do not continue” is not the enforcement mechanism.
A dispatch permit marks a useful boundary. Pausing prevents subsequent permits from being granted. Work that already obtained a permit may still finish, including a request racing with the pause.
Consider this illustrative timeline; it is not a captured production trace:
Edit A: permit granted -> business response confirms completion
Edit B: permit granted -> request sent -> acknowledgement lost
User pauses the task -> subsequent dispatch permits blocked
Edit C: no permit -> not dispatched
Current view:
A Completed
B Result needs checking
C Not dispatched
Enter fullscreen mode Exit fullscreen mode
A separate operation waiting for human approval should remain visibly pending. It must not become “completed” simply because the user approved it; approval and execution are separate facts.
The interface can now say something precise: “Further dispatch is paused. One earlier request still needs checking.”
Continuing the task should preserve its remaining budget and unresolved calls. It should not automatically replay the original plan. Cancelling likewise does not undo completed edits. Reversing a business change requires a supported correction or compensation operation, with its own authorization.
Inspect the original call after a timeout
Return to Edit B. The shop may have committed the new description before the connection dropped.
Sending another edit because the first response is missing creates a new business operation. It does not establish what happened to the original one.
Recovery needs a durable record linking the invocation to its original authorization, target, parameters, and execution context. After reopening the client, the first useful action is to inspect that record.
Inspection should be read-only. Explicitly continuing a pending operation is a different action and must retain the original identity and governance checks. A previously dispatched write with an uncertain result should be reconciled through its original record and available business evidence, not replaced with a new call.
Sometimes the evidence remains insufficient. “Unverified” is then an honest result. A missing local record is not proof that the business operation never happened.
The conversation explains what the user requested. The invocation record explains what was dispatched and what outcome is known. Both are useful; neither should be fabricated from the other.
What we have implemented
The current pairing is BailingHub Core 0.8.0, Agent Client SDK 0.6.0, and the separate DSH plugin 0.6.0. The Core release notes and DSH release notes describe the shipped behavior.
DSH retains valid tools across searches within a turn. Adapted hosts can opt into reuse across turns of the same living Session and runtime. Restarting still requires discovery; original-call recovery relies on a separate persistent journal.
Core provides task budgets, dispatch permits, and pause controls. SDK and DSH expose the corresponding integration points and original-call inspection. Client developers must connect the persistence and UI; installing a package does not supply those automatically.
The implementation currently keeps participating targets within the same Hub and audit domain. It does not provide cross-system transactions, automatic product mapping, business rollback, or automatic restart of an entire model plan.
ACC, the Agent Capability Contract, remains a separate, implementation-neutral contract. BailingHub implements runtime controls; business systems retain final authority over their state.
Start with three synthetic products
A small acceptance exercise can expose the important behavior before you increase the workload:
- Switch capabilities. Edit a test description, query inventory, then return to editing. Check the selected target and current schema each time.
- Continue the conversation. With the adapted host’s session reuse enabled, ask a follow-up. Check that valid declarations can be reused without another remote search solely because the turn changed.
- Pause during work. Check that no subsequent permit is granted while earlier calls remain observable.
- Lose an acknowledgement deliberately. In a controlled test backend, commit one edit but drop its response. Reopen the host and inspect the original invocation. Verify that recovery creates no replacement write.
- Inspect accounting. Confirm that messages and restarts did not reset the budget, and that completed, pending, unverified, and undispatched work remain distinguishable.
Use dedicated test authorizations. In this implementation, enrolling an original Agent Session in task control creates a persistent requirement that also affects its other conversations; cancelling a task does not remove it. Check the paired upgrade guide and every relevant host before enrollment.
For a first integration, describe one business system, one action, and a sanitized API example. That gives a reviewer something concrete to reason about and a developer something small to verify.
If you are building a similar integration, where does control of the whole assignment live today—in the client, a workflow engine, or an execution service? How does your user distinguish a paused task from an operation whose result is still unknown?
Disclosure: I maintain BailingHub and ACC. The examples here are synthetic design and acceptance scenarios, not customer adoption claims.