The Interface Is Shaping How We Use AI
We open an AI, ready to hand it a difficult task. In the input box, we type, “Help me redesign the homepage,” and hit send. It quickly comes back with questions. What style do we want? Which pages should change? How should it work on mobile? Are there any reference sites? Should it read the code first?
Every question is reasonable. The trouble begins when we answer them one at a time. As soon as we settle the color palette, it asks about typography. Once we have explained the homepage, it wants to confirm the navigation. The screen keeps scrolling, and we remain in front of it. Work we meant to hand off turns into a remote operation that requires our constant supervision.
I have come to think that the model is only partly responsible for many of the problems people encounter when using agents. The narrow chat box is also teaching us how to behave.
The chat box breaks work into fragments
Chat boxes are well suited to questions and answers. One person says something, the other replies, and faster replies usually make the experience feel better. A small input field, a send button that is always lit, and answers appearing word by word on the screen all urge us to say something quickly, wait for a response, and then say something else.
Complex work needs a different rhythm. Someone taking on a coding task needs to know at least why the change is being made, how far it should go, and what must remain untouched. They also need to know what counts as done. The relevant code, designs, earlier discussions, and test commands need somewhere to live. Once they have read the material, they need an uninterrupted stretch of time to make changes, run them, fail, and revise.
A chat box encourages us to send an incomplete sentence first and fill in what is missing later. The task is then split across many rounds of conversation. Every few steps, the agent comes back with a question; every so often, the person switches back to the window to check it. The model may be working continuously, but the person’s attention is scattered by these small interruptions.
When the result is poor, people often blame the prompt and start learning about role definitions, ways to express constraints, and an assortment of prompting techniques. Those techniques are genuinely useful. Yet the same person will often write much more completely when they switch to email. They know the recipient will not reply at once, so they provide the background in advance, attach files, state the deadline, and explain what kind of result they expect.
Their writing ability did not suddenly improve. The interface changed their expectations.
Write the task as a letter
Some people now deliberately write as if they were composing an email, even inside a chat box. They begin with a complete brief, provide the repository and file paths, attach reference material, list what must not be changed, and explain how the work will be evaluated. Then they close the window and let the agent read the code, edit the files, and run the tests on its own. It pauses to ask only when it encounters a tradeoff that requires a human decision.
This way of working feels somewhat awkward. We buy an agent capable of carrying out tasks, then have to resist the cues of the product interface and remind ourselves not to type half a sentence as if we were chatting.
A brief that can be handed to an agent does not require an elaborate format. It only needs to answer a few practical questions.
Start by explaining why the work needs to be done. Then say what the final deliverable should be and which changes are out of scope. Point the agent to the code, documentation, and reference material, and specify checks it can run. For ordinary details, allow it to follow the repository’s existing conventions and continue. It should come back to a person only when the answer would materially change the product’s direction, introduce a security risk, or require an irreversible action.
This already resembles delegation in everyday work. A manager does not ask a colleague to report back after changing every line. The manager explains the goal and the person’s authority, agrees on which situations must be escalated, and reviews the result at the end. If an agent has its own workspace and can read materials, modify files, and run tests, it should work at the same pace.
A good agent interface should let people leave
The agent interface I would like to see would combine a task inbox with a workbench.
The task inbox would receive the brief, attachments, and acceptance criteria. The workbench would preserve execution status, code changes, test results, and key decisions. After sending a task, the person could leave. The agent would work quietly and return the result when it was done. If it became blocked, it would come back with the material it had already found and a sufficiently specific question, sparing the person from having to reconstruct the entire context.
Such a product would not need to hide its process. Logs, file changes, and intermediate artifacts could still be available without requiring anyone to watch them continuously. The statuses need not be complicated either. In progress, awaiting a decision, and ready for review would usually be enough. People would remain responsible for direction, tradeoffs, and final acceptance, while constant monitoring could disappear.
This would also change how we judge whether a product is good. Chat products tend to value response speed, the number of conversational turns, and how long users stay. Task-oriented agents should aim for fewer interruptions, less hands-on time from people, and a higher rate of complete delivery on the first attempt. When someone sends a task, goes off to do something else, and returns later to review it, that is evidence that the tool has actually taken the work off their hands.
Once a person uses several agents at the same time, the problem with chat boxes becomes even clearer. With a dozen windows taking turns surfacing questions, the user quickly becomes the busiest message dispatcher of all. What they need then is a unified task list and a mechanism for reporting exceptions. Agents should handle routine choices according to the agreed rules and notify a person only when they exceed the budget, lack permission, or cannot determine the intent.
Chat still has its place
Chat works well for discussing an idea, asking a follow-up question, or jointly working through a problem that has not yet taken shape. At the start of a task, a person and an agent may also need a few rounds of conversation to settle on a direction. Once the direction is clear, the work should move into execution. Chat is one stage of the process; it does not need to encompass the whole thing.
We have spent a long time learning how to talk to AI. Now we can practice giving a complete brief at once: provide enough material, agree on boundaries and acceptance criteria, and allow ourselves to step away from the screen.
To evaluate such an interface, ask whether users can submit a task once, leave the page, and return only when a genuine decision is needed. When that is possible, the chat box no longer dictates the rhythm of the entire job.
This essay was inspired by Yage’s article, “The Chat Box Illusion.”
https://yage.ai/share/chat-box-illusion-agent-interface-20260710.html