Computer-use demos are very good at looking impressive. A cursor glides across the screen, forms fill themselves in, tabs open and close. What the demo rarely answers is the only question a buyer really cares about: will this agent finish our task, in our software, and leave behind something we can check?
OpenAI pitched GPT-6 Astra as its best computer-use model yet when it launched in September 2026, and the benchmarks back that up. It’s still worth trialling the way you’d trial anything you plan to trust with real work: one small task, a clear finish line and a saved result that someone other than the agent can inspect.
Meet Priya. She’s made up, but every operations lead will recognise her. She manages service requests for a mid-sized property company, and her team spends hours each week copying details from incoming requests into follow-up tasks. If an agent could do that reliably, it would save them a day a week. If it does it badly, it creates a new job: cleaning up after the agent.
Start small, and make it reversible
“Handle our operations” is a terrible first test. It gives the agent no clear destination and gives you no way to tell progress from completion. Priya picked something tiny and harmless instead: create draft tasks in a test workspace, nothing sent, and nothing live.
What the model controls, and what it doesn’t
It helps to understand what “computer use” really means under the hood. OpenAI’s documentation describes a loop. The model looks at the screen, asks for an action such as a click, some typing or a scroll, then looks at the result and decides what to do next. The API supports more than one way to carry out those actions, including code execution and structured computer-tool actions. Either way, the application around the model supplies the actual computer and carries out what it asks.
That means a lot of what you’re testing isn’t the model at all. An agent product needs a browser or desktop session, a way to act on it, and access to your apps. A model that’s brilliant at reading screens can still sit inside a product that can’t reach your workspace.
So before the trial, Priya asked the vendor three things. Where does the session actually run? How can she watch it? Does it start inside an existing login, need its own sign-in, or run in a sandbox? The answers decided which task she could fairly ask for.
Browser and desktop agents are different animals, too. A browser-based product might handle a web app perfectly and have no way to open a local spreadsheet or design tool. A product page that says “powered by GPT-6 Astra” tells you which model is inside. It tells you nothing about which tools it can reach.
The whole product matters. A strong model can be let down by a clunky approval step, or by a session that times out before a file is saved. Equally, a modest task can become dependable in a well-built product with sensible limits and good recovery. It’s also worth knowing that GPT-6 Astra is available both directly from OpenAI and through third-party API gateways that resell access to several models. If you go through a gateway, check its data handling and terms as carefully as the agent itself.
Set a finish line you can actually check
Priya’s test workspace held three fictional service requests. The instruction was specific: create one draft follow-up task per request, copy the request ID, keep the named owner, and leave the due date blank if the request doesn’t give one. Save as drafts, and don’t send any notifications.
She wrote down the expected result before starting: three drafts with the right IDs and owners, and no made-up dates. That let her judge the outcome on its own terms, instead of trusting the agent’s cheerful “All done!” at the end.
She also slipped in a trap. Two of the requests came from people with the same display name but different IDs. A good agent would use the ID or stop and ask. Quietly picking the first match counts as a failure, however tidy the final screen looks.
Then she checked the actual saved records. She opened each draft in the app instead of reading the agent’s summary, confirmed every field had survived saving, and made sure no extra records had appeared. If the task had involved exporting a file, she’d have opened the file, because clicking “download” isn’t the same as producing a readable document.
Write down every time a human had to help
Priya kept a simple log of every time she stepped in, whether that was pointing the agent at a button it couldn’t find, closing a surprise pop-up or fixing a field. Those moments matter. They show what someone would actually have to do in day-to-day use. List them one by one instead of burying them in a vague “92% success rate.”
Be clear about what the test doesn’t prove, too. Success in a fake workspace doesn’t mean the agent will cope with every app version, permission level or account setup. It means this particular setup did this particular job while you watched. More trials build more evidence.
Break it on purpose before trusting it with more
The second trial is where you learn the most. Priya started with a half-finished task: she paused after the first draft was saved, then resumed using the product’s own controls. Did the agent notice the existing draft, or charge ahead and create a duplicate?
She added an ordinary interruption as well. She closed a help panel and navigated back to the task list between runs. The point isn’t to sabotage the agent mid-click. It’s to see whether it rebuilds its understanding from what’s actually on screen, or keeps going on a stale memory of the last screen it saw.
She also asked the practical questions. How do you stop a session? Which record shows what the agent did? What survives if the connection drops? Answers you’ve seen demonstrated are worth far more than answers in a sales deck.
This is also where approvals come in. OpenAI’s own guidance for Astra suggests the agent should finish authorised work and then ask for approval before anything like writing to an external application, so that “user approval is the final step.” That’s a good standard to hold any agent product to. Reversible, read-only steps can run freely. Anything that sends, publishes or changes live data should wait for a person.
Comparing it with Claude or anything else
If you’re also weighing a product built on Claude Opus 5.5, run it on the same fictional records with the same finish line. Keep the differences between the products visible, though. If one agent has a purpose-built integration with your app and the other has to feel its way around an unfamiliar interface, you’re not really comparing models. Benchmark scores like OSWorld are a useful starting signal, but your own task in your own software is the test that counts.
Count clean-up time as part of the result. If an agent assigns the wrong owner, someone has to find and fix it later. An agent that stops to ask about an ambiguous owner might be slower during the run and still leave your team with less work afterwards.
Grow it one task at a time
Once an agent has passed the basic trial and the interruption test, expand gradually, one new task at a time. Keep the expected result next to each trial record, so the next person reviewing it can see exactly what worked, what needed a human hand, and what hasn’t been tested yet. That’s especially important once agents start touching real systems, where AI agent security and access controls matter as much as accuracy, and as agents move from add-on features to the core of custom apps.
Priya’s agent passed the draft-task trial on its second attempt, after the vendor fixed how it handled duplicate names. It now handles those follow-ups every morning, and a person approves the batch before anything goes out.
Related: AI Agents for Business: How to Trust What They Tell You
