There is nothing wrong with chat. It is an excellent interface for a question, a quick draft, a line of inquiry, or the first articulation of a task. It gives a person somewhere to think aloud and gives a model enough context to respond.

The trouble begins when the conversation becomes the only place where work exists.

A transcript can show that an agent said it would inspect a repository. It does not show which branch is currently active, whether a command changed a file, which check produced a screenshot, whether a request is waiting for approval, or whether the task is blocked on a missing credential. It tells us what was said. It does not reliably tell us what is true now.

That gap is the design problem for an agent-native workbench.

Start from the moment of uncertainty

Imagine taking over a task that someone else started two hours ago. The agent has edited eleven files, run a test suite, encountered a failed browser check, and stopped before a command that would publish a preview. The next decision may be simple: inspect the visual regression, approve the preview, or abandon the branch. But it will not feel simple if the interface begins with two thousand lines of chronological narration.

The workbench should answer the questions a person naturally asks at that moment:

• What is the objective?
• What has actually changed?
• What is currently blocked or waiting?
• What evidence is available for the agent's claims?
• What action requires my decision, and what happens if I allow it?

The interface does not need to make every fact equally prominent. It needs to make the next responsible decision easy.

A task has several kinds of state

Agent interfaces often collapse everything into a single event stream: messages, tool calls, command output, approvals, and final summaries appear as neighboring bubbles. It is a convenient implementation, but a poor mental model. These events have different roles.

Intent is the request and its constraints. It changes rarely and should be visible without scrolling.

Work state is the live environment: the repository, branch, files touched, active services, pending plan, and unresolved blockers. It changes as the task proceeds.

Evidence is the subset of artifacts that supports a claim: a diff, test run, preview, query result, screenshot, or log excerpt. It should be attached to the claim it helps assess, not buried in an undifferentiated feed.

Authority is what the system may do next. Reading a local file, writing a branch, sending a message, deleting a record, and publishing a deployment are different operations. An approval should make the requested action, scope, reversibility, and relevant context clear before it asks someone to decide.

History is the sequence that explains how the task reached its current state. It matters, but it should be a route to detail, not the default surface for every decision.

When these categories are visually distinct, a workbench becomes calmer. The user is not forced to parse narration in order to determine whether the next step is a review, a retry, or a question.

Evidence should arrive when it becomes useful

An agent that claims "the issue is fixed" should not expect a reviewer to trust a polished sentence. But a workbench can make verification exhausting if it presents every build log and every screenshot before the reviewer has seen the change.

The better pattern is progressive disclosure. Start with a concise account: the task changed a specific surface, these checks ran, one limitation remains. Let the reviewer open the diff, inspect the terminal output, or compare the preview when the risk warrants it.

The order matters. A visual change may be assessed first in a preview, then in the code. A dependency update may begin with the lockfile and advisories, then expand into tests. A database operation may lead with its rollback plan and impact estimate. There is no universal panel order because there is no universal kind of work.

The interface should understand that evidence is contextual. It is not a decorative attachment added after the agent has finished speaking.

Approvals are moments of responsibility

An approval request is not another chat message with a button. It marks a change in responsibility. The agent has reached a boundary and is asking a person to authorize something the runtime will carry out.

That request deserves its own surface. Before approving, a user should be able to see:

• the exact operation and its target;
• why the task needs it now;
• the authority that would be used;
• whether the action is reversible;
• any evidence or diff that makes the request intelligible;
• the option to decline, narrow the scope, or ask for a different plan.

The aim is not to convert every small command into an interruption. Good systems classify operations so that routine, bounded work can proceed while consequential actions are brought into focus. The user should not have to remember a policy encoded in a prompt, nor should they be asked to approve an opaque sentence that hides the real effect.

Design for the second person

Tasks are interrupted constantly. A meeting starts. A model call fails. A reviewer changes the priority. A person moves to another task. A new engineer joins an investigation. An agent-native workbench should be designed for that second person, even when the second person is the original operator returning after lunch.

Resumption becomes inexpensive when the screen preserves a compact operating record: the goal, the branch, meaningful actions, failures that changed the plan, outstanding approvals, and evidence already collected. This is not the same as retaining every line of scrollback. A long transcript is often the least useful artifact in a handoff because it makes the reader reconstruct which details still matter.

The design test is practical: can a new person explain the task's current state in one minute, find the supporting artifacts in another, and make the next decision without asking the agent to start its story over?

The goal is a shared workspace

The best workbench will still include conversation. People need a place to state intent, challenge a proposal, and ask questions that do not fit a form. But the center of gravity should shift from conversation about work to the work itself.

That means a clear objective, legible state, scoped approvals, recoverable execution, and evidence that a human can inspect. It means using source, terminal output, previews, logs, and messages as tools for answering a decision rather than filling a dashboard.

When an agent interface is designed this way, it feels less like a conversation with a capable stranger and more like a shared workspace that keeps a careful record. That is the standard worth aiming for.

The best agent interface will feel less like a conversation with a clever assistant and more like a shared workspace with a careful operating record.