AGENTS AND SOFTWARE

Connected business actions require explicit transaction intent

Event source: Claude Duet opens a proactive-agent research preview ↗

In this analysis
THE RETROSPECTIVE TAKE

An approved proposal must remain connected to the operation actually attempted and the outcome actually observed.

Connected work reached a transaction boundary

The August 25, 2026 shared-memory update and September 22 Opus 5.5 release preceded Duet’s October 21 research preview. Its app-and-connector direction included preparing business work and seeking approval for consequential actions. That makes transaction intent a separate object from a broad goal. Knowing that a business needs supplies can justify preparing a comparison. It does not fully specify which item, counterparty and consequence the user intends to authorize.

Preparation can remain reversible

An illustrative assistant compares compatible office equipment and prepares an order proposal. The proposal can expose the selected item, relevant terms and unresolved questions before a commitment exists. This preparation is valuable even when the user ultimately declines. Treating it as equivalent to purchase would remove the opportunity to correct a misunderstanding. The key design boundary is the transition from an editable artifact to an external consequence, rather than a vague distinction between helpful and unhelpful autonomy.

Approval needs a stable object

A person cannot meaningfully approve an operation whose material details change afterward. If the chosen item, recipient or amount differs from the reviewed proposal, the earlier decision no longer clearly applies. A workflow should therefore connect the approved intent to the operation actually attempted. This is a general transaction-design principle, not a claim about an undocumented Duet identifier or payment guarantee. It also avoids treating a remembered preference as a substitute for the specific decision needed at the point of consequence.

An illustrative proposal-to-outcome fixture

A practical test can use a mock purchasing environment with a prepared proposal and a changed item before submission. The expected behavior identifies the mismatch rather than silently carrying forward the old approval. A separate case leaves the proposal unchanged and inspects whether the reported result matches the mock system’s outcome. No real purchase, card detail or financial return is involved. The fixture examines consistency of intent, attempted operation and reported outcome, keeping product access and actual connector support as separate prerequisites.

Integration does not erase the decision

The preview makes cross-application assistance plausible, but connectivity alone cannot define business authority or prove that an operation achieved its intended effect. A useful handoff retains the proposal, decision and supported outcome at the appropriate level of detail. The retrospective lesson is that an agent can reduce preparation work while preserving an explicit transaction boundary. This supports meaningful review without assuming that every small operation requires a new ceremonial workflow. The necessary boundary follows the actual consequence and the authorization already provided for that particular task.

← All retrospectives