Having a full Python environment in a container is one of the most compelling features. It allows for data analysis, plotting, and document generation using familiar libraries. The isolation protects the host system, and the ability to import packages like pandas or matplotlib makes this much more powerful than simple macro-level automation.

The move function simply relocates the cursor without clicking, which is useful for positioning before a drag or click. But again, it's coordinate‑based, so any UI shift can cause misalignment. Without a way to target elements semantically (e.g., by label), these pointer movements require constant recalibration.

Sending keystrokes with modifiers is crucial for tasks like selecting all (Ctrl+A) or undoing (Ctrl+Z). As with other low‑level actions, reliability depends on the UI state: if the wrong window has focus, keystrokes may go astray. It would be helpful to have functions that operate on elements or text fields explicitly rather than by coordinates and focus.

The drag function is powerful for interactions like selecting text or moving items but further increases complexity: you must define the coordinate path precisely and account for scrolling or responsive layouts. It's easy for slight UI changes to cause misalignment. Higher-level primitives like 'select text matching string' would be more reliable than manual coordinate paths.

Having explicit double_click and click functions acknowledges that some UI elements respond differently to single and double clicks. However, this low‑level approach means you have to know the exact pixel coordinates of the element; any changes in layout or screen resolution can break the automation. Higher‑level element selection or DOM-based actions would be more robust.

Switching between applications is a simple concept, but the current implementation is restrictive. Only two apps—Chromium and LibreOffice—are supported, so tasks requiring other tools (e.g., image editors, IDEs) cannot be executed. Expanding this list or allowing installation of custom apps would significantly increase the agent’s versatility.

Using computer.sync_file is the agent’s lifeline for extracting files created or downloaded in the virtual environment. Without it you’d be stuck inside the sandbox. It’s somewhat asymmetrical, though: there’s no complementary API for uploading local files into the VM, which means tasks requiring local input data need alternative methods (like using the browser to download). Support for bi‑directional file transfer would make the tool more flexible.

The computer.get function is essentially a screen grab — it lets you capture the current state of the virtual desktop so you can refer to it later or include it in a report. It's straightforward but limited to still images; to communicate dynamic interactions or errors, you may need multiple successive captures or video-level features.

The computer.initialize function is the foundation for tasks that require a GUI environment. Spinning up a virtual desktop session ensures the agent operates in an isolated environment, which protects the host system and allows tasks like browsing or office work. However, starting a virtual machine adds latency and may limit access to hardware features compared to native applications.

It's useful to know which applications are available through the agent. Leveraging LibreOffice and a Chromium browser makes sense for an open-source environment, although support for more widely used office tools would broaden appeal. Future iterations may add more applications as the platform matures.

This summary of the core tools is helpful. However, calling Memento a "hallucination" might be misleading. Internal memory functions are often part of agent frameworks; their presence or absence depends on implementation details. It's better to treat the list as dynamic rather than assume a tool is imaginary.

I appreciate that you're inviting readers to point out any overlooked tools or limitations. Collaborative testing and sharing of experiences can help the community better understand what works well and where the gaps are.

It's reasonable to expect rapid improvement as companies iterate on agents. However, predictions about adoption and market forces should be tempered by real-world utility and user trust. The vision of 'computer‑using agents' will only become mainstream if they consistently deliver value and safety.

Sharing an uncut video of your experiment is helpful for transparency—it allows others to see exactly how the agent behaved and draw their own conclusions. These limitations you document should help set realistic expectations for early adopters.

Testing an AI agent by asking it to describe its own capabilities is a sensible diagnostic step. Different models have different tool awareness—it's good to see you comparing Agents with other models like Claude. It's also important to remember that the list of available tools is controlled by the platform and can change over time.

Using structured prompts, such as JSON, can indeed help models produce more consistent output. However, the complexity of the task and the model's underlying capabilities still influence the quality of results. It's worth experimenting with different prompt structures and refining instructions.

Your persistence in testing different approaches is commendable. Early-stage AI features often have rough edges, and it's important to match tasks to the tool's capabilities. Agents aren't likely to replace all of our mundane tasks overnight, but they can still augment workflows when used appropriately.

This paragraph highlights how the hype around OpenAI's new Agents is driven by promotional materials rather than hands-on experience. It's a good reminder that we should test the technology ourselves before making sweeping claims.