One evening I sat and watched GPT-6 Astra use my computer. I said what should happen on the screen, it looked, it moved the cursor, it clicked. It worked.
My first reaction was not that it was impressive. It was that it was waste.
Then I read what others wrote about the same thing, and there the reaction was the opposite. This was the big one, the proof that something had taken a step. That difference is what this text is about — because I do not think the people who were impressed saw wrong. They saw the same thing I did. They measured it against something else.
What is being demonstrated is that a model can use an interface built for humans. That is an impressive technical feat, and it is at the same time a poor way to work. Both things are true at once, and that is where the confusion comes from. The feat is measured against what models could do last year, and by that yardstick it is large. The way of working ought to be measured against how the same model performs when it is given the right channel, and by that yardstick it is small.
But none of that is visible until you know what the other channel gives you. So I will start there.
How an agent works when you let it
Give an agent a goal and a form it can work in, and you get something with no real equivalent in human work.
It works in parallel. Thirty files are not thirty things to hold in your head; they are a single context. It works without fatigue: the same check on record four hundred is performed exactly as it was on record one, without the drift in attention that makes a human find three errors out of five by mid-afternoon. It works precisely — a comparison against a value is a comparison against a value, not a glance. And it works at machine speed, which is the least interesting of these properties and the one everybody mentions first.
Above all, it can back out. Redoing a step costs almost nothing, which means it can feel its way forward in a manner that is uneconomical for a human being. That property is what lets you give it a goal instead of an instruction.
Put it together and you get a way of working with a cost curve entirely unlike ours. What is expensive for a human — repetition, endurance, precision across volume, starting over — is cheap for the agent. What is expensive for the agent, the judgement about what is worth doing at all and the ability to see when an answer looks right but is wrong, is what we are still here for.
That is the way of working that is worth something. It is also the one you give away.
An interface is a channel built for a mouse pointer
A graphical user interface is not the function. It is the function packaged for a particular recipient.
We forget this, because we are the recipient. A button is an operation that has been given a shape, a position and a colour so that a human being can find it in under a second. A menu is a decision tree folded up small enough to fit in working memory. A hover state exists because a hand can hover. Spatial layout, iconography, grouping, greying out what is inactive — all of it is compression, and the compression is optimised for human perception. Nothing else.
Underneath the interface, the whole time, lies the uncompressed form. The file. The command. The API call. That form is not a simplification of the interface; it is the interface that is a translation of it. To let an agent work through the screen is to let it read a photograph of the spreadsheet instead of the spreadsheet.
But what matters is not that the format is different. What matters is that the format is serial. An interface is built for an operator with a mouse pointer — someone who can do one thing at a time and needs to see the result before the next. And every property from the previous section is lost in that channel, one after another.
Parallelism first: a mouse pointer is by definition one. Thirty files become thirty sequential openings. Endurance next: every step requires a fresh reading of the screen, and every reading of the screen is an opportunity to misinterpret — not because the model is careless, but because inference from pixels is less certain than reading a value. Precision goes the same way. And backing out, which was nearly free, suddenly becomes expensive, because the state now sits in an interface that has no undo button for what the agent just did.
What remains is the speed, and it is worse than a human's.
The important thing is that this is not immaturity. It is easy to read the demonstration as an early stage — slow now, fast later. But the bottleneck is not in the model. It is in the channel. A model twice as fast clicks twice as fast through the same keyhole, and the keyhole is still sized for a hand. You can make the adapter better. You cannot make it into anything other than an adapter.
So the objection is not that the technology is bad. It is that you are paying for an agent and using it as an intern with a mouse.
Why it is still what gets demonstrated
And yet that is the form that gets shown, and the explanation is banal.
You can see it. An agent clicking its way through an interface does something intelligible. We recognise every step, we watch the cursor move towards the field we would have chosen ourselves, we see it hesitate, we see it succeed. We have an internal model of what the same thing costs by hand, and that model fills automatically with meaning.
Effective work does not look like anything at all. A goal is formulated, a command runs, a result exists. There is no cursor to follow with your eyes and nothing that holds interest for thirty seconds.
So a distortion arises. The visible variant wins attention, the useful one wins the work, and those are not the same market. Attention governs what gets demonstrated on stages, what gets cut to thirty seconds, what investors believe the technology is, and ultimately what an operations manager pictures when someone says "AI agent". None of this is new in industry. We have had thirty years of the same thing with visual management boards: the board that looks best during a site visit is rarely the one that changes the most decisions.
So I have no objection to anyone being impressed. I have an objection to the criterion. The question "did it manage it?" has an answer that always becomes yes in time, and therefore stops carrying information. The question that holds is easy to ask and uncomfortable to answer: compared to what?
The order is not a matter of taste
And here I come at it from a different direction than most people writing about agent architecture.
The first thing lean asks about a step in the work is not how to do it faster. It is whether it should exist at all. Eliminate, then simplify, then — only then — mechanise. The order is not a preference. It is a defence mechanism against one particular error: making an unnecessary step permanent by building infrastructure around it.
Because that is what automation does. Manual waste is irritating, visible and cheap to abolish; somebody complains about it every week. Automated waste draws no complaints. It stops hurting. It has an owner, an operating budget, a schedule and a history, and removing it is now a project rather than a decision. The step has gone from being a cost to being an asset on somebody's balance sheet. That is why simplification has to come before mechanisation — not because it is nobler, but because the window closes.
The ladder has three rungs, and AI is the top one. Begin by reducing: cut the work back to what actually adds value, make the process steady, get the routine to hold. Then mechanise: automate the repetitive parts once they are stable — instruments that log the values, scripts that file the records, hard stops that make the wrong move impossible. Mechanisation makes a steady process faster. It never makes an unsteady one steady. And only at the very end let a model in, in the places where recognising a pattern or weighing a case is what the job actually needs, and where the material it has to learn from is already sitting there, clean, because the two rungs below it were built first.
No rung holds unless the one beneath it is in place. Skip one and you get a model trained on process disorder, and the only thing it learns is to produce more of it. Then the model takes the blame, though it is doing exactly what it learned. The disorder was there first. The model only scaled it up.
Computer use automates the human interface. But the human interface is itself a stopgap. It exists because a human being had to reach the function and pixels were the only channel we had. It is not the process. It is the process packaged for a particular operator. When we build an agent that clicks inside that packaging, we have taken a step that existed for human reasons and made it permanent for technical ones.
That is skipping the first two rungs and applying the third to a process nobody has simplified. You never ask whether the click path needed to exist. You only ask whether the model can handle it.
And that is where the two things meet. Automate a click path and it acquires a schedule, an owner and an operating budget — and with them a defence. The waste does not merely remain. It becomes infrastructure, and infrastructure is not abolished, it is maintained.
Where there is no way in
And then the counter-picture, which matters just as much, because without it the rest is a hobbyhorse.
Computer use is right when there is no other way in. Not "when it is more convenient". When there is none.
That situation is not marginal in manufacturing. It is the normal state. An MES with no export beyond the one report somebody once ordered. A PLC vendor's proprietary tool where the data exists but only inside their own window. A machine HMI that displays ten parameters in real time and passes none of them on. A web service with no API, or with an API that costs more than the problem. A system whose vendor went bankrupt and whose integration nobody can order any more.
In every one of those cases the uncompressed form is not available. It exists — it is sitting there, three layers down — but it is locked behind an interface that is the only door. Then an agent reading the screen is not a detour. Then it is the bridge across what cannot be bridged, and it may be the only thing that makes an analysis possible without a six-month integration project.
The difference between the two cases is easy to state and uncomfortable to answer: is there another way in? If yes, the interface route is a choice — and almost always a worse one. If no, it is the only route, and then the question is no longer which architecture is most elegant but whether the bridge holds.
What I run myself
I have more reason than most to be honest here, because my own work is evidence in both directions.
Three things I have built work every day: a publishing pipeline for this site, a memory system that holds context across sessions and machines, and analysis work on production data. All three are driven the same way. I formulate a goal, I supply the necessary context, and the work is carried out against files, against commands, against APIs.
The concrete case is clearest in the first. One edition touches some thirty files across three language versions, and everything has to be internally consistent: the same articles in all three feeds, the same dates, no untranslated headings left behind, no link pointing at yesterday's file. That is exactly the kind of check a human does sloppily at eleven at night and an agent performs identically on file one and file thirty. It does not open them one at a time to look at them. It has them.
The analysis work behaves the same way. The same check on every row of a measurement series, and when something looks wrong it can back out and rerun with a different boundary without costing an afternoon. Speed is not the point there. The point is that you dare to try a third and a fourth hypothesis, because being wrong is no longer expensive.
None of it would have worked through screen clicks. Not "would have been slower" — would not have worked.
And then there is the exception, and it is exactly the exception the counter-picture describes: the only place in my entire setup where a model actually drives an interface is a browser inside a nightly job. The reason is not one of principle. There is no API. The source has no other way in, and what I need from it is worth the bridge. It is also the only component that breaks regularly — a nightly job clicking its way through an interface will sooner or later meet a dialogue box that was not there yesterday, and then it stands still until somebody wakes up.
I have learned to read that as a signal rather than a problem. When I notice that I am about to put a model in front of a screen, it usually says something about the system on the other side — that it lacks a way in that ought to have existed. Sometimes that conclusion is worth more than the data I was after.
The question is not the one we ask
I do not think computer use is going away, and I do not think it should. There is too much locked-in function in the world for a general adapter to become unnecessary, and in manufacturing especially.
But it is an adapter. It is the answer to a format, not to a task. And the fact that it looks like work — that it is the only form of AI work a human can follow with their eyes and recognise — makes it neither more capable nor less costly.
What I saw that evening was a model doing something difficult in a way that made it harder than it needed to be. That is no accusation against the model. It did exactly what I asked, and it did it well. It was the task that was badly framed, and I was the one who framed it.
The interesting question about a demonstration is not whether the model can manage it.
It is whether that is how it should be done.