A click is not proof.

A button accepted a click. A progress indicator stopped. A green toast appeared. The agent reports success. None of those events necessarily means the invoice was posted, the order was created once, or the customer record now contains the intended value.

Interfaces are designed to guide people, not to provide machine-grade evidence. They can display optimistic state. A request can time out after the server commits it. A confirmation can refer to a queued operation rather than a completed one. The screen can move forward while a background write fails.

For low-consequence tasks, a plausible success signal may be enough. For work that changes a system of record, it is not. Reliable agent action begins by defining what “done” means outside the click path.

Define the effect before the action

“Create the order” sounds precise until the workflow fails halfway through. Which customer should own the order? Which currency and approval state are valid? Is an order number sufficient, or must the record contain specific line items? What happens if the system creates the record but the interface never returns a confirmation?

A useful action contract answers those questions before execution. It describes the accepted inputs, the state that must exist before the action, the side effect the action is permitted to produce, and the evidence that should exist afterward. It also names the conditions that count as a failure rather than leaving the agent to infer them from the screen.

Execution should not grade its own work

The component that performs an action has a narrow view. It knows which controls it used and which responses it observed. If that same component is the only judge of success, a mistaken assumption can survive from the first click through the final report.

Verification needs a separate question: what source-system fact would demonstrate that the intended effect occurred? Depending on the workflow, that might be a newly assigned record identifier, a read-back of the changed fields, a status transition, an export, or another independent observation. The important property is that the evidence refers to the business effect, not merely to the motion of the interface.

Graft’s product model separates these jobs: an adapter executes the bounded workflow, while verification checks the resulting source-system state. Graft is being built to return source evidence rather than only a summary of screen activity.

Retries are business decisions

Interface workflows fail in awkward places. The network disappears after submission. A remote desktop freezes while the source application continues processing. A response arrives too late for the caller. In those moments, “try again” is not a neutral recovery strategy.

A second attempt might be correct for a read. It might create a duplicate payment, order, or ticket for a write. The action therefore needs explicit retry behavior. Before repeating a write, it should determine whether the first attempt produced the effect. If that cannot be established, it should stop in a state a person can inspect rather than improvising.

Permission belongs inside the action

A reliable action is not only technically correct. It is authorized. The ability to read a record does not imply the ability to change it. The ability to update one field does not imply access to an entire application. Some actions should require an approval, a role, a value limit, or a specific operating window.

Those rules should travel with the action rather than exist as a suggestion in the agent’s prompt. The tool can then expose a narrow capability: this operation, on this kind of record, under these conditions. The action log can preserve who or what initiated it, which policy applied, what inputs were accepted, and what evidence came back.

Agent access therefore belongs in the execution layer, not only in a prompt. A prompt can describe a boundary; the execution layer must enforce it.

Interface drift should become visible

Business software changes. A field moves, a warning is added, a selector disappears, or a new application version alters the order of a workflow. Silent adaptation sounds convenient, but it can also hide a change in meaning.

When an interface-backed action is treated as a contract, drift should trigger maintenance: isolate the affected workflow, test the changed behavior, and recertify the adapter before resuming execution.

The goal is not execution that merely looks uninterrupted. It is a clear answer about whether the intended business effect occurred.

Questions to ask before an agent can write

Why this is central to Graft

Graft is being built for the moment when an agent leaves analysis and acts in a business system. The interface reaches the workflow, the contract defines the permitted action, and verification ties the result to the source system that owns the record.

The agent’s final answer should not be “I clicked submit.” It should be “Here is the effect, here is the evidence, and here is the policy under which it happened.”