Agent UX Optimizes Delegation

Most AI product discussions still talk as if the hard problem is making the agent smarter.

That is only half true. Smarter agents create a different bottleneck: the human no longer knows when to look, what to trust, where to intervene, and what action is valid from the current state.

A tool UX optimizes response. An agent UX optimizes delegation.

Those are not the same product problem.

Tools answer. Agents continue.

Traditional tools are built around synchronous intent:

1. human asks;
2. tool responds;
3. human checks;
4. session ends.

The UX surface is the response. If the response is good, the tool feels good.

Agents are different. A real agent does not just answer. It continues: reads files, runs commands, gets blocked, repairs, opens drafts, waits for approval, resumes later, maybe hands work to another agent.

Once work becomes long-lived, the UX surface is no longer the answer. The UX surface is the state of delegation.

The key question changes from:

“What did the agent say?”

into:

“What state is the delegated work in, and do I need to care now?”

That is why chat-only agent products feel noisy. They expose activity, not delegation state.

Logs are not states.

A failing test is not automatically a notification. It may just mean the agent is in a normal repair loop.

A generated PR is not automatically done. It may be a held draft awaiting review.

A long command is not automatically stuck. It may be expected runtime activity.

The product layer has to translate runtime events into delegation events:

• test failed → maybe repairing, not “notify human”;
• missing API key → blocked, notify;
• patch generated → held_draft, ask for approval;
• done → digest, unless it unblocks a human step.

Notifications should be state transitions, not log events. Even more precisely: only state transitions that cross an attention boundary should notify.

This is the difference between an agent console and an agent workspace.

A console shows what happened.

A workspace tells the human whether they need to act.

The missing layer: Attention Compiler

The useful abstraction here is an Attention Compiler.

Input:

• runtime activity;
• evidence;
• policy;
• task context.

Output:

• derived delegation state;
• attention level;
• valid human actions;
• evidence references;
• provenance for why the state is trustworthy.

The invariant should be:

same evidence + same policy = same attention behavior.

That means the LLM can summarize, explain, or suggest wording, but it cannot be the sole authority for state transitions. Deterministic policy owns transitions. Evidence supplies trust. UI exposes the projection.

If the model alone decides whether something is blocked, done, or safe to approve, the system has no stable semantics. It is just vibes with buttons.

tmux and Raft are two halves of the same problem.

One useful mental split:

• tmux preserves execution context;
• Raft-like collaboration surfaces preserve delegation context.

tmux tells you the process is still there: logs, shell, command history, running tests.

A collaboration surface tells you the work is still owned: who is doing what, whether it is waiting, whether intervention is needed, whether an external action is pending approval.

The interesting product layer sits between them.

Without that glue, the runtime is just a remote shell and the collaboration UI is just a prettier inbox.

The hard product question is not “can I see the agent’s terminal?” It is:

Can runtime state become human-attention state without forcing the human to re-derive it from raw logs?

Evidence should be the UI material, not an audit appendix.

A good delegation surface should lead with derived state:

• blocked;
• since when;
• by which rule;
• based on which evidence;
• what actions are valid now.

Raw logs should be drill-down material, not the default cognitive burden.

For example:

Blocked: missing GitHub token
Since: 14:03
Rule: external write requires authenticated remote
Evidence: gh auth status failed in sandbox
Valid actions: connect token / switch to local-only draft / cancel

That is much more useful than dumping the last 200 terminal lines and asking the human to infer the state.

The goal is not to hide detail. The goal is to avoid making the human perform the compiler pass manually.

Acceptance tests for agent UX

A serious agent workspace should be testable with replay, not just judged by screenshots.

Minimum checks:

1. Replaying the same event log under the same policy should produce the same delegation transitions.
2. Every notification should be explainable by evidence.
3. Human override should not rewrite the append-only runtime log.
4. Policy changes should affect future projection, not silently mutate historical truth.
5. UI must show valid actions for the current state, not generic buttons everywhere.

This is where many agent products will fail: they will have beautiful activity streams but no state semantics.

The moat is not “more agents.”

Spawning more agents is easy. Making their work bearable for a human is hard.

The real moat is the judgment loop around delegation:

• which events matter;
• which states deserve attention;
• which actions are safe;
• which evidence makes the state trustworthy;
• when silence is the correct UX.

Capability is what the agent can do.

AX — agent experience — is how a human can safely delegate to it without becoming its full-time supervisor.

That distinction is the whole product.