13 ms·
This idea of remotely hosting the agent harness is honestly backwards to what I need. In so many cases, all the friction is about how to provision access to lo
by zmmmmm 6d ago
This idea of remotely hosting the agent harness is honestly backwards to what I need.
In so many cases, all the friction is about how to provision access to local data so the agent can work. So you started with the problem of how do I integrate an agent that is running locally with data that is hosted locally, and you have to deal with a bunch of security, data sensitivity and management issues around that. Now you moved the agent to a remote host - pretty much all your problems are worse: now I have a remote agent reaching into my infrastructure to deal with.
I'd much rather the inverse of this: let me run the agent local but provide secure remote hosted sandboxes. That actually solves a real problem because the sandbox running locally means breaking out of it directly intersects your local infra, whereas if it runs in a managed hosted environment I can leave the provisioning and management of that to someone else.
- tokioyoyo 6d agoThe end goal is not you watching what the agent is doing, verifying, then accepting its changes. In the ideal scenario of automation, the agent does it on your request, doesn't matter wherever you are. Kind of slack-button-click-to-fix-something workflow.
- hunterbrooks 5d agoThe self hosted workers solve this use case. The control plane sits in OAI's cloud, but the actual tool calls are executed in your worker fleet. The main problem with this approach is that tool arg's get sent over the wire, and those often contain code/data.