Not every click needs an agent

Some actions are local presentation: selecting a row, switching tabs, changing a sort. Others change a durable view's state. Some invoke a bounded domain operation, such as submitting an already reviewed form. And some begin a multi-step investigation that may need planning, delegation, human decisions and recovery.

These should not be forced into one universal 'run an agent' pipeline. The user needs normal software responsiveness for simple tasks and durable work semantics for autonomous ones.

Calling an action 'direct' does not exempt it from policy, authorization or verification. A user clicking a confirmation button and an agent requesting the same business transition should face the appropriate action boundary.

A small direct write is not automatically a long-lived Execution. Conversely, a seemingly simple request may become an Execution when it requires querying hundreds of records, reconciling evidence and waiting for an external source.

A generated table should preserve a stable reference to the data and the user's current view. Closing its tab should not erase the artifact. Reopening a document should not require reproducing a transcript.

If an agent changes the same document the user is editing, the system must account for revision and conflict rather than overwriting newer edits because the model's turn finished later.

The point of intent-shaped UI is not drawing a different component for every request. It is selecting useful work surfaces that expose state, evidence and controls with consistent interaction semantics.

The hard engineering lies in the boundaries: view versus data, draft versus committed change, direct action versus autonomous work.

Software should stay software. Intelligence should be available where the work actually requires it.

Imagine an analyst looking at a supplier table. Sorting by overdue amount should be immediate presentation logic. Changing which columns are visible may become a persistent workspace preference. Opening a read-only supplier detail can be a bounded domain action. Asking 'investigate why these three suppliers keep missing deadlines and coordinate a follow-up' is substantive autonomous work.

From the user's perspective these actions happen in one coherent surface. From the system's perspective they have different lifecycles, permission requirements and latency budgets. Treating them all as one agent invocation makes basic software fragile and expensive. Treating all of them as direct API calls loses the planning and recovery required by long tasks.

A good intent-shaped interface chooses the smallest interaction model that matches the job, rather than promoting every click into a separate conversation.

A direct user action and an agent-proposed action may ultimately request the same business transition. They should meet equivalent business policy and verification requirements even though one is interactive and the other autonomous. UI convenience cannot become a shortcut around authority.

The line between draft state and committed state needs particular care. A generated form can collect edits locally and display a successful-looking preview, but that does not mean an ERP record changed. A write receipt and a verified postcondition are separate from the user-visible component.

Similarly, having a generated component display a capability is not proof that the capability is currently available. The user should see disabled, absent or appropriately explained actions rather than an optimistic button with no valid backend.

A work surface can outlive the message that created it. It can maintain a stable relationship to an artifact or business object while the user switches focus, another Execution completes, or new evidence arrives. This is more ambitious than drawing a chart inside the last assistant bubble.

An agent may update the underlying artifact while the user is editing a form. The system needs revision discipline and conflict handling rather than silently overwriting either side. Focus identifies which object the user is looking at; it cannot be treated as automatic permission or a binding instruction for every ambiguous request.

This separation is part of Artemis's vNext Work Surface model, not a claim that every interaction is currently available in the demo. The underlying design is described at https://github.com/sarooo17/artemis-architecture/blob/main/docs/08-EXPERIENCE.md.