Computer use can end support’s broken telephone

Support has an instruction relay problem

Consider this exchange. The support agent knows which setting to change. The customer is looking at a slightly different version of the application.

Each turn translates the same problem into a different form: a screen into a description, a description into a mental picture, a proposed fix into instructions, and those instructions back into actions. A hidden menu, a renamed label, or a different window size can break the chain.

That is the broken-telephone experience. Both people can be careful and capable, yet spend most of the conversation establishing where they are. The customer is doing the navigation, interpretation, and reporting while also dealing with the original problem.

A longer help article or a faster chatbot reply can still leave this entire relay in place. For a routine interface task, the experience can be much more work than allowing a trusted helper to inspect the screen and carry out the agreed change.

A shared screen gives the conversation a common reference

Usability research gives us a reason to take that translation cost seriously. Nielsen Norman Group’s explanation of recognition and recall describes how visible choices and contextual cues make information easier to retrieve. In support, a person may have to hold an instruction in mind while hunting for the control it describes. Keeping the relevant screen in view can reduce some of that burden.

There is also evidence about shared visual context. In a 2004 study by Darren Gergle, Robert Kraut, and Susan Fussell, pairs solving visual puzzles coordinated more efficiently when they shared an immediate view of the workspace. Delayed views reduced the benefit. It was a small laboratory study of human collaboration, so its results are evidence for the value of shared context, not a measured business case for AI support.

Human remote-support tools already put that idea to work. Microsoft’s Remote Help documentation, for example, distinguishes between viewing a device and requesting full control. Seeing the same interface can help a support person locate the problem; permission to act lets them carry out a change.

Computer use builds on that familiar pattern. The opportunity is to let an AI system work from the interface itself, so the customer has fewer steps to translate and perform.

Why we think computer use is the future of support

Computer use connects understanding to action. A model receives the current screen, proposes an interaction, and gets a new view after the system executes it. Google’s computer-use documentation describes this loop explicitly: screenshot, proposed UI action, execution by the application, and an updated screenshot.

For support, that creates a different starting point. The customer can say, “Help me select the microphone for this call.” A capable agent can inspect the actual application, navigate its controls, make a permitted change, and help run a test. A different layout becomes something to observe, rather than another set of directions the customer must decode.

We believe computer use will become a core part of customer support because it lets support work on the problem where it appears: the customer’s interface. Routine settings, application setup, and other bounded tasks are promising places to start. The customer supplies the goal and the context that only they know; the system takes on more of the mechanical navigation.

This is our view of the direction of support, not a prediction established by the sources above. A reliable API can be the best way to make a particular change. Computer use is useful when the work is exposed through an interface, including workflows that cross several applications. Its practical value depends on whether it can complete those workflows reliably and with less effort for the customer.

The customer should understand and control the help

Delegating clicks changes the responsibility of the support system. It needs to explain what it will do, obtain access deliberately, stay within the agreed task, and make stopping easy. A person should be able to watch the work, answer a question, reject a consequential action, or take over.

Current computer-use systems can make mistakes. Google’s documentation warns about errors and security vulnerabilities in the capability and recommends close supervision for important tasks. A screen can also contain misleading instructions. Treating everything on it as permission would turn a useful support session into a source of new problems.

That is why guardrails and tests belong in the support experience. Restrict the task’s scope, decide which actions require approval, and stop or hand off when the system cannot proceed with confidence. Good support includes a clear path to a person who can exercise judgment.

Guidance still has a place. A customer may want to learn a workflow, prefer to keep control, or need help with a decision rather than a setting. The useful choice is whether they want an explanation, help carrying out a task, or both.

Prove the fix before closing the ticket

A convincing completion message does not establish that the microphone works. The test is a call or a recording the customer can actually hear. Define that outcome before the agent starts.

Compare a computer-use workflow with your current support process on the same kinds of tasks. Include setup and connection time, unsuccessful attempts, approvals, and human intervention. Measure:

• Checked resolution: did the intended result occur, and did it persist after reopening the application?
• Customer effort: how much active time, navigation, repetition, and explanation did the person contribute?
• Recovery: what happened when the control was missing, the layout changed, or the first attempt failed?
• Control: did the system respect scope, denied approvals, and the customer’s request to stop?

Repeat those checks across the operating systems and application versions you support. An eval makes a case repeatable: a starting state, a task, and a check of the resulting state. Runtime guardrails govern actions during the task; evals test whether the whole workflow behaves as intended.

The evidence that matters is a customer getting back to work with less friction and an acceptable rate of errors. An impressive demo is a useful starting point for that measurement.

Try one support task with Eager

Eager gives support teams a way to describe a task in plain language and have an agent work on a connected Mac or Windows PC. The customer installs the app, explicitly clicks Connect, and can watch and stop the task. They do not need an Eager account.

Start on a test computer with a small, reversible task, such as changing an app preference. Configure the agent’s scope and approval rules, then check the result yourself. Guardrail coverage differs by platform: site rules currently require a supported Mac, and Windows action-category approvals rely on the agent’s own requests.

Use Eager’s evals to repeat the task from fresh machine states and inspect the outcome. Include a variation the agent should finish and one it should stop or hand off. If you are embedding this in your product, the computer-use API connects sessions and tasks to your own support workflow.

The next time a customer needs help finding a setting, give them a way to delegate the navigation. Let them describe what they want to accomplish, stay in control, and check that it worked.