OpenComputer turns Slack threads into durable agent sessions
The agent infrastructure product is pushing Slack from notification surface to shared runtime control plane for long-running AI work.
By Ryan Merket ยท Published
Why it matters
OpenComputer is betting that production agents need durable, shared runtime infrastructure, with Slack serving as the collaboration layer rather than a chat add-on.
OpenComputer is pitching Slack as the front door for durable AI agent sessions, giving teams a way to start and steer an agent from a channel thread rather than a local prompt window.
The move, described in an Aligned News post, centers on a developer workflow that OpenComputer says takes three API calls: create an agent, generate a Slack manifest, and connect that agent to Slack credentials. Once installed, a team can @mention the bot in a channel; the first mention starts a durable session, later mentions in the same thread steer that same session, and answers return to the thread.
That is a small product surface with a larger infrastructure bet underneath it. OpenComputer is not selling another Slack bot builder. It is trying to make the agent session itself the durable unit of work, with Slack acting as the shared interface teams already use to argue, approve, correct, and audit decisions.
OpenComputer has published more technical depth in its Slack agent-session docs, which say developers can connect one Slack app per agent, per workspace. The docs describe two setup paths: a guided wizard from the OpenComputer dashboard, or an API flow where developers retrieve a manifest, create the Slack app from it, and finalize the connection with Slack's App ID, Signing Secret, and Bot User OAuth Token.
OpenComputer's routing model is the important part. An @mention is signature-verified, de-duplicated, and appended to a session as a steer. The first mention in a Slack thread starts the session. Later mentions in that thread steer the same one. Session events post back into the Slack thread, while the docs specify that the agent itself does not call Slack directly.
The product bet is persistence
OpenComputer's broader product is long-running cloud infrastructure for AI agents, built around always-on virtual machines rather than disposable sandboxes. Its homepage says each OpenComputer is a real machine with a full filesystem, full OS access, and persistent state. OpenComputer says VMs can resize CPU and memory at runtime, hibernate and resume with state intact, and use checkpoints to fork or restore a machine.
The open-source repo, diggerhq/opencomputer, frames the product in plainer terms: "Long-running cloud infrastructure for AI agents. Real computers, not sandboxes."
The pitch centers on running agents on persistent VMs with a real filesystem, so they can install dependencies, edit files, run processes, and return hours later with state intact. For coding agents and internal operators, that persistence is the core product claim.
OpenComputer contrasts its persistent VMs with ephemeral sandboxes that start from scratch. It says its VMs can hibernate and resume, with checkpoints to fork or restore machines. The goal is to avoid state loss, repeated dependency installs, and timeout recovery work.
Slack makes the session collaborative
The Slack integration matters because it changes who can steer the agent. A single-user chat session keeps control with one operator. A Slack thread exposes the work to a team and lets multiple people participate in the same session history.
That fits how operational AI work is already spreading inside companies. Support teams want agents that can inspect tickets and draft responses. Engineering teams want agents that can triage incidents, query repositories, or test fixes. GTM teams want agents that can prepare account research inside the channels where account executives and managers already coordinate. In each case, the valuable object is not the answer alone. It is the durable work record: who asked, what the agent did, who corrected it, and what answer shipped back.
OpenComputer's docs impose limits that matter for buyers. Anyone who can @mention the bot in a channel it has joined can start and steer the agent. The docs say there is no per-user or per-channel allow-list yet. The bot is mention-only and does not passively follow replies in the thread. Outbound posts include user-level events, while live progress is not yet streamed into the thread.
Those constraints keep the current feature closer to a developer preview than a finished enterprise control plane. They also reveal the road map pressure facing every agent runtime company: once agents enter shared systems of record, access control, auditability, streaming state, and recovery behavior become product requirements rather than back-office implementation details.
OpenComputer is tied to the Digger orbit
OpenComputer's site does not establish a founder roster in the public pages reviewed for this story. It does, however, present the product as "opencomputer by" Digger and routes its homepage's "Speak to founders" link through a Digger team calendar. The GitHub organization is also diggerhq.
The clearest named people in the public materials are authors on OpenComputer's blog. Igor Zalutski has written several OpenComputer posts, including pieces on elastic compute and agent execution. Utpal Nadiger and Mohamed Habib co-authored a March 20th post on where agents should live. Habib is identified on the March 11th OpenComputer blog post "Building an Open Lovable - part 1" as CTO of Digger.
That Digger connection matters because OpenComputer reads less like a generic AI wrapper and more like an infrastructure product from a team already thinking in developer-platform primitives: isolation, filesystem access, runtime behavior, credentials, sessions, and compute pricing.
OpenComputer lists on-demand pricing for a displayed 4 GB memory and 1 vCPU configuration at $0.004 per minute, $0.24 per hour, or $168.72 per month. The homepage says 20 GB of disk is included per VM, with additional disk metered at $0.0000001 per GB-second, about $0.26 per GB-month, billed for the lifetime of the sandbox whether running or hibernated.
OpenComputer says it is built for B2B agent platforms and names Lovable, Devin, and Bolt as examples of products whose users may need persistent computers. Those names are examples on the homepage, not disclosed customers.
The hard part is the governance layer
The Slack feature gives OpenComputer a clean wedge into how teams will actually use agents: less as standalone copilots and more as persistent workers inside shared channels. The session becomes the operational object. Slack becomes the control surface. The VM becomes the place where state survives.
The open question is how quickly OpenComputer can add the controls buyers will expect when those sessions touch company data, credentials, repositories, or customer workflows. Per-user and per-channel controls are already called out as absent in the docs. Live progress streaming is also missing. For a small team testing an agent in a trusted channel, those limits are manageable. For a larger company using Slack as a production work surface, they become procurement questions.
OpenComputer's advantage is that the product starts at the infrastructure layer rather than at the chat interface. A Slack bot can be copied. A durable runtime that preserves files, processes, session events, and recoverable machine state is harder to replace once it sits under production agent workflows.
That is the reason the Slack update is worth watching. OpenComputer is making a claim about where agent work will live. The answer, in its version, is a persistent computer controlled through the tools teams already keep open all day.