Why waste RAM on a lightweight Windows box when you can just

A developer built a remote-execution AI workflow where an LLM agent on a Linux host (Host A) runs Ollama and controls a Windows machine (Host B) via Tailscale SSH, avoiding the need to install AI runtime on the Windows box. The solution uses a Python wrapper that translates high-level agent tool calls (e.g., move_file) into PowerShell commands, preventing the LLM from hallucinating Linux commands on Windows. The author advises defining specific tools instead of a generic shell and explicitly instructing the agent in the system prompt to use PowerShell syntax.

Why waste RAM on a lightweight Windows box when you can just The Setup and the Hurdle The architecture is straightforward: Host A Linux : Runs Ollama + an LLM agent. Host B Windows : Tailscale SSH enabled, no local AI. I wanted to send a command like "Organize the files in my Downloads folder by type and year" to Host A, and have Host A execute the corresponding PowerShell commands on Host B. The main friction point I hit was the environment mismatch. The agent lives in a Linux shell but needs to manipulate a Windows filesystem. If I just give the agent a generic execute shell tool, it tends to hallucinate ls or mkdir commands that fail on Windows, or it gets confused about pathing using / instead of \ . My Diagnosis and Solution After some trial and error, I realized that giving an LLM a raw SSH terminal is a recipe for errors. The agent needs a "bridge" that translates intent into valid PowerShell. To make this work, I moved away from a generic shell and instead defined specific tools for the agent. Instead of "Run this command," I gave it a set of high-level functions that the Python wrapper on Host A handles. For example, I implemented a remote move file tool. When the agent calls it, the backend does this: The agent calls move file source, dest The backend executes: ssh windows-node "powershell -Command Move-Item -Path 'C:\source' -Destination 'C:\dest'" Key Takeaways for this Architecture If anyone else is trying to build a remote-execution AI workflow, here is what I found: Agent Location: Yes, the LLM and agent can stay 100% on the remote machine. The target machine only needs an SSH server Tailscale SSH makes this trivial . Tooling Strategy: Do not use a generic shell tool. Create a "wrapper" layer of tools e.g., list files , move file , read log . This prevents the LLM from guessing the OS syntax and ensures the commands are formatted for PowerShell before they ever hit the wire. Environment Awareness: You have to explicitly tell the agent in the system prompt: "You are controlling a Windows machine via SSH. All filesystem operations must use PowerShell syntax." This approach kept my Windows machine lean while still giving me the power of a local LLM for file management. It's a much cleaner deployment than trying to cram a runtime onto every device in the house. Next SpaceX just bought Cursor and I wonder if this kills the → /en/threads/6474/ these AI tool field notes https://tanyan888.com/ , with plenty of directly applicable cases.