The framing is wrong, and it's wrong in a way that leads teams to bad designs. Capability and control are not on the same axis. You can buy one and keep the other, and the systems that work well in practice are the ones that do exactly that.

This is an attempt to write down the split properly, because "hybrid" has become a word that means nothing.

Two different things called "the AI"

Start by separating the two components people collapse together.

The model is a computational artifact running on hardware you will never touch, priced per unit of work, improving on a cadence you don't control. It is fundamentally a rented capability, and attempting to own it is a category error for almost every organisation. The economics are brutal and the depreciation is worse.

The workspace is where the data lives while the model operates on it: the filesystem, the running applications, the credentials, the session. This is not rented capability. It's the actual boundary of your system, and it's the thing you should be designing.

Nearly every failure I've seen in this space comes from treating the second as an implementation detail of the first. The model gets chosen carefully. The workspace is whatever laptop was available.

Designing the workspace layer

Three properties matter, in this order.

1. A bounded reachable set

The security property that survives contact with reality is not "the tool is trustworthy." It's "the tool cannot reach what isn't there." Every other control is downstream of this one, because every other control depends on assumptions about behaviour, and this one doesn't.

In practice this means the workspace is provisioned with a specific set of data for a specific purpose, and nothing else is present. Not "nothing else is permitted" — nothing else is present. Permission systems fail. Absence doesn't.

2. A defined lifetime

A workspace that exists indefinitely accumulates. After two quarters, the environment provisioned for one engagement holds fragments of four, and the bounded reachable set you designed has quietly become unbounded again.

The fix is to make destruction part of the workflow rather than a cleanup task nobody schedules. Environments are created for a piece of work and destroyed when it completes. Snapshots handle the "I need to go back to how it was on Tuesday" case without keeping the environment alive forever.

3. An explicit egress path

If the workspace is disposable, the outputs must be written somewhere that isn't. This sounds obvious and is the step teams most often leave implicit, which is how you end up with someone frantically trying to recover a report from an environment that was torn down that morning.

Name the destination. Make writing to it a step in the process, not an afterthought.

Why the unit is a desktop and not a container

For pipeline work, containers are the correct primitive and this whole discussion is unnecessary.

The reason a heavier unit keeps showing up is the software that holds the data. A large share of real business records sit inside Windows applications — accounting suites, practice management systems, industry-specific line-of-business tools — that assume an interactive desktop session, a persistent user profile, sometimes licensing bound to a machine identity. They do not decompose into a stateless process, and forcing them to is a project in itself.

So the workspace unit becomes a full cloud-hosted Windows desktop: reachable from any device, provisioned per purpose, disposable. Not because it's architecturally elegant, but because it's the smallest unit that actually holds the software the work depends on.

A worked example

A firm processing client financials during an engagement:

• Provision a desktop. Install the accounting package and nothing else.
• Load only that client's documents. The other twelve clients are not on this machine and cannot be reached from it.
• Point AI tooling at the folder. The model runs remotely; the data stays in the workspace; the reachable set is one client's records.
• Write deliverables to the firm's document system — an explicit, logged step.
• Snapshot at milestones. Destroy at completion.

The staff member reaches all of this from a MacBook or a Chromebook. Their own machine never holds client material, which means it never enters scope for any question about client material.

The two constraints that decide adoption

Everything above is uncontroversial once written down. The reason it isn't ubiquitous comes down to two operational facts, and neither is about architecture.

Provisioning time. The pattern requires standing up environments freely — per engagement, per purpose, sometimes per week. If each one is a project (a quota request, an image to build, a console to learn) it will not happen, and the team goes back to using the laptop. The decision has to be reversible in minutes. At Infosaic Technologies this is zero: you sign up, the login arrives by email, and the desktop is there. Nothing to provision, nothing to wait for.

Billing model. Usage-based pricing makes every new environment a small financial decision, and small financial decisions made repeatedly turn into "just use your laptop, it's fine." The architecture loses to the expense process. Flat-rate pricing removes that friction: a fixed cost per environment per month, no hourly meter, so provisioning is a technical decision rather than a budgetary one. Infosaic desktops are flat from \(14.95/month, or \)11.95/month billed annually.

I'll disclose the obvious conflict of interest — this is what we sell. But test your own platform against the question regardless: does the billing model, or the setup time, make the correct architecture the expensive one? If either does, you will not get the correct architecture, no matter what the design document says.

Summary

Rent the intelligence. Own the workspace. Give the workspace a bounded reachable set, a defined lifetime, and an explicit egress path. Choose a platform where standing one up costs minutes and a predictable amount of money.

The model you're using will be replaced within the year. The boundary you draw around your data will outlive several of them.

About Infosaic Technologies. Infosaic Technologies has delivered managed Windows virtual desktops from the cloud since 2001. Delivery is instant — you sign up and the login lands in your inbox, so provisioning time is zero. Plans are flat-rate from \(14.95/month, or \)11.95/month billed annually, with no hourly metering, full administrator rights, a dedicated IP and a pre-activated Windows licence. Support is included, and a person answers.

More on virtual desktop configurations, pricing and provider comparisons: infosaic.com/virtual-desktop-resources

Infosaic Technologies, LLC · 175 South 3rd St, Suite 200 #1008, Columbus, OH 43215 · 614-855-7084

Most writing about running computer-use agents locally frames the risk as security. That framing is correct and incomplete. There is a second constraint, and in daily practice it bites first: an agent and its operator cannot share a host, because they value time differently and they contend for the same input devices.

I want to lay that out properly, because once you see it as a resource-contention problem the answer stops being a matter of preference.

Two properties of computer-use agents

I ran two agents against production-adjacent work for a month — Claude via computer use, and an open-source agent driven by Grok — specifically to separate product behaviour from category behaviour. Two properties held across both.

Property one: the agent's time budget is effectively unbounded

An agent has no opportunity cost. It is not aware of the work queued behind the current task. It does not get bored, hungry, or impatient. So it will happily spend minutes on activity that a human would skip:

• Settling waits. After navigation or a click, it polls until confident the resulting state is stable.
• Start-up latency per action. Small individually, additive across a long task.
• Re-orientation. When the screen does not match expectation, it stops and re-establishes where it is.
• Read-back verification. The one that surprised me most. Filling a form, the open-source agent enumerated every dropdown, read the options, then captured a screenshot to persist the values so it could assert them later.

None of this is a defect. It is exactly what you want from something operating unsupervised. But it means the agent optimises for correctness with no regard to elapsed time, because elapsed time is not a cost it experiences.

Property two: the agent's action space is identical to yours

This is the part that turns a slowness annoyance into a hard constraint.

A computer-use agent does not run as a background process with its own I/O. It drives the same primitives you do — pointer, keyboard, window focus. It uses your real browser profile with your real sessions. Window activation is inside its action space.

The consequence: while the agent runs, the host is not busy, it is claimed. And intervening is not merely rude, it is unsafe — you cannot reliably predict its next target, and a stray click mutates the state it believes it is operating on.

Composing the two properties

Put them together:

The agent will hold the host for an unbounded duration, and you cannot use the host while it does.

That is the finding. Not "agents are slow." Not "be careful." A structural incompatibility between two processes contending for one set of input devices, where one process has infinite patience and the other has a support queue.

You can verify this on your own setup in an afternoon. Instrument two numbers: host occupancy (wall-clock minutes the agent holds input control) and verification ratio (fraction of actions that are read-back rather than mutation). If occupancy is a meaningful fraction of your working day, timesharing is already costing you more than it saves.

The resolution

Separate hosts. The agent gets its own machine.

Its verification loops continue exactly as before — they simply stop being your problem, because they are no longer happening on the device you are trying to work on. Occupancy on your machine drops to zero.

Requirements for the agent's host are unremarkable: a reliable Windows environment, the applications the agent drives, availability during the agent's runs. No GPU, no unusual memory.

Two selection criteria are less obvious than they look.

The first is provisioning time. If standing up the agent's machine is a project — a quota request, an image to build, a console to learn — you will not do it, and you will go back to timesharing. The decision has to be reversible in minutes. Infosaic delivers this at zero: you sign up, the login arrives by email, and the desktop is there. Nothing to provision, nothing to wait for.

The second is billing model. Agents generate far more billable activity than a human performing the same task — retries, waits, verification passes — so metered compute makes your monthly cost a function of how thorough the agent chooses to be. That is an unpleasant variable to carry. Flat-rate hosting eliminates it. Mine run on Infosaic cloud desktops, flat from $14.95/month, though the principle applies whatever you choose: on this workload, predictable pricing beats low hourly pricing.

Open question

I have not found a satisfying account of how anyone runs agents and their own work on a single machine successfully. If you have a working arrangement — a scheduling discipline, a virtualisation setup, something I have not considered — I would like to hear it, because the contention above looks structural to me and I would be glad to be wrong.

About Infosaic Technologies. Infosaic Technologies has delivered managed Windows virtual desktops from the cloud since 2001. Delivery is instant — you sign up and the login lands in your inbox, so provisioning time is zero. Plans are flat-rate from \(14.95/month, or \)11.95/month billed annually, with no hourly metering, full administrator rights, a dedicated IP and a pre-activated Windows licence. Support is included, and a person answers.

More on virtual desktop configurations, pricing and provider comparisons: https://www.infosaic.com/virtual-desktop-resources/

Infosaic Technologies, LLC · 175 South 3rd St, Suite 200 #1008, Columbus, OH 43215 · 614-855-7084

What changes when an agent gets input primitives

A language model reading a document is a content-layer actor. Give the same model screenshot, pointer and keystroke primitives against a live desktop session and it becomes an OS-layer actor. Its effective privilege stops being "the text you pasted" and becomes the transitive closure of everything reachable from that session:

• cookie jars holding live authenticated sessions
• OS and browser credential stores
• the entire local filesystem the user account can read
• any desktop client already signed in, including mail, accounting, VPN and chat
• whatever those clients can reach on the network

That last one matters more than people expect. A workstation inside a corporate VPN extends the agent's reach to internal hosts that were never part of the plan.

Why prompt injection stops being a content problem

Injection against a chat model produces bad text. Injection against an agent with input primitives produces bad actions, executed with the operator's ambient authority and without a confirmation step. The payload does not have to come from the user: it can sit in a webpage the agent browses, a PDF it opens, an email it triages, or a calendar entry it reads while summarizing a week. A crafted calendar event leading to code execution through an agent loop has already been demonstrated publicly.

Anthropic's own operator guidance says the quiet part directly: run computer use in a sandboxed environment, with no saved credentials, and treat prompt injection as an OS-level vulnerability. That is vendor documentation telling you not to run it on your daily machine.

Why a container is the wrong primitive

The instinct for isolation is a container. It does not fit this workload:

1. The agent drives GUI applications. Accounting packages, Office, line-of-business software with no API. That is the entire reason computer use exists, because if there were an API you would call the API.
2. A container gives you process isolation without a usable display server, so you end up bolting on a virtual display, a window manager and a remote-desktop transport just to reach parity with a plain VM.
3. Most of the target software is Windows-only, which puts you outside the comfortable part of the container ecosystem immediately.

The workload wants a disposable desktop. Provision a disposable desktop.

The architecture

Per agent, not per user. One agent, one machine.

1. Separate infrastructure from the operator's device. No shared filesystem, no credential passthrough, no mapped drives back to the laptop. The isolation is worthless if you mount your home directory into it.
2. Minimal install surface. Only the applications inside the agent's task scope. Every extra installed app is additional reachable state during an injection.
3. A dedicated browser profile containing only the logins the agent is authorized to use. Never a copy of the operator's profile, because copying the profile copies the session cookies and defeats the whole exercise.
4. Snapshot before each run, roll back on anomaly. Recovery becomes a rollback rather than a forensic investigation. This is the highest-value control on the list and the one people skip.
5. Least-privilege network egress where the platform allows it. If the agent needs one SaaS host and one internal app, it does not need general outbound access.
6. Always-on, because scheduled agent work should not depend on a laptop lid being open.

Failure modes worth planning for

• Silent partial completion. The agent believes it finished; it clicked the wrong confirmation. Snapshots plus an output diff catch this. Trusting the agent's own summary does not.
• State drift. An agent that installs a helper tool or changes a setting makes the next run non-reproducible. Re-image from snapshot between runs if the task matters.
• Credential creep. Someone signs into "just one more" service inside the agent's browser profile to unblock a task. Audit the profile periodically. This is how the blast radius quietly grows back.

The cost argument, which is what makes it real

Isolation proposals usually die on budget. This one does not, because the machine is cheap.

Inference happens at the model provider. The desktop is a thin GUI host: no GPU, no large RAM allocation, no specialized hardware. A flat-rate managed Windows desktop, ours start at $14.95 a month, typically costs less than the AI subscription driving it. That is what moves per-agent isolation from a security team's wish list into something a solo practitioner actually does.

Compare that to hourly metered instances on a hyperscaler, where an agent that runs longer than expected produces a bill nobody budgeted for. Predictable pricing is not a minor convenience here. Unpredictable pricing is what kills these pilots before they prove anything.

Who actually adopts this

Not the enterprises with security teams, because they already have VDI. The adopters are solo accountants processing client documents, small law firms with confidentiality obligations, freelancers with one laptop they also need for calls, and remote workers who do not want to gamble a corporate machine. People with real exposure and no IT department to delegate it to.

The heuristic

Treat the agent as a junior hire rather than a browser tab. You would not hand a new employee your personal laptop with every password saved in it. You would give them a machine with scoped access and the ability to reimage it. Everything above follows from taking that comparison literally.

About Infosaic Technologies

Infosaic Technologies has delivered managed Windows desktops in the cloud since 2001: flat-rate pricing from $14.95/month, real human support, and desktops that just work. No hourly metering, no surprise bills.

More virtual desktop guides, comparisons and pricing breakdowns: infosaic.com/virtual-desktop-resources

Get started: infosaic.com

Infosaic Technologies, 175 South 3rd St, Suite 200 #1008, Columbus, OH 43215 | Phone: 614-855-7084

Facebook | LinkedIn