Launching today
OpenComputer
The easiest way to deploy a managed agent.
137 followers
The easiest way to deploy a managed agent.
137 followers
The easiest way to deploy a managed agent. Say what your agent should do, paste one prompt into your coding agent, get a live agent URL.
Digger.dev
"managed agent" is doing a lot of work in that tagline - managed by who, exactly? if this is hosting the compute and credentials for an agent that can act on my behalf, what's the blast radius if OpenComputer's own infra gets compromised - does the agent run with scoped, revocable tokens per task, or does it hold onto broad standing access to whatever it's connected to?
The paste-to-live-URL flow is exactly the kind of friction reduction that gets developer adoption. The first thing I would test is credential handling: when an agent needs to call an external API, is there a secrets vault per agent where I can store keys separately from the prompt, or does the prompt itself have to carry them? And can the deployed agent expose an inbound webhook endpoint, so external services like Slack or Discord can push events to it β that is what would make this useful for community tooling rather than just scheduled tasks.
The "beyond sandboxes, always on" combination is the interesting bet, and the risky one. Omri's got the security half, so here's the other one.
A sandbox was quietly doing two jobs. It contained blast radius, and it gave you a free reset. A durable, always-on agent keeps the first problem and loses the second entirely. The failure I'd watch isn't compromise, it's drift: a long-running agent's picture of the world goes stale and it keeps acting confidently against it. On day one it's right. By day five the thing it "knows" and the thing that's true have quietly diverged, and now every action is real, with no sandbox to throw away.
So two questions for a permanent background agent. What does a human see between actions, is there anything that surfaces "still on track" versus just "still running"? And when it does the wrong thing, not malicious, just wrong, what's the undo?
The deploy story is genuinely clean. It's the day-five story I'd want to see.
Congrats on the launch. Durable sessions is the right primitive to build this on.
Adding to the drift point above: what makes a long running agent debuggable is not the sandbox, it is whether each action is replayable after the fact. When something goes wrong on day five you need to answer what the agent believed at that moment and which inputs it saw, not just what it did.
That means the session log has to capture the inputs to each decision, not only the tool calls. Tool call history tells you the agent moved the file. It does not tell you why it thought it should.
Is the session state inspectable and exportable, or does it stay internal to the platform?
the "durable, always-on" part is the interesting bit to me, more than the deploy step itself. if an agent gets stuck in a loop or just keeps working longer than expected, is there a cost ceiling or a way to pause/kill it from outside the session, or do you find out when the bill shows up?
Congrats on the launch. Paste one prompt, get a live agent URL is what got me, that's a genuinely fast path from idea to something live. Curious about that URL itself: does holding the link give you access on its own, or is there a separate auth/token layer in front of it once it's live?