Why Are We Still Giving AI Agents the Wrong Interface?

Almost all AI programming and Agent tools today default to a chat window (like Cursor, Claude Code). But from an efficiency standpoint, this interaction pattern—mimicking WeChat or Slack—is seriously limiting AI’s true potential.

Whether an interface is truly AI-native depends not on which model it connects to, but on whether the default human behavior it induces actually allows AI to perform at its best.

In fact, graphical interfaces are imposing invisible discipline on both sides:

1. On the user: The narrow chat box limits input volume, encouraging lazy typing, leaving the AI in a state of severe information starvation.
2. On the development architecture: To match the rhythm of instant chat, tool developers force the Agent to stop and ask questions at every small branch, constantly reporting micro-progress—thus robbing the AI of the quiet time it needs to silently compile, test, and self-correct in a sandbox. The AI is forcibly molded into an impatient chat partner.

This leads to a bizarre phenomenon: the hardcore engineers who use AI best are essentially “pretending to write emails” inside a chat box—they paste in thousands of words of specs, hand it absolute paths and demand it run tests on its own, then close the window after sending, cutting off any expectation of an instant reply.

The answer may have existed all along in ancient management practices: writing task briefs (emails), keeping process traces (local Git & Markdown), and reviewing outcomes (Review mode).

We wrote a detailed analysis exploring the chat box illusion, power users’ reverse arbitrage, and the asynchronous collaboration workflow of “Post Office vs. Office Desk”:

The Chat Box Illusion: Why Are We Still Giving AI Agents the Wrong Interface?

Source: https://yage.ai/share/chat-box-illusion-agent-interface-20260710.html?utm_source=twitter&utm_medium=thread&utm_campaign=chat-box-illusion-agent-interface-20260710 ← Table of Contents (https://yage.ai/share/) EN (https://yage.ai/share/chat-box-illusion-agent-interface-en-20260710.html) Deep News Superlinear Academy (https://superlinear.academy/) AI Agent AI Programming

In today’s developer tools—whether Cursor, Codex, or Claude Code—the default interface is almost always a narrow chat window. You type a line in a terminal or editor, watch the logs start scrolling on screen, then wait for the AI to spit out a modification plan and ask if you’re satisfied.

This input-scroll-query dialogue mechanism seems to lower the barrier as much as possible. But from the perspective of human-AI collaboration efficiency, this imitation of human chat software is actually limiting AI’s true potential.

I. The Ideal State of Human-AI Collaboration

To understand the interface problem, we need to return to the ideal state of human-machine collaboration.

Imagine you have a reliable subordinate. The most efficient way to work is: you assign the task, and they go off and do it, solving the problem at a high quality. You don’t need to stand behind them watching them type, nor answer a stream of trivial questions every few seconds.

To achieve this state of letting AI work autonomously, the system must satisfy three prerequisites:

1. Detailed task description and acceptance criteria: The AI must know what you want done and how to verify the result.
2. Supporting materials and non-prompt context: For complex tasks, the AI needs to reference a large amount of background information (e.g., project codebase, historical preferences, local documents). This material is too large to squeeze into a single-line input box, requiring other access channels (e.g., attachments or local workspace paths).
3. Asynchronous waiting expectation: The AI needs to read through all the context, write code, compile, run tests, and debug repeatedly—this can take minutes or even tens of minutes. You must allow it to slow down, establishing an expectation that after sending the task, you go do something else.

II. How the Interface Silently Shapes User Expectations

When tuning models, we always talk about how to write prompts. But many overlook that the interface itself constantly writes prompts to humans, silently shaping our expectations of the product.

There’s an easily overlooked logical flaw: the AI itself is a piece of running code—it can’t see the graphical interface. So how is it affected by a chat box?

The truth is, the interface influences both the programmer who designs the tool and the user who uses the tool, collectively restricting the AI’s autonomous workspace from both ends.

• Discipline imposed on the user (input side): The size of the input box, the blinking of streaming output, the always-lit send button—these interaction details hint to humans: type shorter, I’ll reply immediately, you can interrupt anytime. This makes us instinctively type only one vague short command (e.g., “change the homepage layout”). Low input quality isn’t because people are lazy—it’s because the interface induces laziness. In a state of information starvation, the AI can only guess when generating code.
• Mental lock on designers (development side): Because tool designers assume it’s a chat software, they design the Agent’s backend to match the rhythm of chat. To accommodate the fast pace of instant dialogue, developers command the Agent to stop and ask questions at every detail branch, frequently report progress to humans, and output text with minimal latency. This directly robs the AI of the quiet time needed to silently compile, run tests, and self-verify in a sandbox. It is forcibly molded into an impatient chat partner.
• Continuation of REPL interaction (contract lock): Even with Claude Code on the command line, the essence of human-machine interaction remains a question-answer loop. The user’s psychological expectation set by the chat box is transplanted verbatim: humans are still tied to the screen, constantly checking status and typing corrections, trapped in a vicious cycle of micromanagement.

This dual discipline from both ends constitutes the inherent limitation of the chat window (see Figure 1). Whether an interface is AI-native depends not on the latest model it connects to, but on whether the default human behavior it induces actually allows AI to perform at its best.

Figure 1: Invisible constraints of the chat box on user behavior and development architecture

III. Reverse Arbitrage: Top AI Users Are All Pretending to Write Emails

Observing engineers who truly use AI as a super-amplifier reveals an interesting phenomenon: when they use a chat box, they actively fight its default cues.

• They don’t send just one sentence. Instead, they jam a thousand-word requirement, complete code files, and API specs into the input box.
• They actively hand the AI a local path, telling it: “Read the code in this directory, run the tests, think it through, then answer.”
• After clicking send, they actively close the window, go write documentation or grab coffee, forcibly breaking their expectation of an instant reply.

These arbitrageurs are essentially using a chat box with an email mindset.

But this highlights an absurd situation: to get advanced AI to do good work for us, we have to pretend we’re writing emails inside a chat box. So why not just give AI an email interface directly?

IV. The Answer Lies in Management: Why Email Specifically?

Email has been popular in the business world for half a century because it was inherently designed for asynchronous collaboration, and it aligns perfectly with the three prerequisites for AI work:

• Email body: Naturally corresponds to a detailed task description and success criteria. Because the expectation when sending an email is that the recipient will reply in hours or even days, it forces you to think carefully and state your intent clearly in one go.
• Attachments and codebase references: Naturally correspond to non-prompt context. You don’t need to paste thousands of lines of code into a conversation; just drag in reference files and design diagrams, or attach a Git repository link. For a local personal Agent, you can even write the absolute path to the local workspace as credentials authorizing it to access the physical hard drive.
• Inbox mentality: Naturally corresponds to asynchronous waiting. After clicking send, you go do something else. This gives the AI valuable quiet execution time, allowing it to compile, run tests, and self-correct without interruption.

This is essentially transferring the mature manager-subordinate reporting structure from human organizations to the digital world:

Assign task (write task brief / send email) → Process trace (Git Repo / Markdown) → Blocking escalation (interrupt only when over budget / safety boundary triggered) → Outcome review (Review Markdown report)

In practice, we should adopt the mindset that code is consumable: when encountering non-fatal decision branches, the AI should make assumptions and follow through, not stop to ask. The computing cost of an AI mistake is extremely low, while the cost of interrupting a human’s thought process and forcing a context switch is extremely high.

Recently, we’ve seen the emergence of Manus’s email task entry and startups like AgenticMail. This convergent evolution shows that email is being rediscovered because it’s currently the only ready-made digital infrastructure that can carry this asynchronous management workflow.

V. Cognitive Inertia and Business Metric Mindset

If asynchronous collaboration and high-context input are more reasonable, why do almost all products on the market use chat boxes?

There are two bottlenecks:

1. Cognitive inertia of chat: Because it’s called “artificial intelligence,” our first reaction is “to talk with it.” We easily equate intelligence with conversation, so chatbots become the most intuitive solution. Email sounds like an ancient dinosaur and is overlooked by most developers.
2. Business metric inertia: Big companies designing AI products often inherit the metrics of the mobile internet era: DAU, user activity, dwell time. But a truly efficient Agent tool has the opposite experience: the less time humans spend in the interface, the better—send the task and leave. This metric conflict restricts the creation of asynchronous productivity products that truly free human attention. Of course, as Agent capabilities improve, this outdated metric setting will eventually be broken.

VI. The Endgame: Post Office vs. Office Desk

In engineering implementation, we don’t need to tear down everything and rebuild. We just need to split the information flow and control plane into two interfaces: Post Office and Office Desk (see Figure 2).

• Post Office – Mail flow: Responsible for task assignment and delivery reports. You send complex task requirements to the Agent’s dedicated mailbox, then close the mailbox.
• Office Desk – Shared workspace: After receiving the email, the Agent silently creates a branch in the workspace, runs code and tests, and leaves traces all in the workspace’s task status file (e.g., task.md).
• Review tool (e.g., iOS client): Abandons the chat form entirely, only managing task status: Working (silently executing), Ready to Review (done, notify human to review), Archived (filed away).

Figure 2: Asynchronous collaboration architecture of Post Office and Office Desk

When the number of Agents grows to dozens, even reading reports becomes a burden. Then the interface will evolve again toward an executive dashboard—defaulting to silent progress, only routing exceptions like budget overruns or permission violations. But first, we need to free the AI from the micromanagement of the chat box.