The agent interface is the work graph

The present generation of coding-agent interfaces is still organized around the wrong noun. We say we are managing agents, but most of the time we are managing terminal windows, conversation logs, background processes, and the small private memory of where we left something running. This is already better than a single prompt box. It is also an admission that the interface has not yet found the shape of the work.

The useful insight in the current debate is that the model is no longer the only productivity variable. A capable model inside a poor workflow becomes expensive theater. A slightly less capable model inside a disciplined workflow can move more real work, because the human spends less time reconstructing context, checking whether the agent is alive, and remembering which tab contains which half-finished task. The interface has become part of the machinery of intelligence.

But the stronger claim is not that one terminal wrapper is better than another. That is a practical question, and a good one for this month. The more durable question is whether the interface should be a wrapper around agents at all. If the future of software work is a human supervising many partially autonomous contributors, the primary object cannot remain the session. A session is an accident of implementation. Work is the thing that persists.

Sessions are a poor proxy for work

A terminal tab tells you where a process is running. It does not tell you what promise the process is trying to keep. It does not tell you what evidence has been produced, which dependency is blocking the next step, which approval is required, or whether the change is safe enough to merge. Those questions belong to the work, not to the agent. When the interface gives the human a wall of sessions, it forces the human to rebuild the work graph in their head.

That hidden reconstruction is where much of the cost lives. The operator remembers that one agent is fixing tests, another is changing the implementation, a third is reviewing security posture, and a fourth has the context for documentation. Perhaps one has failed. Perhaps one is waiting for a package install. Perhaps one completed successfully but left behind evidence that has not been attached to the pull request. The terminal can show all of this in principle, but only by making the human inspect each stream and infer the state of the whole.

A better interface would begin with the durable object: the task, the deliverable, the evidence, the dependency, the approval state. The agent would be assigned to the node, not confused with it. A feature would show architecture, implementation, tests, evaluation, documentation, and release readiness as separate pieces of accountable work. Some pieces would be complete. Some would be running. Some would be blocked. Some would have failed in ways that deserve attention. The important point is that the graph would remain after any individual agent disappeared.

The mature interface for agentic software work will not ask which agent is talking; it will ask which promise is still unsupported by evidence.

The fleet should recede

There is a temptation, especially in the early days of any new tool, to make the tool visible because visibility feels like control. We want to see Agent 4 thinking, Agent 7 patching, Agent 12 blocked. That view is comforting when the system is small. At scale it becomes a cockpit made entirely of tachometers. It reports motion without answering the question the operator actually has: is the work becoming safer, truer, and closer to release?

The end state should be less theatrical. A human should be able to state an objective and receive back a structured account of progress: architecture passed; security requires review; tests passed except for one regression; performance improved by a measured amount; evidence has been generated; merge is waiting on approval. Whether two agents or two hundred participated is operational detail. It should be available for debugging, audit, and cost review. It should not be the main abstraction.

The same distinction applies to remote and mobile use. The important feature is not merely that a person can open a phone and type into a running agent. The important feature is that the person can make a decision from a distance without pretending to be present at the terminal. Approve this. Reject that. Rerun the failed evaluation. Escalate the security finding. Attach the evidence to the review. The remote interface should be a control surface for work, not a tiny window into a shell.

Governance is not an enterprise add-on

The missing layer in many discussions of coding-agent interfaces is governance. That word can sound like paperwork, but in software it is the difference between a change that can be trusted and a change that merely exists. An enterprise does not only need code. It needs to know why the code changed, who or what changed it, which evidence supports the change, which risks remain, which policies were applied, and who had standing to approve the result.

A terminal-first interface tends to treat these as aftermath. The agent writes code; the human later gathers proof. That sequence is backwards. Evidence should be produced as the work proceeds, attached to the relevant node, and made available at the moment of decision. A test result without a link to the change it evaluated is weak evidence. A security scan without the policy version it used is weaker than it looks. A benchmark without the environment and baseline is a number wearing a costume.

The interface should therefore expose a live evidence plane: evaluation, security, licensing, software bill of materials, regression, performance, reproducibility, and approval. Not as decorative badges, but as claims with enough detail to be contested. If a node is green, the operator should be able to ask what made it green. If it is red, the operator should know what failed and what decision is required. If it is gray, the operator should know whether the absence of evidence is acceptable or a blocker.

This is where the work graph becomes more than a nicer dashboard. It becomes the place where autonomy and accountability meet. Agents can come and go. Tools can change. Models can improve. The graph remembers the commitments, dependencies, artifacts, and proofs. It gives the human fewer things to babysit and more things to judge. It reduces cognitive load not by hiding reality, but by arranging reality around the decisions that matter.

Terminals will not disappear. They are too powerful, too universal, and too close to the metal. But they will become what they should have been all along: a debugging instrument, not the principal user interface for autonomous engineering. The main interface will look less like a chat room with many occupants and more like a living case file: objectives, deliverables, dependencies, blocked items, costs, risks, evidence, approvals, and a history that can be replayed when someone asks why the system believed the work was ready.

The real optimization target, then, is not faster conversation with a coding agent. It is lower human cognitive load per unit of trustworthy autonomous throughput. That is a colder sentence than most product copy would allow, but it is the right one. The future belongs to interfaces that let humans supervise the lifecycle of work itself, with enough evidence to trust the machine and enough structure to disagree with it.

— Dispatches · Summit Cognitive