Adding an AI agent to Slack sounds appealing to many enterprises — but, as VentureBeat has experienced ourselves first hand — the reality is often far more complex and clunkier than it first seems.
Now NanoCo., the company behind the hit open source, enterprise-friendly, autonomous AI agent harness NanoClaw (a more sandboxed, lower code version of OpenClaw), is hoping to make it just as easy as typing a Slack message. To go one step further: the company’s new NanoClaw Slack integration lets human users spin up entire teams of agents with their own specialized skills, workflows, and even custom avatars, all from a single Slack prompt.
«In the next 12 to 18 months, everyone on a team will be a manager of agents,» NanoCo CEO and co-founder Gavriel Cohen told VentureBeat in an exclusive interview.
Furthermore, the NanoClaw agents can work together in channels and shared Slack Canvases, and can even be messaged outside of Slack on other platforms like Telegram or WhatsApp, letting their human colleagues ping them across messaging platforms, just as they would their fellow humans.
“I think this is agents arriving natively in Slack for the first time,” Cohen added. “In the past, you had to do all these weird things to try to have multiple different agents behind the scenes using the same bot, and now every agent gets its own identity in Slack — its own avatar, its own face, its own name. You can tag them. They can tag each other.”
For enterprise teams, the more consequential part is persistence and separation. NanoClaw is not presenting the additional workers as invisible subagents that disappear after one task. Each can be given its own role, memory context, instructions and permissions, creating a structure closer to a small digital department than a single chatbot with a long prompt.
As with the original open source version of NanoClaw released in January 2026, developers and enterprises can further choose whichever underlying large language model (LLM) they wish to power their NanoClaw agents, optimizing for performance, cost, or other combinations of factors.
From a single NanoClaw Slack agent to a whole specialized team
For a new installation, NanoClaw’s current setup process starts by cloning the project and running its nanoclaw.sh installer, which walks the user through dependencies, credentials, building the agent container and pairing a first messaging channel. NanoClaw’s website says the installer takes a user “from a fresh machine to a named agent you can message,” with Slack among the supported channels.
Cohen described the Slack-specific flow to VentureBeat as a significant simplification over building a traditional Slack bot. Previously, he said, a user would have to navigate Slack’s administrative and developer interfaces, create an app, collect secrets, API keys and tokens, and then move those credentials into wherever the bot was running.
With the new integration, the NanoClaw setup instead offers a Connect Slack option. The user names the agent, authenticates, chooses the NanoClaw Add to Slack option and goes through Slack’s installation and authorization flow. Once authorized, the first agent can appear in Slack and begin communicating with the user.
The important distinction is that this initial authorization is largely a one-time workspace connection. Slack’s Marketplace listing says users “connect a workspace once,” after which NanoClaw can provision each additional agent as its own Slack bot, complete with its own name, generated avatar and identity.
Those agents continue running on the customer’s infrastructure and connect to Slack over Socket Mode. NanoCo says it does not store the agents’ Slack tokens; according to the Marketplace listing, those tokens remain on the user’s machine.
Slack’s standard administrative controls still sit around that system. Organizations can apply their normal app-approval policies to the NanoClaw integration, while NanoClaw’s Marketplace listing says the app’s Home tab displays the agents provisioned in a workspace and lets users revoke individual agents or disconnect the workspace entirely.
The result is less a one-click replacement for NanoClaw’s underlying infrastructure than a one-time bridge between that infrastructure and Slack: users still own and operate the agent runtime, but once the bridge is authorized, the agents themselves can create and coordinate additional Slack-native colleagues without sending the user back through manual app configuration each time.
Behind the scenes, Cohen said, the lead agent has a Model Context Protocol (MCP) tool that can create new agents and define their instructions, personas, skills and tools; another tool can place them into shared rooms. The agents come prepared to work with Slack Canvas and can communicate with every human user on the Slack Channel, and with one another.
The interaction itself is deliberately simple. Rather than opening a separate agent builder every time a new role is needed, Cohen said users can tell the agent they already have what kind of colleague or team they want.
“Your agent in Slack, you can say, ‘Create me another agent to handle my code reviews. Create another agent to review the contributor articles. Create a team of agents that reviews contributor articles from different perspectives.’ And then your agent can create new agents, and they just pop up in the sidebar and send you messages.”
That means a developer could ask for a product manager, architect, implementation agent, code reviewer and testing agent, then give each a different toolset and have them hand work between one another. Cohen said the testing agent, for example, could have access to a testing environment while the review agent carries code-review-specific skills and the product agent monitors user feedback.
Cohen argues that this division of labor is more than cosmetic role-playing. “There are advantages in terms of giving each one specific skills, instructions, and tools for different tasks,” he said. “I can have, let’s say, a code review agent, a code testing agent, a code writing agent, and I can have them in a loop.” If the implementation agent runs into an ambiguity, he added, it can tag the product or architecture agent for clarification rather than forcing one general-purpose model to hold every responsibility and tool in the same context.
Agents work together with humans on a share Slack Canvas
A supplied demo screenshot shows the same pattern applied to marketing: a lead agent named Nano creates Atlas for strategy, Sage for content, Echo for social, Scout for outreach and Compass for SEO and analytics. The agents introduce themselves in the same Slack conversation and begin coordinating work, with Atlas noting that it had added an item to Canvas so the task would not get lost.
Users do not have to specify every detail up front. Cohen said someone could give the lead agent exact review procedures, priorities and required tools, or leave more of the configuration to the agent based on its existing context and memory.
The design also tries to avoid a familiar multi-agent failure mode: bots endlessly triggering one another. NanoCo says the agents reply only when tagged, while comments left on work in Canvas can be routed back to the agent responsible for that piece.
And the model can extend beyond teams of task-specific bots created by one person. Cohen described a workplace where individual employees each have persistent agents that can communicate with one another under human-defined policies.
“Each person having their own agent means that I could have my agent and you have your agent in Slack, and your agent can ask my agent questions,” he said. “Maybe I’m out of the office for the day. Your agent can ping my agent and ask a question about availability, and I can set some policies about whether my agent can answer or if I need to give approval.”
That pushes the concept closer to organizational delegation: some agents specialize by function, while others effectively represent individual employees and the context they have accumulated. Cohen said the agents can be equipped with browser and internet access, memory, coding capabilities and other tools, while newly created agents arrive with built-in support for Canvas work, agent-to-agent communication and spawning still more agents.
Slack is opening the door to more third-party agents
The underlying Slack change is broader than NanoClaw.
In April, Slack, a Salesforce product, announced the ability to add external AI agents to the messaging platform directly, initially pointing to Vercel and Lovable and saying those integrations were coming in late May.
Slack said the deployment mechanism automates OAuth, manifest configuration and environment setup so an externally built agent can be brought into the workspace without being rebuilt specifically for Slack.
Salesforce’s newly published Slack Code page now names NanoClaw alongside Lovable, Hyperagent, Superhuman, n8n, Vercel, ChatGPT, LangChain, Runlayer and Skydive, and says Add to Slack can bring agents from those platforms into Slack in a few clicks with their own identity.
Slack is already crowded with AI assistants. OpenAI, for example, lets ChatGPT workspace agents be deployed into Slack channels, where they can answer questions, perform tasks through connected systems and output files. Slack also supports Claude and custom Agentforce agents. NanoClaw’s differentiation is therefore not simply “AI in Slack.” It is the ability for an already-running agent to create additional, independently addressable teammates from inside the conversation itself. NanoCo calls that a first for Slack; that specific market-first claim is the company’s.
“Add to Slack means one message can spin up a full team of NanoClaw agents, working right alongside people in Slack,” Josh Milas, director of product management at Slack, said in the supplied announcement.
How NanoClaw differs from Claude Tag, ChatGPT agents and Agentforce in Slack
NanoClaw is not alone in trying to turn AI from a sidebar chatbot into something resembling a persistent Slack colleague.
Anthropic’s Claude Tag, which began rolling out in beta to Claude Team and Enterprise customers in June, may be the closest conceptual comparison.
Administrators can give @Claude access to selected channels, tools, data sources and codebases; everyone in the channel can then delegate work to it by tagging it. Claude remembers relevant information from the channels it inhabits, can work asynchronously over hours or days, and, when administrators enable its “ambient” behavior, can proactively flag information or revive unresolved work without waiting for another prompt.
Anthropic says separate Claude identities can also be scoped to different use cases so that, for example, a sales Claude does not share its memories or tools with an engineering Claude.
The difference is in how those digital coworkers are provisioned and organized. Claude Tag’s documented workflow is administrator-led: admins pair Claude with Slack, decide which channels, tools and information each Claude identity can access, set spending limits and then expose those identities to employees.
Within a given channel, Anthropic describes “one Claude that interacts with everyone.” Its public documentation does not describe an end user asking that Claude to create several new, independently named Slack bots on demand. NanoClaw’s model is almost inverted.
After an organization connects its NanoClaw installation to Slack once, NanoClaw says an existing agent can itself provision additional agents from a conversational request, with each new worker receiving its own Slack bot identity, name, generated avatar and token and running back on the customer’s infrastructure.
OpenAI’s ChatGPT Workspace Agents occupy another point on that spectrum.
Business, Edu and Enterprise customers can build reusable agents in ChatGPT, give them instructions, models, files, apps, custom MCP connections and schedules, and then attach those agents to Slack channels.
Builders assign each agent a unique Slack handle and can configure it either to respond only when mentioned or to respond automatically to relevant messages in a channel.
But the construction still happens primarily through ChatGPT’s agent builder: OpenAI’s setup documentation tells users to create the agent first and then add Slack as a channel. Under the hood, the Slack handles rely on Slack user groups managed by the ChatGPT Agents app, rather than NanoClaw’s model in which every provisioned agent is itself a separate Slack bot.
Salesforce’s Agentforce similarly allows organizations to create multiple specialized agents that employees can DM or @mention inside Slack, and it arguably provides the most conventional enterprise administration model of the group.
Companies build the agents in Agentforce Builder, often starting from Slack-specific templates for jobs such as customer insights, employee help or onboarding, and can add subagents and actions that let them search information, create Canvases or perform other work.
Once configured and activated in Salesforce, administrators bring those agents into Slack for employees to use. That makes Agentforce powerful for organizations already centering identity, data and workflows on Salesforce, but again places agent creation before deployment rather than making creation itself something an existing Slack agent can perform during a conversation.
That distinction helps clarify what NanoClaw is actually adding to an increasingly crowded market. Slack itself now provides an Agent Kit for developers and a deployment standard for agents built on outside platforms, automating pieces such as OAuth, manifests and environment configuration. Claude Tag, ChatGPT Workspace Agents and Agentforce all demonstrate that persistent, specialized AI teammates inside Slack are no longer novel on their own.
NanoClaw’s more unusual bet is recursive provisioning: Slack becomes not merely the place where workers invoke agents, but a place where an existing agent can assemble additional named agents, assign them roles and put them together in a channel as a working team.
There are tradeoffs to the different approaches. Claude Tag comes with Anthropic-managed models and centralized administrative controls, including channel-specific permissions, audit logs and token-spending limits, while also offering proactive “ambient” behavior that NanoClaw’s supplied materials do not claim in the same way.
ChatGPT Workspace Agents offer a managed agent builder, schedules, app connections and organization-level publishing and access controls. Agentforce ties agents closely to Salesforce permissions, enterprise data and predefined business actions.
NanoClaw instead emphasizes self-hosting, open-source modification and separate agent identities, shifting more control — and more operational responsibility — to the organization running it.
The result is less a direct replacement for those systems than a different answer to the same emerging question: whether enterprises want a small number of centrally configured AI assistants, or an environment in which employees and existing agents can continuously create specialized digital colleagues as new work appears.
How NanoClaw got here
NanoClaw began far from the enterprise collaboration market. Cohen, a former Wix engineer, launched it under the MIT License on Jan. 31, 2026, as a deliberately small, security-focused alternative to OpenClaw.
The original pitch was that a personal agent with access to messages, files and tools should run inside an OS-isolated container rather than directly on the host, and that the orchestration layer should remain small enough for a developer or security team to understand — an initial core of roughly 500 lines of TypeScript and a design centered on container isolation and a minimal single-process architecture.
The project then moved steadily toward enterprise infrastructure. In March, NanoClaw partnered with Docker to run agents inside Docker Sandboxes, using stronger MicroVM-backed isolation for workloads that may install packages, modify files and launch processes.
In April, NanoClaw 2.0 added Vercel’s Chat SDK and OneCLI’s credential gateway, allowing organizations to define policies around sensitive actions and require human approval before credentials are injected for protected requests.
By May, Cohen and his brother Lazer Cohen had formed NanoCo around the project and raised a $12 million seed round led by Valley Capital Partners, with Docker, Vercel, monday.com and others participating. The commercial strategy is to keep NanoClaw open source while selling managed, organization-wide deployments and “professional assistant” infrastructure to enterprises. The company now says NanoClaw has surpassed 250,000 downloads and 30,000 GitHub stars.
That open-source structure remains central to Cohen’s pitch as NanoClaw moves deeper into workplace infrastructure.
“You’re really able to now integrate an open-source agent into Slack that you fully control,” he said. “You can change all those configurations. Plus, you can fork NanoClaw and completely rewrite or change behaviors — create your own memory system, your own coding harness, agent harness. Whatever you want to do, you can do. Total freedom.”
Persistent agents, but infrastructure stays under the user’s control
Cohen said NanoClaw remains self-hosted: an organization can run it on a local machine or its own cloud VM, with agent data stored there.
The same agent can also appear across Slack, WhatsApp or Telegram while retaining the same memory, workspace and tools, although each messaging surface uses a separate session.
NanoClaw can pull recent context across those sessions so the agent can maintain continuity without merging every chat history into one stream. NanoClaw’s documentation likewise describes a multi-channel architecture in which the same agent can retain one workspace and memory while maintaining separate per-channel sessions.
“This is all self-hosted,” Cohen said. “You’d be running this on your computer or on your virtual machine in the cloud, and that data is stored on your computer or on your [virtual machine] VM. This could be an open-source model running on your Mac Mini, and your data isn’t going anywhere besides your Mac Mini and then into Slack.”
The cross-channel continuity is also intended to make an agent feel less like a Slack-specific bot and more like a persistent colleague that happens to be reachable through Slack.
Cohen said the same agent could exist in Telegram, WhatsApp and Slack with access to the same memory, files and tools. The conversations remain separate sessions, but they share a workspace and persistent context so the agent can carry knowledge from one surface to another.
That architecture matters when an organization starts creating many agents. Cohen said one agent can see its own sessions across channels, but not another agent’s private sessions by default. NanoClaw’s current documentation likewise describes agents running in their own sandboxes and configurable model providers, with Claude Code as the default and Codex, OpenCode and local Ollama models available as alternatives.
There is one cloud dependency for the new Slack flow. Cohen said NanoCo operates a small service that handles Slack provisioning requests and avatar generation. He said it does not receive users’ messages or agent memory.
Continued commitment to open source
NanoCo is not charging for this community Slack capability, according to Cohen, and is absorbing the provisioning-service and avatar-generation costs. Users can still incur their own model inference and hosting expenses, so that does not make a deployed agent team cost-free in practice.
NanoCo says the integration is available through the Slack Marketplace, subject to normal workspace app approval and governance. Slack says workspace owners and administrators can require apps to be approved before installation.
Cohen framed that decision as part of NanoCo’s broader open-source strategy rather than a standalone monetization play. “We’re not making any money off this one. This one is for the community, really,” he said. “We know that in the long run that’s going to benefit NanoCo as a company. As NanoCo grows and builds out capabilities, those go back to the open source. I think that’s the new model of open source, where we’re not trying to monetize every bit of value we bring to the community.”
Whether companies get there that quickly will depend less on how easily agents can be created than on whether IT teams can govern their permissions, memory, spending and failure modes at the same pace. NanoClaw is betting that the next problem is managing the digital coworkers that appear once that barrier is gone.
Adding an AI agent to Slack sounds appealing to many enterprises — but, as VentureBeat has experienced ourselves first hand — the reality is often far more complex and clunkier than it first seems.
Now NanoCo., the company behind the hit open source, enterprise-friendly, autonomous AI agent harness NanoClaw (a more sandboxed, lower code version of OpenClaw), is hoping to make it just as easy as typing a Slack message. To go one step further: the company’s new NanoClaw Slack integration lets human users spin up entire teams of agents with their own specialized skills, workflows, and even custom avatars, all from a single Slack prompt.
«In the next 12 to 18 months, everyone on a team will be a manager of agents,» NanoCo CEO and co-founder Gavriel Cohen told VentureBeat in an exclusive interview.
Furthermore, the NanoClaw agents can work together in channels and shared Slack Canvases, and can even be messaged outside of Slack on other platforms like Telegram or WhatsApp, letting their human colleagues ping them across messaging platforms, just as they would their fellow humans.
“I think this is agents arriving natively in Slack for the first time,” Cohen added. “In the past, you had to do all these weird things to try to have multiple different agents behind the scenes using the same bot, and now every agent gets its own identity in Slack — its own avatar, its own face, its own name. You can tag them. They can tag each other.”
For enterprise teams, the more consequential part is persistence and separation. NanoClaw is not presenting the additional workers as invisible subagents that disappear after one task. Each can be given its own role, memory context, instructions and permissions, creating a structure closer to a small digital department than a single chatbot with a long prompt.
As with the original open source version of NanoClaw released in January 2026, developers and enterprises can further choose whichever underlying large language model (LLM) they wish to power their NanoClaw agents, optimizing for performance, cost, or other combinations of factors.
From a single NanoClaw Slack agent to a whole specialized team
For a new installation, NanoClaw’s current setup process starts by cloning the project and running its nanoclaw.sh installer, which walks the user through dependencies, credentials, building the agent container and pairing a first messaging channel. NanoClaw’s website says the installer takes a user “from a fresh machine to a named agent you can message,” with Slack among the supported channels.
Cohen described the Slack-specific flow to VentureBeat as a significant simplification over building a traditional Slack bot. Previously, he said, a user would have to navigate Slack’s administrative and developer interfaces, create an app, collect secrets, API keys and tokens, and then move those credentials into wherever the bot was running.
With the new integration, the NanoClaw setup instead offers a Connect Slack option. The user names the agent, authenticates, chooses the NanoClaw Add to Slack option and goes through Slack’s installation and authorization flow. Once authorized, the first agent can appear in Slack and begin communicating with the user.
The important distinction is that this initial authorization is largely a one-time workspace connection. Slack’s Marketplace listing says users “connect a workspace once,” after which NanoClaw can provision each additional agent as its own Slack bot, complete with its own name, generated avatar and identity.
Those agents continue running on the customer’s infrastructure and connect to Slack over Socket Mode. NanoCo says it does not store the agents’ Slack tokens; according to the Marketplace listing, those tokens remain on the user’s machine.
Slack’s standard administrative controls still sit around that system. Organizations can apply their normal app-approval policies to the NanoClaw integration, while NanoClaw’s Marketplace listing says the app’s Home tab displays the agents provisioned in a workspace and lets users revoke individual agents or disconnect the workspace entirely.
The result is less a one-click replacement for NanoClaw’s underlying infrastructure than a one-time bridge between that infrastructure and Slack: users still own and operate the agent runtime, but once the bridge is authorized, the agents themselves can create and coordinate additional Slack-native colleagues without sending the user back through manual app configuration each time.
Behind the scenes, Cohen said, the lead agent has a Model Context Protocol (MCP) tool that can create new agents and define their instructions, personas, skills and tools; another tool can place them into shared rooms. The agents come prepared to work with Slack Canvas and can communicate with every human user on the Slack Channel, and with one another.
The interaction itself is deliberately simple. Rather than opening a separate agent builder every time a new role is needed, Cohen said users can tell the agent they already have what kind of colleague or team they want.
“Your agent in Slack, you can say, ‘Create me another agent to handle my code reviews. Create another agent to review the contributor articles. Create a team of agents that reviews contributor articles from different perspectives.’ And then your agent can create new agents, and they just pop up in the sidebar and send you messages.”
That means a developer could ask for a product manager, architect, implementation agent, code reviewer and testing agent, then give each a different toolset and have them hand work between one another. Cohen said the testing agent, for example, could have access to a testing environment while the review agent carries code-review-specific skills and the product agent monitors user feedback.
Cohen argues that this division of labor is more than cosmetic role-playing. “There are advantages in terms of giving each one specific skills, instructions, and tools for different tasks,” he said. “I can have, let’s say, a code review agent, a code testing agent, a code writing agent, and I can have them in a loop.” If the implementation agent runs into an ambiguity, he added, it can tag the product or architecture agent for clarification rather than forcing one general-purpose model to hold every responsibility and tool in the same context.
Agents work together with humans on a share Slack Canvas
A supplied demo screenshot shows the same pattern applied to marketing: a lead agent named Nano creates Atlas for strategy, Sage for content, Echo for social, Scout for outreach and Compass for SEO and analytics. The agents introduce themselves in the same Slack conversation and begin coordinating work, with Atlas noting that it had added an item to Canvas so the task would not get lost.
Users do not have to specify every detail up front. Cohen said someone could give the lead agent exact review procedures, priorities and required tools, or leave more of the configuration to the agent based on its existing context and memory.
The design also tries to avoid a familiar multi-agent failure mode: bots endlessly triggering one another. NanoCo says the agents reply only when tagged, while comments left on work in Canvas can be routed back to the agent responsible for that piece.
And the model can extend beyond teams of task-specific bots created by one person. Cohen described a workplace where individual employees each have persistent agents that can communicate with one another under human-defined policies.
“Each person having their own agent means that I could have my agent and you have your agent in Slack, and your agent can ask my agent questions,” he said. “Maybe I’m out of the office for the day. Your agent can ping my agent and ask a question about availability, and I can set some policies about whether my agent can answer or if I need to give approval.”
That pushes the concept closer to organizational delegation: some agents specialize by function, while others effectively represent individual employees and the context they have accumulated. Cohen said the agents can be equipped with browser and internet access, memory, coding capabilities and other tools, while newly created agents arrive with built-in support for Canvas work, agent-to-agent communication and spawning still more agents.
Slack is opening the door to more third-party agents
The underlying Slack change is broader than NanoClaw.
In April, Slack, a Salesforce product, announced the ability to add external AI agents to the messaging platform directly, initially pointing to Vercel and Lovable and saying those integrations were coming in late May.
Slack said the deployment mechanism automates OAuth, manifest configuration and environment setup so an externally built agent can be brought into the workspace without being rebuilt specifically for Slack.
Salesforce’s newly published Slack Code page now names NanoClaw alongside Lovable, Hyperagent, Superhuman, n8n, Vercel, ChatGPT, LangChain, Runlayer and Skydive, and says Add to Slack can bring agents from those platforms into Slack in a few clicks with their own identity.
Slack is already crowded with AI assistants. OpenAI, for example, lets ChatGPT workspace agents be deployed into Slack channels, where they can answer questions, perform tasks through connected systems and output files. Slack also supports Claude and custom Agentforce agents. NanoClaw’s differentiation is therefore not simply “AI in Slack.” It is the ability for an already-running agent to create additional, independently addressable teammates from inside the conversation itself. NanoCo calls that a first for Slack; that specific market-first claim is the company’s.
“Add to Slack means one message can spin up a full team of NanoClaw agents, working right alongside people in Slack,” Josh Milas, director of product management at Slack, said in the supplied announcement.
How NanoClaw differs from Claude Tag, ChatGPT agents and Agentforce in Slack
NanoClaw is not alone in trying to turn AI from a sidebar chatbot into something resembling a persistent Slack colleague.
Anthropic’s Claude Tag, which began rolling out in beta to Claude Team and Enterprise customers in June, may be the closest conceptual comparison.
Administrators can give @Claude access to selected channels, tools, data sources and codebases; everyone in the channel can then delegate work to it by tagging it. Claude remembers relevant information from the channels it inhabits, can work asynchronously over hours or days, and, when administrators enable its “ambient” behavior, can proactively flag information or revive unresolved work without waiting for another prompt.
Anthropic says separate Claude identities can also be scoped to different use cases so that, for example, a sales Claude does not share its memories or tools with an engineering Claude.
The difference is in how those digital coworkers are provisioned and organized. Claude Tag’s documented workflow is administrator-led: admins pair Claude with Slack, decide which channels, tools and information each Claude identity can access, set spending limits and then expose those identities to employees.
Within a given channel, Anthropic describes “one Claude that interacts with everyone.” Its public documentation does not describe an end user asking that Claude to create several new, independently named Slack bots on demand. NanoClaw’s model is almost inverted.
After an organization connects its NanoClaw installation to Slack once, NanoClaw says an existing agent can itself provision additional agents from a conversational request, with each new worker receiving its own Slack bot identity, name, generated avatar and token and running back on the customer’s infrastructure.
OpenAI’s ChatGPT Workspace Agents occupy another point on that spectrum.
Business, Edu and Enterprise customers can build reusable agents in ChatGPT, give them instructions, models, files, apps, custom MCP connections and schedules, and then attach those agents to Slack channels.
Builders assign each agent a unique Slack handle and can configure it either to respond only when mentioned or to respond automatically to relevant messages in a channel.
But the construction still happens primarily through ChatGPT’s agent builder: OpenAI’s setup documentation tells users to create the agent first and then add Slack as a channel. Under the hood, the Slack handles rely on Slack user groups managed by the ChatGPT Agents app, rather than NanoClaw’s model in which every provisioned agent is itself a separate Slack bot.
Salesforce’s Agentforce similarly allows organizations to create multiple specialized agents that employees can DM or @mention inside Slack, and it arguably provides the most conventional enterprise administration model of the group.
Companies build the agents in Agentforce Builder, often starting from Slack-specific templates for jobs such as customer insights, employee help or onboarding, and can add subagents and actions that let them search information, create Canvases or perform other work.
Once configured and activated in Salesforce, administrators bring those agents into Slack for employees to use. That makes Agentforce powerful for organizations already centering identity, data and workflows on Salesforce, but again places agent creation before deployment rather than making creation itself something an existing Slack agent can perform during a conversation.
That distinction helps clarify what NanoClaw is actually adding to an increasingly crowded market. Slack itself now provides an Agent Kit for developers and a deployment standard for agents built on outside platforms, automating pieces such as OAuth, manifests and environment configuration. Claude Tag, ChatGPT Workspace Agents and Agentforce all demonstrate that persistent, specialized AI teammates inside Slack are no longer novel on their own.
NanoClaw’s more unusual bet is recursive provisioning: Slack becomes not merely the place where workers invoke agents, but a place where an existing agent can assemble additional named agents, assign them roles and put them together in a channel as a working team.
There are tradeoffs to the different approaches. Claude Tag comes with Anthropic-managed models and centralized administrative controls, including channel-specific permissions, audit logs and token-spending limits, while also offering proactive “ambient” behavior that NanoClaw’s supplied materials do not claim in the same way.
ChatGPT Workspace Agents offer a managed agent builder, schedules, app connections and organization-level publishing and access controls. Agentforce ties agents closely to Salesforce permissions, enterprise data and predefined business actions.
NanoClaw instead emphasizes self-hosting, open-source modification and separate agent identities, shifting more control — and more operational responsibility — to the organization running it.
The result is less a direct replacement for those systems than a different answer to the same emerging question: whether enterprises want a small number of centrally configured AI assistants, or an environment in which employees and existing agents can continuously create specialized digital colleagues as new work appears.
How NanoClaw got here
NanoClaw began far from the enterprise collaboration market. Cohen, a former Wix engineer, launched it under the MIT License on Jan. 31, 2026, as a deliberately small, security-focused alternative to OpenClaw.
The original pitch was that a personal agent with access to messages, files and tools should run inside an OS-isolated container rather than directly on the host, and that the orchestration layer should remain small enough for a developer or security team to understand — an initial core of roughly 500 lines of TypeScript and a design centered on container isolation and a minimal single-process architecture.
The project then moved steadily toward enterprise infrastructure. In March, NanoClaw partnered with Docker to run agents inside Docker Sandboxes, using stronger MicroVM-backed isolation for workloads that may install packages, modify files and launch processes.
In April, NanoClaw 2.0 added Vercel’s Chat SDK and OneCLI’s credential gateway, allowing organizations to define policies around sensitive actions and require human approval before credentials are injected for protected requests.
By May, Cohen and his brother Lazer Cohen had formed NanoCo around the project and raised a $12 million seed round led by Valley Capital Partners, with Docker, Vercel, monday.com and others participating. The commercial strategy is to keep NanoClaw open source while selling managed, organization-wide deployments and “professional assistant” infrastructure to enterprises. The company now says NanoClaw has surpassed 250,000 downloads and 30,000 GitHub stars.
That open-source structure remains central to Cohen’s pitch as NanoClaw moves deeper into workplace infrastructure.
“You’re really able to now integrate an open-source agent into Slack that you fully control,” he said. “You can change all those configurations. Plus, you can fork NanoClaw and completely rewrite or change behaviors — create your own memory system, your own coding harness, agent harness. Whatever you want to do, you can do. Total freedom.”
Persistent agents, but infrastructure stays under the user’s control
Cohen said NanoClaw remains self-hosted: an organization can run it on a local machine or its own cloud VM, with agent data stored there.
The same agent can also appear across Slack, WhatsApp or Telegram while retaining the same memory, workspace and tools, although each messaging surface uses a separate session.
NanoClaw can pull recent context across those sessions so the agent can maintain continuity without merging every chat history into one stream. NanoClaw’s documentation likewise describes a multi-channel architecture in which the same agent can retain one workspace and memory while maintaining separate per-channel sessions.
“This is all self-hosted,” Cohen said. “You’d be running this on your computer or on your virtual machine in the cloud, and that data is stored on your computer or on your [virtual machine] VM. This could be an open-source model running on your Mac Mini, and your data isn’t going anywhere besides your Mac Mini and then into Slack.”
The cross-channel continuity is also intended to make an agent feel less like a Slack-specific bot and more like a persistent colleague that happens to be reachable through Slack.
Cohen said the same agent could exist in Telegram, WhatsApp and Slack with access to the same memory, files and tools. The conversations remain separate sessions, but they share a workspace and persistent context so the agent can carry knowledge from one surface to another.
That architecture matters when an organization starts creating many agents. Cohen said one agent can see its own sessions across channels, but not another agent’s private sessions by default. NanoClaw’s current documentation likewise describes agents running in their own sandboxes and configurable model providers, with Claude Code as the default and Codex, OpenCode and local Ollama models available as alternatives.
There is one cloud dependency for the new Slack flow. Cohen said NanoCo operates a small service that handles Slack provisioning requests and avatar generation. He said it does not receive users’ messages or agent memory.
Continued commitment to open source
NanoCo is not charging for this community Slack capability, according to Cohen, and is absorbing the provisioning-service and avatar-generation costs. Users can still incur their own model inference and hosting expenses, so that does not make a deployed agent team cost-free in practice.
NanoCo says the integration is available through the Slack Marketplace, subject to normal workspace app approval and governance. Slack says workspace owners and administrators can require apps to be approved before installation.
Cohen framed that decision as part of NanoCo’s broader open-source strategy rather than a standalone monetization play. “We’re not making any money off this one. This one is for the community, really,” he said. “We know that in the long run that’s going to benefit NanoCo as a company. As NanoCo grows and builds out capabilities, those go back to the open source. I think that’s the new model of open source, where we’re not trying to monetize every bit of value we bring to the community.”
Whether companies get there that quickly will depend less on how easily agents can be created than on whether IT teams can govern their permissions, memory, spending and failure modes at the same pace. NanoClaw is betting that the next problem is managing the digital coworkers that appear once that barrier is gone.
Adding an AI agent to Slack sounds appealing to many enterprises — but, as VentureBeat has experienced ourselves first hand — the reality is often far more complex and clunkier than it first seems.
Now NanoCo., the company behind the hit open source, enterprise-friendly, autonomous AI agent harness NanoClaw (a more sandboxed, lower code version of OpenClaw), is hoping to make it just as easy as typing a Slack message. To go one step further: the company’s new NanoClaw Slack integration lets human users spin up entire teams of agents with their own specialized skills, workflows, and even custom avatars, all from a single Slack prompt.
«In the next 12 to 18 months, everyone on a team will be a manager of agents,» NanoCo CEO and co-founder Gavriel Cohen told VentureBeat in an exclusive interview.
Furthermore, the NanoClaw agents can work together in channels and shared Slack Canvases, and can even be messaged outside of Slack on other platforms like Telegram or WhatsApp, letting their human colleagues ping them across messaging platforms, just as they would their fellow humans.
“I think this is agents arriving natively in Slack for the first time,” Cohen added. “In the past, you had to do all these weird things to try to have multiple different agents behind the scenes using the same bot, and now every agent gets its own identity in Slack — its own avatar, its own face, its own name. You can tag them. They can tag each other.”
For enterprise teams, the more consequential part is persistence and separation. NanoClaw is not presenting the additional workers as invisible subagents that disappear after one task. Each can be given its own role, memory context, instructions and permissions, creating a structure closer to a small digital department than a single chatbot with a long prompt.
As with the original open source version of NanoClaw released in January 2026, developers and enterprises can further choose whichever underlying large language model (LLM) they wish to power their NanoClaw agents, optimizing for performance, cost, or other combinations of factors.
From a single NanoClaw Slack agent to a whole specialized team
For a new installation, NanoClaw’s current setup process starts by cloning the project and running its nanoclaw.sh installer, which walks the user through dependencies, credentials, building the agent container and pairing a first messaging channel. NanoClaw’s website says the installer takes a user “from a fresh machine to a named agent you can message,” with Slack among the supported channels.
Cohen described the Slack-specific flow to VentureBeat as a significant simplification over building a traditional Slack bot. Previously, he said, a user would have to navigate Slack’s administrative and developer interfaces, create an app, collect secrets, API keys and tokens, and then move those credentials into wherever the bot was running.
With the new integration, the NanoClaw setup instead offers a Connect Slack option. The user names the agent, authenticates, chooses the NanoClaw Add to Slack option and goes through Slack’s installation and authorization flow. Once authorized, the first agent can appear in Slack and begin communicating with the user.
The important distinction is that this initial authorization is largely a one-time workspace connection. Slack’s Marketplace listing says users “connect a workspace once,” after which NanoClaw can provision each additional agent as its own Slack bot, complete with its own name, generated avatar and identity.
Those agents continue running on the customer’s infrastructure and connect to Slack over Socket Mode. NanoCo says it does not store the agents’ Slack tokens; according to the Marketplace listing, those tokens remain on the user’s machine.
Slack’s standard administrative controls still sit around that system. Organizations can apply their normal app-approval policies to the NanoClaw integration, while NanoClaw’s Marketplace listing says the app’s Home tab displays the agents provisioned in a workspace and lets users revoke individual agents or disconnect the workspace entirely.
The result is less a one-click replacement for NanoClaw’s underlying infrastructure than a one-time bridge between that infrastructure and Slack: users still own and operate the agent runtime, but once the bridge is authorized, the agents themselves can create and coordinate additional Slack-native colleagues without sending the user back through manual app configuration each time.
Behind the scenes, Cohen said, the lead agent has a Model Context Protocol (MCP) tool that can create new agents and define their instructions, personas, skills and tools; another tool can place them into shared rooms. The agents come prepared to work with Slack Canvas and can communicate with every human user on the Slack Channel, and with one another.
The interaction itself is deliberately simple. Rather than opening a separate agent builder every time a new role is needed, Cohen said users can tell the agent they already have what kind of colleague or team they want.
“Your agent in Slack, you can say, ‘Create me another agent to handle my code reviews. Create another agent to review the contributor articles. Create a team of agents that reviews contributor articles from different perspectives.’ And then your agent can create new agents, and they just pop up in the sidebar and send you messages.”
That means a developer could ask for a product manager, architect, implementation agent, code reviewer and testing agent, then give each a different toolset and have them hand work between one another. Cohen said the testing agent, for example, could have access to a testing environment while the review agent carries code-review-specific skills and the product agent monitors user feedback.
Cohen argues that this division of labor is more than cosmetic role-playing. “There are advantages in terms of giving each one specific skills, instructions, and tools for different tasks,” he said. “I can have, let’s say, a code review agent, a code testing agent, a code writing agent, and I can have them in a loop.” If the implementation agent runs into an ambiguity, he added, it can tag the product or architecture agent for clarification rather than forcing one general-purpose model to hold every responsibility and tool in the same context.
Agents work together with humans on a share Slack Canvas
A supplied demo screenshot shows the same pattern applied to marketing: a lead agent named Nano creates Atlas for strategy, Sage for content, Echo for social, Scout for outreach and Compass for SEO and analytics. The agents introduce themselves in the same Slack conversation and begin coordinating work, with Atlas noting that it had added an item to Canvas so the task would not get lost.
Users do not have to specify every detail up front. Cohen said someone could give the lead agent exact review procedures, priorities and required tools, or leave more of the configuration to the agent based on its existing context and memory.
The design also tries to avoid a familiar multi-agent failure mode: bots endlessly triggering one another. NanoCo says the agents reply only when tagged, while comments left on work in Canvas can be routed back to the agent responsible for that piece.
And the model can extend beyond teams of task-specific bots created by one person. Cohen described a workplace where individual employees each have persistent agents that can communicate with one another under human-defined policies.
“Each person having their own agent means that I could have my agent and you have your agent in Slack, and your agent can ask my agent questions,” he said. “Maybe I’m out of the office for the day. Your agent can ping my agent and ask a question about availability, and I can set some policies about whether my agent can answer or if I need to give approval.”
That pushes the concept closer to organizational delegation: some agents specialize by function, while others effectively represent individual employees and the context they have accumulated. Cohen said the agents can be equipped with browser and internet access, memory, coding capabilities and other tools, while newly created agents arrive with built-in support for Canvas work, agent-to-agent communication and spawning still more agents.
Slack is opening the door to more third-party agents
The underlying Slack change is broader than NanoClaw.
In April, Slack, a Salesforce product, announced the ability to add external AI agents to the messaging platform directly, initially pointing to Vercel and Lovable and saying those integrations were coming in late May.
Slack said the deployment mechanism automates OAuth, manifest configuration and environment setup so an externally built agent can be brought into the workspace without being rebuilt specifically for Slack.
Salesforce’s newly published Slack Code page now names NanoClaw alongside Lovable, Hyperagent, Superhuman, n8n, Vercel, ChatGPT, LangChain, Runlayer and Skydive, and says Add to Slack can bring agents from those platforms into Slack in a few clicks with their own identity.
Slack is already crowded with AI assistants. OpenAI, for example, lets ChatGPT workspace agents be deployed into Slack channels, where they can answer questions, perform tasks through connected systems and output files. Slack also supports Claude and custom Agentforce agents. NanoClaw’s differentiation is therefore not simply “AI in Slack.” It is the ability for an already-running agent to create additional, independently addressable teammates from inside the conversation itself. NanoCo calls that a first for Slack; that specific market-first claim is the company’s.
“Add to Slack means one message can spin up a full team of NanoClaw agents, working right alongside people in Slack,” Josh Milas, director of product management at Slack, said in the supplied announcement.
How NanoClaw differs from Claude Tag, ChatGPT agents and Agentforce in Slack
NanoClaw is not alone in trying to turn AI from a sidebar chatbot into something resembling a persistent Slack colleague.
Anthropic’s Claude Tag, which began rolling out in beta to Claude Team and Enterprise customers in June, may be the closest conceptual comparison.
Administrators can give @Claude access to selected channels, tools, data sources and codebases; everyone in the channel can then delegate work to it by tagging it. Claude remembers relevant information from the channels it inhabits, can work asynchronously over hours or days, and, when administrators enable its “ambient” behavior, can proactively flag information or revive unresolved work without waiting for another prompt.
Anthropic says separate Claude identities can also be scoped to different use cases so that, for example, a sales Claude does not share its memories or tools with an engineering Claude.
The difference is in how those digital coworkers are provisioned and organized. Claude Tag’s documented workflow is administrator-led: admins pair Claude with Slack, decide which channels, tools and information each Claude identity can access, set spending limits and then expose those identities to employees.
Within a given channel, Anthropic describes “one Claude that interacts with everyone.” Its public documentation does not describe an end user asking that Claude to create several new, independently named Slack bots on demand. NanoClaw’s model is almost inverted.
After an organization connects its NanoClaw installation to Slack once, NanoClaw says an existing agent can itself provision additional agents from a conversational request, with each new worker receiving its own Slack bot identity, name, generated avatar and token and running back on the customer’s infrastructure.
OpenAI’s ChatGPT Workspace Agents occupy another point on that spectrum.
Business, Edu and Enterprise customers can build reusable agents in ChatGPT, give them instructions, models, files, apps, custom MCP connections and schedules, and then attach those agents to Slack channels.
Builders assign each agent a unique Slack handle and can configure it either to respond only when mentioned or to respond automatically to relevant messages in a channel.
But the construction still happens primarily through ChatGPT’s agent builder: OpenAI’s setup documentation tells users to create the agent first and then add Slack as a channel. Under the hood, the Slack handles rely on Slack user groups managed by the ChatGPT Agents app, rather than NanoClaw’s model in which every provisioned agent is itself a separate Slack bot.
Salesforce’s Agentforce similarly allows organizations to create multiple specialized agents that employees can DM or @mention inside Slack, and it arguably provides the most conventional enterprise administration model of the group.
Companies build the agents in Agentforce Builder, often starting from Slack-specific templates for jobs such as customer insights, employee help or onboarding, and can add subagents and actions that let them search information, create Canvases or perform other work.
Once configured and activated in Salesforce, administrators bring those agents into Slack for employees to use. That makes Agentforce powerful for organizations already centering identity, data and workflows on Salesforce, but again places agent creation before deployment rather than making creation itself something an existing Slack agent can perform during a conversation.
That distinction helps clarify what NanoClaw is actually adding to an increasingly crowded market. Slack itself now provides an Agent Kit for developers and a deployment standard for agents built on outside platforms, automating pieces such as OAuth, manifests and environment configuration. Claude Tag, ChatGPT Workspace Agents and Agentforce all demonstrate that persistent, specialized AI teammates inside Slack are no longer novel on their own.
NanoClaw’s more unusual bet is recursive provisioning: Slack becomes not merely the place where workers invoke agents, but a place where an existing agent can assemble additional named agents, assign them roles and put them together in a channel as a working team.
There are tradeoffs to the different approaches. Claude Tag comes with Anthropic-managed models and centralized administrative controls, including channel-specific permissions, audit logs and token-spending limits, while also offering proactive “ambient” behavior that NanoClaw’s supplied materials do not claim in the same way.
ChatGPT Workspace Agents offer a managed agent builder, schedules, app connections and organization-level publishing and access controls. Agentforce ties agents closely to Salesforce permissions, enterprise data and predefined business actions.
NanoClaw instead emphasizes self-hosting, open-source modification and separate agent identities, shifting more control — and more operational responsibility — to the organization running it.
The result is less a direct replacement for those systems than a different answer to the same emerging question: whether enterprises want a small number of centrally configured AI assistants, or an environment in which employees and existing agents can continuously create specialized digital colleagues as new work appears.
How NanoClaw got here
NanoClaw began far from the enterprise collaboration market. Cohen, a former Wix engineer, launched it under the MIT License on Jan. 31, 2026, as a deliberately small, security-focused alternative to OpenClaw.
The original pitch was that a personal agent with access to messages, files and tools should run inside an OS-isolated container rather than directly on the host, and that the orchestration layer should remain small enough for a developer or security team to understand — an initial core of roughly 500 lines of TypeScript and a design centered on container isolation and a minimal single-process architecture.
The project then moved steadily toward enterprise infrastructure. In March, NanoClaw partnered with Docker to run agents inside Docker Sandboxes, using stronger MicroVM-backed isolation for workloads that may install packages, modify files and launch processes.
In April, NanoClaw 2.0 added Vercel’s Chat SDK and OneCLI’s credential gateway, allowing organizations to define policies around sensitive actions and require human approval before credentials are injected for protected requests.
By May, Cohen and his brother Lazer Cohen had formed NanoCo around the project and raised a $12 million seed round led by Valley Capital Partners, with Docker, Vercel, monday.com and others participating. The commercial strategy is to keep NanoClaw open source while selling managed, organization-wide deployments and “professional assistant” infrastructure to enterprises. The company now says NanoClaw has surpassed 250,000 downloads and 30,000 GitHub stars.
That open-source structure remains central to Cohen’s pitch as NanoClaw moves deeper into workplace infrastructure.
“You’re really able to now integrate an open-source agent into Slack that you fully control,” he said. “You can change all those configurations. Plus, you can fork NanoClaw and completely rewrite or change behaviors — create your own memory system, your own coding harness, agent harness. Whatever you want to do, you can do. Total freedom.”
Persistent agents, but infrastructure stays under the user’s control
Cohen said NanoClaw remains self-hosted: an organization can run it on a local machine or its own cloud VM, with agent data stored there.
The same agent can also appear across Slack, WhatsApp or Telegram while retaining the same memory, workspace and tools, although each messaging surface uses a separate session.
NanoClaw can pull recent context across those sessions so the agent can maintain continuity without merging every chat history into one stream. NanoClaw’s documentation likewise describes a multi-channel architecture in which the same agent can retain one workspace and memory while maintaining separate per-channel sessions.
“This is all self-hosted,” Cohen said. “You’d be running this on your computer or on your virtual machine in the cloud, and that data is stored on your computer or on your [virtual machine] VM. This could be an open-source model running on your Mac Mini, and your data isn’t going anywhere besides your Mac Mini and then into Slack.”
The cross-channel continuity is also intended to make an agent feel less like a Slack-specific bot and more like a persistent colleague that happens to be reachable through Slack.
Cohen said the same agent could exist in Telegram, WhatsApp and Slack with access to the same memory, files and tools. The conversations remain separate sessions, but they share a workspace and persistent context so the agent can carry knowledge from one surface to another.
That architecture matters when an organization starts creating many agents. Cohen said one agent can see its own sessions across channels, but not another agent’s private sessions by default. NanoClaw’s current documentation likewise describes agents running in their own sandboxes and configurable model providers, with Claude Code as the default and Codex, OpenCode and local Ollama models available as alternatives.
There is one cloud dependency for the new Slack flow. Cohen said NanoCo operates a small service that handles Slack provisioning requests and avatar generation. He said it does not receive users’ messages or agent memory.
Continued commitment to open source
NanoCo is not charging for this community Slack capability, according to Cohen, and is absorbing the provisioning-service and avatar-generation costs. Users can still incur their own model inference and hosting expenses, so that does not make a deployed agent team cost-free in practice.
NanoCo says the integration is available through the Slack Marketplace, subject to normal workspace app approval and governance. Slack says workspace owners and administrators can require apps to be approved before installation.
Cohen framed that decision as part of NanoCo’s broader open-source strategy rather than a standalone monetization play. “We’re not making any money off this one. This one is for the community, really,” he said. “We know that in the long run that’s going to benefit NanoCo as a company. As NanoCo grows and builds out capabilities, those go back to the open source. I think that’s the new model of open source, where we’re not trying to monetize every bit of value we bring to the community.”
Whether companies get there that quickly will depend less on how easily agents can be created than on whether IT teams can govern their permissions, memory, spending and failure modes at the same pace. NanoClaw is betting that the next problem is managing the digital coworkers that appear once that barrier is gone.
Adding an AI agent to Slack sounds appealing to many enterprises — but, as VentureBeat has experienced ourselves first hand — the reality is often far more complex and clunkier than it first seems.
Now NanoCo., the company behind the hit open source, enterprise-friendly, autonomous AI agent harness NanoClaw (a more sandboxed, lower code version of OpenClaw), is hoping to make it just as easy as typing a Slack message. To go one step further: the company’s new NanoClaw Slack integration lets human users spin up entire teams of agents with their own specialized skills, workflows, and even custom avatars, all from a single Slack prompt.
«In the next 12 to 18 months, everyone on a team will be a manager of agents,» NanoCo CEO and co-founder Gavriel Cohen told VentureBeat in an exclusive interview.
Furthermore, the NanoClaw agents can work together in channels and shared Slack Canvases, and can even be messaged outside of Slack on other platforms like Telegram or WhatsApp, letting their human colleagues ping them across messaging platforms, just as they would their fellow humans.
“I think this is agents arriving natively in Slack for the first time,” Cohen added. “In the past, you had to do all these weird things to try to have multiple different agents behind the scenes using the same bot, and now every agent gets its own identity in Slack — its own avatar, its own face, its own name. You can tag them. They can tag each other.”
For enterprise teams, the more consequential part is persistence and separation. NanoClaw is not presenting the additional workers as invisible subagents that disappear after one task. Each can be given its own role, memory context, instructions and permissions, creating a structure closer to a small digital department than a single chatbot with a long prompt.
As with the original open source version of NanoClaw released in January 2026, developers and enterprises can further choose whichever underlying large language model (LLM) they wish to power their NanoClaw agents, optimizing for performance, cost, or other combinations of factors.
From a single NanoClaw Slack agent to a whole specialized team
For a new installation, NanoClaw’s current setup process starts by cloning the project and running its nanoclaw.sh installer, which walks the user through dependencies, credentials, building the agent container and pairing a first messaging channel. NanoClaw’s website says the installer takes a user “from a fresh machine to a named agent you can message,” with Slack among the supported channels.
Cohen described the Slack-specific flow to VentureBeat as a significant simplification over building a traditional Slack bot. Previously, he said, a user would have to navigate Slack’s administrative and developer interfaces, create an app, collect secrets, API keys and tokens, and then move those credentials into wherever the bot was running.
With the new integration, the NanoClaw setup instead offers a Connect Slack option. The user names the agent, authenticates, chooses the NanoClaw Add to Slack option and goes through Slack’s installation and authorization flow. Once authorized, the first agent can appear in Slack and begin communicating with the user.
The important distinction is that this initial authorization is largely a one-time workspace connection. Slack’s Marketplace listing says users “connect a workspace once,” after which NanoClaw can provision each additional agent as its own Slack bot, complete with its own name, generated avatar and identity.
Those agents continue running on the customer’s infrastructure and connect to Slack over Socket Mode. NanoCo says it does not store the agents’ Slack tokens; according to the Marketplace listing, those tokens remain on the user’s machine.
Slack’s standard administrative controls still sit around that system. Organizations can apply their normal app-approval policies to the NanoClaw integration, while NanoClaw’s Marketplace listing says the app’s Home tab displays the agents provisioned in a workspace and lets users revoke individual agents or disconnect the workspace entirely.
The result is less a one-click replacement for NanoClaw’s underlying infrastructure than a one-time bridge between that infrastructure and Slack: users still own and operate the agent runtime, but once the bridge is authorized, the agents themselves can create and coordinate additional Slack-native colleagues without sending the user back through manual app configuration each time.
Behind the scenes, Cohen said, the lead agent has a Model Context Protocol (MCP) tool that can create new agents and define their instructions, personas, skills and tools; another tool can place them into shared rooms. The agents come prepared to work with Slack Canvas and can communicate with every human user on the Slack Channel, and with one another.
The interaction itself is deliberately simple. Rather than opening a separate agent builder every time a new role is needed, Cohen said users can tell the agent they already have what kind of colleague or team they want.
“Your agent in Slack, you can say, ‘Create me another agent to handle my code reviews. Create another agent to review the contributor articles. Create a team of agents that reviews contributor articles from different perspectives.’ And then your agent can create new agents, and they just pop up in the sidebar and send you messages.”
That means a developer could ask for a product manager, architect, implementation agent, code reviewer and testing agent, then give each a different toolset and have them hand work between one another. Cohen said the testing agent, for example, could have access to a testing environment while the review agent carries code-review-specific skills and the product agent monitors user feedback.
Cohen argues that this division of labor is more than cosmetic role-playing. “There are advantages in terms of giving each one specific skills, instructions, and tools for different tasks,” he said. “I can have, let’s say, a code review agent, a code testing agent, a code writing agent, and I can have them in a loop.” If the implementation agent runs into an ambiguity, he added, it can tag the product or architecture agent for clarification rather than forcing one general-purpose model to hold every responsibility and tool in the same context.
Agents work together with humans on a share Slack Canvas
A supplied demo screenshot shows the same pattern applied to marketing: a lead agent named Nano creates Atlas for strategy, Sage for content, Echo for social, Scout for outreach and Compass for SEO and analytics. The agents introduce themselves in the same Slack conversation and begin coordinating work, with Atlas noting that it had added an item to Canvas so the task would not get lost.
Users do not have to specify every detail up front. Cohen said someone could give the lead agent exact review procedures, priorities and required tools, or leave more of the configuration to the agent based on its existing context and memory.
The design also tries to avoid a familiar multi-agent failure mode: bots endlessly triggering one another. NanoCo says the agents reply only when tagged, while comments left on work in Canvas can be routed back to the agent responsible for that piece.
And the model can extend beyond teams of task-specific bots created by one person. Cohen described a workplace where individual employees each have persistent agents that can communicate with one another under human-defined policies.
“Each person having their own agent means that I could have my agent and you have your agent in Slack, and your agent can ask my agent questions,” he said. “Maybe I’m out of the office for the day. Your agent can ping my agent and ask a question about availability, and I can set some policies about whether my agent can answer or if I need to give approval.”
That pushes the concept closer to organizational delegation: some agents specialize by function, while others effectively represent individual employees and the context they have accumulated. Cohen said the agents can be equipped with browser and internet access, memory, coding capabilities and other tools, while newly created agents arrive with built-in support for Canvas work, agent-to-agent communication and spawning still more agents.
Slack is opening the door to more third-party agents
The underlying Slack change is broader than NanoClaw.
In April, Slack, a Salesforce product, announced the ability to add external AI agents to the messaging platform directly, initially pointing to Vercel and Lovable and saying those integrations were coming in late May.
Slack said the deployment mechanism automates OAuth, manifest configuration and environment setup so an externally built agent can be brought into the workspace without being rebuilt specifically for Slack.
Salesforce’s newly published Slack Code page now names NanoClaw alongside Lovable, Hyperagent, Superhuman, n8n, Vercel, ChatGPT, LangChain, Runlayer and Skydive, and says Add to Slack can bring agents from those platforms into Slack in a few clicks with their own identity.
Slack is already crowded with AI assistants. OpenAI, for example, lets ChatGPT workspace agents be deployed into Slack channels, where they can answer questions, perform tasks through connected systems and output files. Slack also supports Claude and custom Agentforce agents. NanoClaw’s differentiation is therefore not simply “AI in Slack.” It is the ability for an already-running agent to create additional, independently addressable teammates from inside the conversation itself. NanoCo calls that a first for Slack; that specific market-first claim is the company’s.
“Add to Slack means one message can spin up a full team of NanoClaw agents, working right alongside people in Slack,” Josh Milas, director of product management at Slack, said in the supplied announcement.
How NanoClaw differs from Claude Tag, ChatGPT agents and Agentforce in Slack
NanoClaw is not alone in trying to turn AI from a sidebar chatbot into something resembling a persistent Slack colleague.
Anthropic’s Claude Tag, which began rolling out in beta to Claude Team and Enterprise customers in June, may be the closest conceptual comparison.
Administrators can give @Claude access to selected channels, tools, data sources and codebases; everyone in the channel can then delegate work to it by tagging it. Claude remembers relevant information from the channels it inhabits, can work asynchronously over hours or days, and, when administrators enable its “ambient” behavior, can proactively flag information or revive unresolved work without waiting for another prompt.
Anthropic says separate Claude identities can also be scoped to different use cases so that, for example, a sales Claude does not share its memories or tools with an engineering Claude.
The difference is in how those digital coworkers are provisioned and organized. Claude Tag’s documented workflow is administrator-led: admins pair Claude with Slack, decide which channels, tools and information each Claude identity can access, set spending limits and then expose those identities to employees.
Within a given channel, Anthropic describes “one Claude that interacts with everyone.” Its public documentation does not describe an end user asking that Claude to create several new, independently named Slack bots on demand. NanoClaw’s model is almost inverted.
After an organization connects its NanoClaw installation to Slack once, NanoClaw says an existing agent can itself provision additional agents from a conversational request, with each new worker receiving its own Slack bot identity, name, generated avatar and token and running back on the customer’s infrastructure.
OpenAI’s ChatGPT Workspace Agents occupy another point on that spectrum.
Business, Edu and Enterprise customers can build reusable agents in ChatGPT, give them instructions, models, files, apps, custom MCP connections and schedules, and then attach those agents to Slack channels.
Builders assign each agent a unique Slack handle and can configure it either to respond only when mentioned or to respond automatically to relevant messages in a channel.
But the construction still happens primarily through ChatGPT’s agent builder: OpenAI’s setup documentation tells users to create the agent first and then add Slack as a channel. Under the hood, the Slack handles rely on Slack user groups managed by the ChatGPT Agents app, rather than NanoClaw’s model in which every provisioned agent is itself a separate Slack bot.
Salesforce’s Agentforce similarly allows organizations to create multiple specialized agents that employees can DM or @mention inside Slack, and it arguably provides the most conventional enterprise administration model of the group.
Companies build the agents in Agentforce Builder, often starting from Slack-specific templates for jobs such as customer insights, employee help or onboarding, and can add subagents and actions that let them search information, create Canvases or perform other work.
Once configured and activated in Salesforce, administrators bring those agents into Slack for employees to use. That makes Agentforce powerful for organizations already centering identity, data and workflows on Salesforce, but again places agent creation before deployment rather than making creation itself something an existing Slack agent can perform during a conversation.
That distinction helps clarify what NanoClaw is actually adding to an increasingly crowded market. Slack itself now provides an Agent Kit for developers and a deployment standard for agents built on outside platforms, automating pieces such as OAuth, manifests and environment configuration. Claude Tag, ChatGPT Workspace Agents and Agentforce all demonstrate that persistent, specialized AI teammates inside Slack are no longer novel on their own.
NanoClaw’s more unusual bet is recursive provisioning: Slack becomes not merely the place where workers invoke agents, but a place where an existing agent can assemble additional named agents, assign them roles and put them together in a channel as a working team.
There are tradeoffs to the different approaches. Claude Tag comes with Anthropic-managed models and centralized administrative controls, including channel-specific permissions, audit logs and token-spending limits, while also offering proactive “ambient” behavior that NanoClaw’s supplied materials do not claim in the same way.
ChatGPT Workspace Agents offer a managed agent builder, schedules, app connections and organization-level publishing and access controls. Agentforce ties agents closely to Salesforce permissions, enterprise data and predefined business actions.
NanoClaw instead emphasizes self-hosting, open-source modification and separate agent identities, shifting more control — and more operational responsibility — to the organization running it.
The result is less a direct replacement for those systems than a different answer to the same emerging question: whether enterprises want a small number of centrally configured AI assistants, or an environment in which employees and existing agents can continuously create specialized digital colleagues as new work appears.
How NanoClaw got here
NanoClaw began far from the enterprise collaboration market. Cohen, a former Wix engineer, launched it under the MIT License on Jan. 31, 2026, as a deliberately small, security-focused alternative to OpenClaw.
The original pitch was that a personal agent with access to messages, files and tools should run inside an OS-isolated container rather than directly on the host, and that the orchestration layer should remain small enough for a developer or security team to understand — an initial core of roughly 500 lines of TypeScript and a design centered on container isolation and a minimal single-process architecture.
The project then moved steadily toward enterprise infrastructure. In March, NanoClaw partnered with Docker to run agents inside Docker Sandboxes, using stronger MicroVM-backed isolation for workloads that may install packages, modify files and launch processes.
In April, NanoClaw 2.0 added Vercel’s Chat SDK and OneCLI’s credential gateway, allowing organizations to define policies around sensitive actions and require human approval before credentials are injected for protected requests.
By May, Cohen and his brother Lazer Cohen had formed NanoCo around the project and raised a $12 million seed round led by Valley Capital Partners, with Docker, Vercel, monday.com and others participating. The commercial strategy is to keep NanoClaw open source while selling managed, organization-wide deployments and “professional assistant” infrastructure to enterprises. The company now says NanoClaw has surpassed 250,000 downloads and 30,000 GitHub stars.
That open-source structure remains central to Cohen’s pitch as NanoClaw moves deeper into workplace infrastructure.
“You’re really able to now integrate an open-source agent into Slack that you fully control,” he said. “You can change all those configurations. Plus, you can fork NanoClaw and completely rewrite or change behaviors — create your own memory system, your own coding harness, agent harness. Whatever you want to do, you can do. Total freedom.”
Persistent agents, but infrastructure stays under the user’s control
Cohen said NanoClaw remains self-hosted: an organization can run it on a local machine or its own cloud VM, with agent data stored there.
The same agent can also appear across Slack, WhatsApp or Telegram while retaining the same memory, workspace and tools, although each messaging surface uses a separate session.
NanoClaw can pull recent context across those sessions so the agent can maintain continuity without merging every chat history into one stream. NanoClaw’s documentation likewise describes a multi-channel architecture in which the same agent can retain one workspace and memory while maintaining separate per-channel sessions.
“This is all self-hosted,” Cohen said. “You’d be running this on your computer or on your virtual machine in the cloud, and that data is stored on your computer or on your [virtual machine] VM. This could be an open-source model running on your Mac Mini, and your data isn’t going anywhere besides your Mac Mini and then into Slack.”
The cross-channel continuity is also intended to make an agent feel less like a Slack-specific bot and more like a persistent colleague that happens to be reachable through Slack.
Cohen said the same agent could exist in Telegram, WhatsApp and Slack with access to the same memory, files and tools. The conversations remain separate sessions, but they share a workspace and persistent context so the agent can carry knowledge from one surface to another.
That architecture matters when an organization starts creating many agents. Cohen said one agent can see its own sessions across channels, but not another agent’s private sessions by default. NanoClaw’s current documentation likewise describes agents running in their own sandboxes and configurable model providers, with Claude Code as the default and Codex, OpenCode and local Ollama models available as alternatives.
There is one cloud dependency for the new Slack flow. Cohen said NanoCo operates a small service that handles Slack provisioning requests and avatar generation. He said it does not receive users’ messages or agent memory.
Continued commitment to open source
NanoCo is not charging for this community Slack capability, according to Cohen, and is absorbing the provisioning-service and avatar-generation costs. Users can still incur their own model inference and hosting expenses, so that does not make a deployed agent team cost-free in practice.
NanoCo says the integration is available through the Slack Marketplace, subject to normal workspace app approval and governance. Slack says workspace owners and administrators can require apps to be approved before installation.
Cohen framed that decision as part of NanoCo’s broader open-source strategy rather than a standalone monetization play. “We’re not making any money off this one. This one is for the community, really,” he said. “We know that in the long run that’s going to benefit NanoCo as a company. As NanoCo grows and builds out capabilities, those go back to the open source. I think that’s the new model of open source, where we’re not trying to monetize every bit of value we bring to the community.”
Whether companies get there that quickly will depend less on how easily agents can be created than on whether IT teams can govern their permissions, memory, spending and failure modes at the same pace. NanoClaw is betting that the next problem is managing the digital coworkers that appear once that barrier is gone.
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
Adding an AI agent to Slack sounds appealing to many enterprises — but, as VentureBeat has experienced ourselves first hand — the reality is often far more complex and clunkier than it first seems.
Now NanoCo., the company behind the hit open source, enterprise-friendly, autonomous AI agent harness NanoClaw (a more sandboxed, lower code version of OpenClaw), is hoping to make it just as easy as typing a Slack message. To go one step further: the company’s new NanoClaw Slack integration lets human users spin up entire teams of agents with their own specialized skills, workflows, and even custom avatars, all from a single Slack prompt.
«In the next 12 to 18 months, everyone on a team will be a manager of agents,» NanoCo CEO and co-founder Gavriel Cohen told VentureBeat in an exclusive interview.
Furthermore, the NanoClaw agents can work together in channels and shared Slack Canvases, and can even be messaged outside of Slack on other platforms like Telegram or WhatsApp, letting their human colleagues ping them across messaging platforms, just as they would their fellow humans.
“I think this is agents arriving natively in Slack for the first time,” Cohen added. “In the past, you had to do all these weird things to try to have multiple different agents behind the scenes using the same bot, and now every agent gets its own identity in Slack — its own avatar, its own face, its own name. You can tag them. They can tag each other.”
For enterprise teams, the more consequential part is persistence and separation. NanoClaw is not presenting the additional workers as invisible subagents that disappear after one task. Each can be given its own role, memory context, instructions and permissions, creating a structure closer to a small digital department than a single chatbot with a long prompt.
As with the original open source version of NanoClaw released in January 2026, developers and enterprises can further choose whichever underlying large language model (LLM) they wish to power their NanoClaw agents, optimizing for performance, cost, or other combinations of factors.
From a single NanoClaw Slack agent to a whole specialized team
For a new installation, NanoClaw’s current setup process starts by cloning the project and running its nanoclaw.sh installer, which walks the user through dependencies, credentials, building the agent container and pairing a first messaging channel. NanoClaw’s website says the installer takes a user “from a fresh machine to a named agent you can message,” with Slack among the supported channels.
Cohen described the Slack-specific flow to VentureBeat as a significant simplification over building a traditional Slack bot. Previously, he said, a user would have to navigate Slack’s administrative and developer interfaces, create an app, collect secrets, API keys and tokens, and then move those credentials into wherever the bot was running.
With the new integration, the NanoClaw setup instead offers a Connect Slack option. The user names the agent, authenticates, chooses the NanoClaw Add to Slack option and goes through Slack’s installation and authorization flow. Once authorized, the first agent can appear in Slack and begin communicating with the user.
The important distinction is that this initial authorization is largely a one-time workspace connection. Slack’s Marketplace listing says users “connect a workspace once,” after which NanoClaw can provision each additional agent as its own Slack bot, complete with its own name, generated avatar and identity.
Those agents continue running on the customer’s infrastructure and connect to Slack over Socket Mode. NanoCo says it does not store the agents’ Slack tokens; according to the Marketplace listing, those tokens remain on the user’s machine.
Slack’s standard administrative controls still sit around that system. Organizations can apply their normal app-approval policies to the NanoClaw integration, while NanoClaw’s Marketplace listing says the app’s Home tab displays the agents provisioned in a workspace and lets users revoke individual agents or disconnect the workspace entirely.
The result is less a one-click replacement for NanoClaw’s underlying infrastructure than a one-time bridge between that infrastructure and Slack: users still own and operate the agent runtime, but once the bridge is authorized, the agents themselves can create and coordinate additional Slack-native colleagues without sending the user back through manual app configuration each time.
Behind the scenes, Cohen said, the lead agent has a Model Context Protocol (MCP) tool that can create new agents and define their instructions, personas, skills and tools; another tool can place them into shared rooms. The agents come prepared to work with Slack Canvas and can communicate with every human user on the Slack Channel, and with one another.
The interaction itself is deliberately simple. Rather than opening a separate agent builder every time a new role is needed, Cohen said users can tell the agent they already have what kind of colleague or team they want.
“Your agent in Slack, you can say, ‘Create me another agent to handle my code reviews. Create another agent to review the contributor articles. Create a team of agents that reviews contributor articles from different perspectives.’ And then your agent can create new agents, and they just pop up in the sidebar and send you messages.”
That means a developer could ask for a product manager, architect, implementation agent, code reviewer and testing agent, then give each a different toolset and have them hand work between one another. Cohen said the testing agent, for example, could have access to a testing environment while the review agent carries code-review-specific skills and the product agent monitors user feedback.
Cohen argues that this division of labor is more than cosmetic role-playing. “There are advantages in terms of giving each one specific skills, instructions, and tools for different tasks,” he said. “I can have, let’s say, a code review agent, a code testing agent, a code writing agent, and I can have them in a loop.” If the implementation agent runs into an ambiguity, he added, it can tag the product or architecture agent for clarification rather than forcing one general-purpose model to hold every responsibility and tool in the same context.
Agents work together with humans on a share Slack Canvas
A supplied demo screenshot shows the same pattern applied to marketing: a lead agent named Nano creates Atlas for strategy, Sage for content, Echo for social, Scout for outreach and Compass for SEO and analytics. The agents introduce themselves in the same Slack conversation and begin coordinating work, with Atlas noting that it had added an item to Canvas so the task would not get lost.
Users do not have to specify every detail up front. Cohen said someone could give the lead agent exact review procedures, priorities and required tools, or leave more of the configuration to the agent based on its existing context and memory.
The design also tries to avoid a familiar multi-agent failure mode: bots endlessly triggering one another. NanoCo says the agents reply only when tagged, while comments left on work in Canvas can be routed back to the agent responsible for that piece.
And the model can extend beyond teams of task-specific bots created by one person. Cohen described a workplace where individual employees each have persistent agents that can communicate with one another under human-defined policies.
“Each person having their own agent means that I could have my agent and you have your agent in Slack, and your agent can ask my agent questions,” he said. “Maybe I’m out of the office for the day. Your agent can ping my agent and ask a question about availability, and I can set some policies about whether my agent can answer or if I need to give approval.”
That pushes the concept closer to organizational delegation: some agents specialize by function, while others effectively represent individual employees and the context they have accumulated. Cohen said the agents can be equipped with browser and internet access, memory, coding capabilities and other tools, while newly created agents arrive with built-in support for Canvas work, agent-to-agent communication and spawning still more agents.
Slack is opening the door to more third-party agents
The underlying Slack change is broader than NanoClaw.
In April, Slack, a Salesforce product, announced the ability to add external AI agents to the messaging platform directly, initially pointing to Vercel and Lovable and saying those integrations were coming in late May.
Slack said the deployment mechanism automates OAuth, manifest configuration and environment setup so an externally built agent can be brought into the workspace without being rebuilt specifically for Slack.
Salesforce’s newly published Slack Code page now names NanoClaw alongside Lovable, Hyperagent, Superhuman, n8n, Vercel, ChatGPT, LangChain, Runlayer and Skydive, and says Add to Slack can bring agents from those platforms into Slack in a few clicks with their own identity.
Slack is already crowded with AI assistants. OpenAI, for example, lets ChatGPT workspace agents be deployed into Slack channels, where they can answer questions, perform tasks through connected systems and output files. Slack also supports Claude and custom Agentforce agents. NanoClaw’s differentiation is therefore not simply “AI in Slack.” It is the ability for an already-running agent to create additional, independently addressable teammates from inside the conversation itself. NanoCo calls that a first for Slack; that specific market-first claim is the company’s.
“Add to Slack means one message can spin up a full team of NanoClaw agents, working right alongside people in Slack,” Josh Milas, director of product management at Slack, said in the supplied announcement.
How NanoClaw differs from Claude Tag, ChatGPT agents and Agentforce in Slack
NanoClaw is not alone in trying to turn AI from a sidebar chatbot into something resembling a persistent Slack colleague.
Anthropic’s Claude Tag, which began rolling out in beta to Claude Team and Enterprise customers in June, may be the closest conceptual comparison.
Administrators can give @Claude access to selected channels, tools, data sources and codebases; everyone in the channel can then delegate work to it by tagging it. Claude remembers relevant information from the channels it inhabits, can work asynchronously over hours or days, and, when administrators enable its “ambient” behavior, can proactively flag information or revive unresolved work without waiting for another prompt.
Anthropic says separate Claude identities can also be scoped to different use cases so that, for example, a sales Claude does not share its memories or tools with an engineering Claude.
The difference is in how those digital coworkers are provisioned and organized. Claude Tag’s documented workflow is administrator-led: admins pair Claude with Slack, decide which channels, tools and information each Claude identity can access, set spending limits and then expose those identities to employees.
Within a given channel, Anthropic describes “one Claude that interacts with everyone.” Its public documentation does not describe an end user asking that Claude to create several new, independently named Slack bots on demand. NanoClaw’s model is almost inverted.
After an organization connects its NanoClaw installation to Slack once, NanoClaw says an existing agent can itself provision additional agents from a conversational request, with each new worker receiving its own Slack bot identity, name, generated avatar and token and running back on the customer’s infrastructure.
OpenAI’s ChatGPT Workspace Agents occupy another point on that spectrum.
Business, Edu and Enterprise customers can build reusable agents in ChatGPT, give them instructions, models, files, apps, custom MCP connections and schedules, and then attach those agents to Slack channels.
Builders assign each agent a unique Slack handle and can configure it either to respond only when mentioned or to respond automatically to relevant messages in a channel.
But the construction still happens primarily through ChatGPT’s agent builder: OpenAI’s setup documentation tells users to create the agent first and then add Slack as a channel. Under the hood, the Slack handles rely on Slack user groups managed by the ChatGPT Agents app, rather than NanoClaw’s model in which every provisioned agent is itself a separate Slack bot.
Salesforce’s Agentforce similarly allows organizations to create multiple specialized agents that employees can DM or @mention inside Slack, and it arguably provides the most conventional enterprise administration model of the group.
Companies build the agents in Agentforce Builder, often starting from Slack-specific templates for jobs such as customer insights, employee help or onboarding, and can add subagents and actions that let them search information, create Canvases or perform other work.
Once configured and activated in Salesforce, administrators bring those agents into Slack for employees to use. That makes Agentforce powerful for organizations already centering identity, data and workflows on Salesforce, but again places agent creation before deployment rather than making creation itself something an existing Slack agent can perform during a conversation.
That distinction helps clarify what NanoClaw is actually adding to an increasingly crowded market. Slack itself now provides an Agent Kit for developers and a deployment standard for agents built on outside platforms, automating pieces such as OAuth, manifests and environment configuration. Claude Tag, ChatGPT Workspace Agents and Agentforce all demonstrate that persistent, specialized AI teammates inside Slack are no longer novel on their own.
NanoClaw’s more unusual bet is recursive provisioning: Slack becomes not merely the place where workers invoke agents, but a place where an existing agent can assemble additional named agents, assign them roles and put them together in a channel as a working team.
There are tradeoffs to the different approaches. Claude Tag comes with Anthropic-managed models and centralized administrative controls, including channel-specific permissions, audit logs and token-spending limits, while also offering proactive “ambient” behavior that NanoClaw’s supplied materials do not claim in the same way.
ChatGPT Workspace Agents offer a managed agent builder, schedules, app connections and organization-level publishing and access controls. Agentforce ties agents closely to Salesforce permissions, enterprise data and predefined business actions.
NanoClaw instead emphasizes self-hosting, open-source modification and separate agent identities, shifting more control — and more operational responsibility — to the organization running it.
The result is less a direct replacement for those systems than a different answer to the same emerging question: whether enterprises want a small number of centrally configured AI assistants, or an environment in which employees and existing agents can continuously create specialized digital colleagues as new work appears.
How NanoClaw got here
NanoClaw began far from the enterprise collaboration market. Cohen, a former Wix engineer, launched it under the MIT License on Jan. 31, 2026, as a deliberately small, security-focused alternative to OpenClaw.
The original pitch was that a personal agent with access to messages, files and tools should run inside an OS-isolated container rather than directly on the host, and that the orchestration layer should remain small enough for a developer or security team to understand — an initial core of roughly 500 lines of TypeScript and a design centered on container isolation and a minimal single-process architecture.
The project then moved steadily toward enterprise infrastructure. In March, NanoClaw partnered with Docker to run agents inside Docker Sandboxes, using stronger MicroVM-backed isolation for workloads that may install packages, modify files and launch processes.
In April, NanoClaw 2.0 added Vercel’s Chat SDK and OneCLI’s credential gateway, allowing organizations to define policies around sensitive actions and require human approval before credentials are injected for protected requests.
By May, Cohen and his brother Lazer Cohen had formed NanoCo around the project and raised a $12 million seed round led by Valley Capital Partners, with Docker, Vercel, monday.com and others participating. The commercial strategy is to keep NanoClaw open source while selling managed, organization-wide deployments and “professional assistant” infrastructure to enterprises. The company now says NanoClaw has surpassed 250,000 downloads and 30,000 GitHub stars.
That open-source structure remains central to Cohen’s pitch as NanoClaw moves deeper into workplace infrastructure.
“You’re really able to now integrate an open-source agent into Slack that you fully control,” he said. “You can change all those configurations. Plus, you can fork NanoClaw and completely rewrite or change behaviors — create your own memory system, your own coding harness, agent harness. Whatever you want to do, you can do. Total freedom.”
Persistent agents, but infrastructure stays under the user’s control
Cohen said NanoClaw remains self-hosted: an organization can run it on a local machine or its own cloud VM, with agent data stored there.
The same agent can also appear across Slack, WhatsApp or Telegram while retaining the same memory, workspace and tools, although each messaging surface uses a separate session.
NanoClaw can pull recent context across those sessions so the agent can maintain continuity without merging every chat history into one stream. NanoClaw’s documentation likewise describes a multi-channel architecture in which the same agent can retain one workspace and memory while maintaining separate per-channel sessions.
“This is all self-hosted,” Cohen said. “You’d be running this on your computer or on your virtual machine in the cloud, and that data is stored on your computer or on your [virtual machine] VM. This could be an open-source model running on your Mac Mini, and your data isn’t going anywhere besides your Mac Mini and then into Slack.”
The cross-channel continuity is also intended to make an agent feel less like a Slack-specific bot and more like a persistent colleague that happens to be reachable through Slack.
Cohen said the same agent could exist in Telegram, WhatsApp and Slack with access to the same memory, files and tools. The conversations remain separate sessions, but they share a workspace and persistent context so the agent can carry knowledge from one surface to another.
That architecture matters when an organization starts creating many agents. Cohen said one agent can see its own sessions across channels, but not another agent’s private sessions by default. NanoClaw’s current documentation likewise describes agents running in their own sandboxes and configurable model providers, with Claude Code as the default and Codex, OpenCode and local Ollama models available as alternatives.
There is one cloud dependency for the new Slack flow. Cohen said NanoCo operates a small service that handles Slack provisioning requests and avatar generation. He said it does not receive users’ messages or agent memory.
Continued commitment to open source
NanoCo is not charging for this community Slack capability, according to Cohen, and is absorbing the provisioning-service and avatar-generation costs. Users can still incur their own model inference and hosting expenses, so that does not make a deployed agent team cost-free in practice.
NanoCo says the integration is available through the Slack Marketplace, subject to normal workspace app approval and governance. Slack says workspace owners and administrators can require apps to be approved before installation.
Cohen framed that decision as part of NanoCo’s broader open-source strategy rather than a standalone monetization play. “We’re not making any money off this one. This one is for the community, really,” he said. “We know that in the long run that’s going to benefit NanoCo as a company. As NanoCo grows and builds out capabilities, those go back to the open source. I think that’s the new model of open source, where we’re not trying to monetize every bit of value we bring to the community.”
Whether companies get there that quickly will depend less on how easily agents can be created than on whether IT teams can govern their permissions, memory, spending and failure modes at the same pace. NanoClaw is betting that the next problem is managing the digital coworkers that appear once that barrier is gone.
Adding an AI agent to Slack sounds appealing to many enterprises — but, as VentureBeat has experienced ourselves first hand — the reality is often far more complex and clunkier than it first seems.
Now NanoCo., the company behind the hit open source, enterprise-friendly, autonomous AI agent harness NanoClaw (a more sandboxed, lower code version of OpenClaw), is hoping to make it just as easy as typing a Slack message. To go one step further: the company’s new NanoClaw Slack integration lets human users spin up entire teams of agents with their own specialized skills, workflows, and even custom avatars, all from a single Slack prompt.
«In the next 12 to 18 months, everyone on a team will be a manager of agents,» NanoCo CEO and co-founder Gavriel Cohen told VentureBeat in an exclusive interview.
Furthermore, the NanoClaw agents can work together in channels and shared Slack Canvases, and can even be messaged outside of Slack on other platforms like Telegram or WhatsApp, letting their human colleagues ping them across messaging platforms, just as they would their fellow humans.
“I think this is agents arriving natively in Slack for the first time,” Cohen added. “In the past, you had to do all these weird things to try to have multiple different agents behind the scenes using the same bot, and now every agent gets its own identity in Slack — its own avatar, its own face, its own name. You can tag them. They can tag each other.”
For enterprise teams, the more consequential part is persistence and separation. NanoClaw is not presenting the additional workers as invisible subagents that disappear after one task. Each can be given its own role, memory context, instructions and permissions, creating a structure closer to a small digital department than a single chatbot with a long prompt.
As with the original open source version of NanoClaw released in January 2026, developers and enterprises can further choose whichever underlying large language model (LLM) they wish to power their NanoClaw agents, optimizing for performance, cost, or other combinations of factors.
From a single NanoClaw Slack agent to a whole specialized team
For a new installation, NanoClaw’s current setup process starts by cloning the project and running its nanoclaw.sh installer, which walks the user through dependencies, credentials, building the agent container and pairing a first messaging channel. NanoClaw’s website says the installer takes a user “from a fresh machine to a named agent you can message,” with Slack among the supported channels.
Cohen described the Slack-specific flow to VentureBeat as a significant simplification over building a traditional Slack bot. Previously, he said, a user would have to navigate Slack’s administrative and developer interfaces, create an app, collect secrets, API keys and tokens, and then move those credentials into wherever the bot was running.
With the new integration, the NanoClaw setup instead offers a Connect Slack option. The user names the agent, authenticates, chooses the NanoClaw Add to Slack option and goes through Slack’s installation and authorization flow. Once authorized, the first agent can appear in Slack and begin communicating with the user.
The important distinction is that this initial authorization is largely a one-time workspace connection. Slack’s Marketplace listing says users “connect a workspace once,” after which NanoClaw can provision each additional agent as its own Slack bot, complete with its own name, generated avatar and identity.
Those agents continue running on the customer’s infrastructure and connect to Slack over Socket Mode. NanoCo says it does not store the agents’ Slack tokens; according to the Marketplace listing, those tokens remain on the user’s machine.
Slack’s standard administrative controls still sit around that system. Organizations can apply their normal app-approval policies to the NanoClaw integration, while NanoClaw’s Marketplace listing says the app’s Home tab displays the agents provisioned in a workspace and lets users revoke individual agents or disconnect the workspace entirely.
The result is less a one-click replacement for NanoClaw’s underlying infrastructure than a one-time bridge between that infrastructure and Slack: users still own and operate the agent runtime, but once the bridge is authorized, the agents themselves can create and coordinate additional Slack-native colleagues without sending the user back through manual app configuration each time.
Behind the scenes, Cohen said, the lead agent has a Model Context Protocol (MCP) tool that can create new agents and define their instructions, personas, skills and tools; another tool can place them into shared rooms. The agents come prepared to work with Slack Canvas and can communicate with every human user on the Slack Channel, and with one another.
The interaction itself is deliberately simple. Rather than opening a separate agent builder every time a new role is needed, Cohen said users can tell the agent they already have what kind of colleague or team they want.
“Your agent in Slack, you can say, ‘Create me another agent to handle my code reviews. Create another agent to review the contributor articles. Create a team of agents that reviews contributor articles from different perspectives.’ And then your agent can create new agents, and they just pop up in the sidebar and send you messages.”
That means a developer could ask for a product manager, architect, implementation agent, code reviewer and testing agent, then give each a different toolset and have them hand work between one another. Cohen said the testing agent, for example, could have access to a testing environment while the review agent carries code-review-specific skills and the product agent monitors user feedback.
Cohen argues that this division of labor is more than cosmetic role-playing. “There are advantages in terms of giving each one specific skills, instructions, and tools for different tasks,” he said. “I can have, let’s say, a code review agent, a code testing agent, a code writing agent, and I can have them in a loop.” If the implementation agent runs into an ambiguity, he added, it can tag the product or architecture agent for clarification rather than forcing one general-purpose model to hold every responsibility and tool in the same context.
Agents work together with humans on a share Slack Canvas
A supplied demo screenshot shows the same pattern applied to marketing: a lead agent named Nano creates Atlas for strategy, Sage for content, Echo for social, Scout for outreach and Compass for SEO and analytics. The agents introduce themselves in the same Slack conversation and begin coordinating work, with Atlas noting that it had added an item to Canvas so the task would not get lost.
Users do not have to specify every detail up front. Cohen said someone could give the lead agent exact review procedures, priorities and required tools, or leave more of the configuration to the agent based on its existing context and memory.
The design also tries to avoid a familiar multi-agent failure mode: bots endlessly triggering one another. NanoCo says the agents reply only when tagged, while comments left on work in Canvas can be routed back to the agent responsible for that piece.
And the model can extend beyond teams of task-specific bots created by one person. Cohen described a workplace where individual employees each have persistent agents that can communicate with one another under human-defined policies.
“Each person having their own agent means that I could have my agent and you have your agent in Slack, and your agent can ask my agent questions,” he said. “Maybe I’m out of the office for the day. Your agent can ping my agent and ask a question about availability, and I can set some policies about whether my agent can answer or if I need to give approval.”
That pushes the concept closer to organizational delegation: some agents specialize by function, while others effectively represent individual employees and the context they have accumulated. Cohen said the agents can be equipped with browser and internet access, memory, coding capabilities and other tools, while newly created agents arrive with built-in support for Canvas work, agent-to-agent communication and spawning still more agents.
Slack is opening the door to more third-party agents
The underlying Slack change is broader than NanoClaw.
In April, Slack, a Salesforce product, announced the ability to add external AI agents to the messaging platform directly, initially pointing to Vercel and Lovable and saying those integrations were coming in late May.
Slack said the deployment mechanism automates OAuth, manifest configuration and environment setup so an externally built agent can be brought into the workspace without being rebuilt specifically for Slack.
Salesforce’s newly published Slack Code page now names NanoClaw alongside Lovable, Hyperagent, Superhuman, n8n, Vercel, ChatGPT, LangChain, Runlayer and Skydive, and says Add to Slack can bring agents from those platforms into Slack in a few clicks with their own identity.
Slack is already crowded with AI assistants. OpenAI, for example, lets ChatGPT workspace agents be deployed into Slack channels, where they can answer questions, perform tasks through connected systems and output files. Slack also supports Claude and custom Agentforce agents. NanoClaw’s differentiation is therefore not simply “AI in Slack.” It is the ability for an already-running agent to create additional, independently addressable teammates from inside the conversation itself. NanoCo calls that a first for Slack; that specific market-first claim is the company’s.
“Add to Slack means one message can spin up a full team of NanoClaw agents, working right alongside people in Slack,” Josh Milas, director of product management at Slack, said in the supplied announcement.
How NanoClaw differs from Claude Tag, ChatGPT agents and Agentforce in Slack
NanoClaw is not alone in trying to turn AI from a sidebar chatbot into something resembling a persistent Slack colleague.
Anthropic’s Claude Tag, which began rolling out in beta to Claude Team and Enterprise customers in June, may be the closest conceptual comparison.
Administrators can give @Claude access to selected channels, tools, data sources and codebases; everyone in the channel can then delegate work to it by tagging it. Claude remembers relevant information from the channels it inhabits, can work asynchronously over hours or days, and, when administrators enable its “ambient” behavior, can proactively flag information or revive unresolved work without waiting for another prompt.
Anthropic says separate Claude identities can also be scoped to different use cases so that, for example, a sales Claude does not share its memories or tools with an engineering Claude.
The difference is in how those digital coworkers are provisioned and organized. Claude Tag’s documented workflow is administrator-led: admins pair Claude with Slack, decide which channels, tools and information each Claude identity can access, set spending limits and then expose those identities to employees.
Within a given channel, Anthropic describes “one Claude that interacts with everyone.” Its public documentation does not describe an end user asking that Claude to create several new, independently named Slack bots on demand. NanoClaw’s model is almost inverted.
After an organization connects its NanoClaw installation to Slack once, NanoClaw says an existing agent can itself provision additional agents from a conversational request, with each new worker receiving its own Slack bot identity, name, generated avatar and token and running back on the customer’s infrastructure.
OpenAI’s ChatGPT Workspace Agents occupy another point on that spectrum.
Business, Edu and Enterprise customers can build reusable agents in ChatGPT, give them instructions, models, files, apps, custom MCP connections and schedules, and then attach those agents to Slack channels.
Builders assign each agent a unique Slack handle and can configure it either to respond only when mentioned or to respond automatically to relevant messages in a channel.
But the construction still happens primarily through ChatGPT’s agent builder: OpenAI’s setup documentation tells users to create the agent first and then add Slack as a channel. Under the hood, the Slack handles rely on Slack user groups managed by the ChatGPT Agents app, rather than NanoClaw’s model in which every provisioned agent is itself a separate Slack bot.
Salesforce’s Agentforce similarly allows organizations to create multiple specialized agents that employees can DM or @mention inside Slack, and it arguably provides the most conventional enterprise administration model of the group.
Companies build the agents in Agentforce Builder, often starting from Slack-specific templates for jobs such as customer insights, employee help or onboarding, and can add subagents and actions that let them search information, create Canvases or perform other work.
Once configured and activated in Salesforce, administrators bring those agents into Slack for employees to use. That makes Agentforce powerful for organizations already centering identity, data and workflows on Salesforce, but again places agent creation before deployment rather than making creation itself something an existing Slack agent can perform during a conversation.
That distinction helps clarify what NanoClaw is actually adding to an increasingly crowded market. Slack itself now provides an Agent Kit for developers and a deployment standard for agents built on outside platforms, automating pieces such as OAuth, manifests and environment configuration. Claude Tag, ChatGPT Workspace Agents and Agentforce all demonstrate that persistent, specialized AI teammates inside Slack are no longer novel on their own.
NanoClaw’s more unusual bet is recursive provisioning: Slack becomes not merely the place where workers invoke agents, but a place where an existing agent can assemble additional named agents, assign them roles and put them together in a channel as a working team.
There are tradeoffs to the different approaches. Claude Tag comes with Anthropic-managed models and centralized administrative controls, including channel-specific permissions, audit logs and token-spending limits, while also offering proactive “ambient” behavior that NanoClaw’s supplied materials do not claim in the same way.
ChatGPT Workspace Agents offer a managed agent builder, schedules, app connections and organization-level publishing and access controls. Agentforce ties agents closely to Salesforce permissions, enterprise data and predefined business actions.
NanoClaw instead emphasizes self-hosting, open-source modification and separate agent identities, shifting more control — and more operational responsibility — to the organization running it.
The result is less a direct replacement for those systems than a different answer to the same emerging question: whether enterprises want a small number of centrally configured AI assistants, or an environment in which employees and existing agents can continuously create specialized digital colleagues as new work appears.
How NanoClaw got here
NanoClaw began far from the enterprise collaboration market. Cohen, a former Wix engineer, launched it under the MIT License on Jan. 31, 2026, as a deliberately small, security-focused alternative to OpenClaw.
The original pitch was that a personal agent with access to messages, files and tools should run inside an OS-isolated container rather than directly on the host, and that the orchestration layer should remain small enough for a developer or security team to understand — an initial core of roughly 500 lines of TypeScript and a design centered on container isolation and a minimal single-process architecture.
The project then moved steadily toward enterprise infrastructure. In March, NanoClaw partnered with Docker to run agents inside Docker Sandboxes, using stronger MicroVM-backed isolation for workloads that may install packages, modify files and launch processes.
In April, NanoClaw 2.0 added Vercel’s Chat SDK and OneCLI’s credential gateway, allowing organizations to define policies around sensitive actions and require human approval before credentials are injected for protected requests.
By May, Cohen and his brother Lazer Cohen had formed NanoCo around the project and raised a $12 million seed round led by Valley Capital Partners, with Docker, Vercel, monday.com and others participating. The commercial strategy is to keep NanoClaw open source while selling managed, organization-wide deployments and “professional assistant” infrastructure to enterprises. The company now says NanoClaw has surpassed 250,000 downloads and 30,000 GitHub stars.
That open-source structure remains central to Cohen’s pitch as NanoClaw moves deeper into workplace infrastructure.
“You’re really able to now integrate an open-source agent into Slack that you fully control,” he said. “You can change all those configurations. Plus, you can fork NanoClaw and completely rewrite or change behaviors — create your own memory system, your own coding harness, agent harness. Whatever you want to do, you can do. Total freedom.”
Persistent agents, but infrastructure stays under the user’s control
Cohen said NanoClaw remains self-hosted: an organization can run it on a local machine or its own cloud VM, with agent data stored there.
The same agent can also appear across Slack, WhatsApp or Telegram while retaining the same memory, workspace and tools, although each messaging surface uses a separate session.
NanoClaw can pull recent context across those sessions so the agent can maintain continuity without merging every chat history into one stream. NanoClaw’s documentation likewise describes a multi-channel architecture in which the same agent can retain one workspace and memory while maintaining separate per-channel sessions.
“This is all self-hosted,” Cohen said. “You’d be running this on your computer or on your virtual machine in the cloud, and that data is stored on your computer or on your [virtual machine] VM. This could be an open-source model running on your Mac Mini, and your data isn’t going anywhere besides your Mac Mini and then into Slack.”
The cross-channel continuity is also intended to make an agent feel less like a Slack-specific bot and more like a persistent colleague that happens to be reachable through Slack.
Cohen said the same agent could exist in Telegram, WhatsApp and Slack with access to the same memory, files and tools. The conversations remain separate sessions, but they share a workspace and persistent context so the agent can carry knowledge from one surface to another.
That architecture matters when an organization starts creating many agents. Cohen said one agent can see its own sessions across channels, but not another agent’s private sessions by default. NanoClaw’s current documentation likewise describes agents running in their own sandboxes and configurable model providers, with Claude Code as the default and Codex, OpenCode and local Ollama models available as alternatives.
There is one cloud dependency for the new Slack flow. Cohen said NanoCo operates a small service that handles Slack provisioning requests and avatar generation. He said it does not receive users’ messages or agent memory.
Continued commitment to open source
NanoCo is not charging for this community Slack capability, according to Cohen, and is absorbing the provisioning-service and avatar-generation costs. Users can still incur their own model inference and hosting expenses, so that does not make a deployed agent team cost-free in practice.
NanoCo says the integration is available through the Slack Marketplace, subject to normal workspace app approval and governance. Slack says workspace owners and administrators can require apps to be approved before installation.
Cohen framed that decision as part of NanoCo’s broader open-source strategy rather than a standalone monetization play. “We’re not making any money off this one. This one is for the community, really,” he said. “We know that in the long run that’s going to benefit NanoCo as a company. As NanoCo grows and builds out capabilities, those go back to the open source. I think that’s the new model of open source, where we’re not trying to monetize every bit of value we bring to the community.”
Whether companies get there that quickly will depend less on how easily agents can be created than on whether IT teams can govern their permissions, memory, spending and failure modes at the same pace. NanoClaw is betting that the next problem is managing the digital coworkers that appear once that barrier is gone.
Adding an AI agent to Slack sounds appealing to many enterprises — but, as VentureBeat has experienced ourselves first hand — the reality is often far more complex and clunkier than it first seems.
Now NanoCo., the company behind the hit open source, enterprise-friendly, autonomous AI agent harness NanoClaw (a more sandboxed, lower code version of OpenClaw), is hoping to make it just as easy as typing a Slack message. To go one step further: the company’s new NanoClaw Slack integration lets human users spin up entire teams of agents with their own specialized skills, workflows, and even custom avatars, all from a single Slack prompt.
«In the next 12 to 18 months, everyone on a team will be a manager of agents,» NanoCo CEO and co-founder Gavriel Cohen told VentureBeat in an exclusive interview.
Furthermore, the NanoClaw agents can work together in channels and shared Slack Canvases, and can even be messaged outside of Slack on other platforms like Telegram or WhatsApp, letting their human colleagues ping them across messaging platforms, just as they would their fellow humans.
“I think this is agents arriving natively in Slack for the first time,” Cohen added. “In the past, you had to do all these weird things to try to have multiple different agents behind the scenes using the same bot, and now every agent gets its own identity in Slack — its own avatar, its own face, its own name. You can tag them. They can tag each other.”
For enterprise teams, the more consequential part is persistence and separation. NanoClaw is not presenting the additional workers as invisible subagents that disappear after one task. Each can be given its own role, memory context, instructions and permissions, creating a structure closer to a small digital department than a single chatbot with a long prompt.
As with the original open source version of NanoClaw released in January 2026, developers and enterprises can further choose whichever underlying large language model (LLM) they wish to power their NanoClaw agents, optimizing for performance, cost, or other combinations of factors.
From a single NanoClaw Slack agent to a whole specialized team
For a new installation, NanoClaw’s current setup process starts by cloning the project and running its nanoclaw.sh installer, which walks the user through dependencies, credentials, building the agent container and pairing a first messaging channel. NanoClaw’s website says the installer takes a user “from a fresh machine to a named agent you can message,” with Slack among the supported channels.
Cohen described the Slack-specific flow to VentureBeat as a significant simplification over building a traditional Slack bot. Previously, he said, a user would have to navigate Slack’s administrative and developer interfaces, create an app, collect secrets, API keys and tokens, and then move those credentials into wherever the bot was running.
With the new integration, the NanoClaw setup instead offers a Connect Slack option. The user names the agent, authenticates, chooses the NanoClaw Add to Slack option and goes through Slack’s installation and authorization flow. Once authorized, the first agent can appear in Slack and begin communicating with the user.
The important distinction is that this initial authorization is largely a one-time workspace connection. Slack’s Marketplace listing says users “connect a workspace once,” after which NanoClaw can provision each additional agent as its own Slack bot, complete with its own name, generated avatar and identity.
Those agents continue running on the customer’s infrastructure and connect to Slack over Socket Mode. NanoCo says it does not store the agents’ Slack tokens; according to the Marketplace listing, those tokens remain on the user’s machine.
Slack’s standard administrative controls still sit around that system. Organizations can apply their normal app-approval policies to the NanoClaw integration, while NanoClaw’s Marketplace listing says the app’s Home tab displays the agents provisioned in a workspace and lets users revoke individual agents or disconnect the workspace entirely.
The result is less a one-click replacement for NanoClaw’s underlying infrastructure than a one-time bridge between that infrastructure and Slack: users still own and operate the agent runtime, but once the bridge is authorized, the agents themselves can create and coordinate additional Slack-native colleagues without sending the user back through manual app configuration each time.
Behind the scenes, Cohen said, the lead agent has a Model Context Protocol (MCP) tool that can create new agents and define their instructions, personas, skills and tools; another tool can place them into shared rooms. The agents come prepared to work with Slack Canvas and can communicate with every human user on the Slack Channel, and with one another.
The interaction itself is deliberately simple. Rather than opening a separate agent builder every time a new role is needed, Cohen said users can tell the agent they already have what kind of colleague or team they want.
“Your agent in Slack, you can say, ‘Create me another agent to handle my code reviews. Create another agent to review the contributor articles. Create a team of agents that reviews contributor articles from different perspectives.’ And then your agent can create new agents, and they just pop up in the sidebar and send you messages.”
That means a developer could ask for a product manager, architect, implementation agent, code reviewer and testing agent, then give each a different toolset and have them hand work between one another. Cohen said the testing agent, for example, could have access to a testing environment while the review agent carries code-review-specific skills and the product agent monitors user feedback.
Cohen argues that this division of labor is more than cosmetic role-playing. “There are advantages in terms of giving each one specific skills, instructions, and tools for different tasks,” he said. “I can have, let’s say, a code review agent, a code testing agent, a code writing agent, and I can have them in a loop.” If the implementation agent runs into an ambiguity, he added, it can tag the product or architecture agent for clarification rather than forcing one general-purpose model to hold every responsibility and tool in the same context.
Agents work together with humans on a share Slack Canvas
A supplied demo screenshot shows the same pattern applied to marketing: a lead agent named Nano creates Atlas for strategy, Sage for content, Echo for social, Scout for outreach and Compass for SEO and analytics. The agents introduce themselves in the same Slack conversation and begin coordinating work, with Atlas noting that it had added an item to Canvas so the task would not get lost.
Users do not have to specify every detail up front. Cohen said someone could give the lead agent exact review procedures, priorities and required tools, or leave more of the configuration to the agent based on its existing context and memory.
The design also tries to avoid a familiar multi-agent failure mode: bots endlessly triggering one another. NanoCo says the agents reply only when tagged, while comments left on work in Canvas can be routed back to the agent responsible for that piece.
And the model can extend beyond teams of task-specific bots created by one person. Cohen described a workplace where individual employees each have persistent agents that can communicate with one another under human-defined policies.
“Each person having their own agent means that I could have my agent and you have your agent in Slack, and your agent can ask my agent questions,” he said. “Maybe I’m out of the office for the day. Your agent can ping my agent and ask a question about availability, and I can set some policies about whether my agent can answer or if I need to give approval.”
That pushes the concept closer to organizational delegation: some agents specialize by function, while others effectively represent individual employees and the context they have accumulated. Cohen said the agents can be equipped with browser and internet access, memory, coding capabilities and other tools, while newly created agents arrive with built-in support for Canvas work, agent-to-agent communication and spawning still more agents.
Slack is opening the door to more third-party agents
The underlying Slack change is broader than NanoClaw.
In April, Slack, a Salesforce product, announced the ability to add external AI agents to the messaging platform directly, initially pointing to Vercel and Lovable and saying those integrations were coming in late May.
Slack said the deployment mechanism automates OAuth, manifest configuration and environment setup so an externally built agent can be brought into the workspace without being rebuilt specifically for Slack.
Salesforce’s newly published Slack Code page now names NanoClaw alongside Lovable, Hyperagent, Superhuman, n8n, Vercel, ChatGPT, LangChain, Runlayer and Skydive, and says Add to Slack can bring agents from those platforms into Slack in a few clicks with their own identity.
Slack is already crowded with AI assistants. OpenAI, for example, lets ChatGPT workspace agents be deployed into Slack channels, where they can answer questions, perform tasks through connected systems and output files. Slack also supports Claude and custom Agentforce agents. NanoClaw’s differentiation is therefore not simply “AI in Slack.” It is the ability for an already-running agent to create additional, independently addressable teammates from inside the conversation itself. NanoCo calls that a first for Slack; that specific market-first claim is the company’s.
“Add to Slack means one message can spin up a full team of NanoClaw agents, working right alongside people in Slack,” Josh Milas, director of product management at Slack, said in the supplied announcement.
How NanoClaw differs from Claude Tag, ChatGPT agents and Agentforce in Slack
NanoClaw is not alone in trying to turn AI from a sidebar chatbot into something resembling a persistent Slack colleague.
Anthropic’s Claude Tag, which began rolling out in beta to Claude Team and Enterprise customers in June, may be the closest conceptual comparison.
Administrators can give @Claude access to selected channels, tools, data sources and codebases; everyone in the channel can then delegate work to it by tagging it. Claude remembers relevant information from the channels it inhabits, can work asynchronously over hours or days, and, when administrators enable its “ambient” behavior, can proactively flag information or revive unresolved work without waiting for another prompt.
Anthropic says separate Claude identities can also be scoped to different use cases so that, for example, a sales Claude does not share its memories or tools with an engineering Claude.
The difference is in how those digital coworkers are provisioned and organized. Claude Tag’s documented workflow is administrator-led: admins pair Claude with Slack, decide which channels, tools and information each Claude identity can access, set spending limits and then expose those identities to employees.
Within a given channel, Anthropic describes “one Claude that interacts with everyone.” Its public documentation does not describe an end user asking that Claude to create several new, independently named Slack bots on demand. NanoClaw’s model is almost inverted.
After an organization connects its NanoClaw installation to Slack once, NanoClaw says an existing agent can itself provision additional agents from a conversational request, with each new worker receiving its own Slack bot identity, name, generated avatar and token and running back on the customer’s infrastructure.
OpenAI’s ChatGPT Workspace Agents occupy another point on that spectrum.
Business, Edu and Enterprise customers can build reusable agents in ChatGPT, give them instructions, models, files, apps, custom MCP connections and schedules, and then attach those agents to Slack channels.
Builders assign each agent a unique Slack handle and can configure it either to respond only when mentioned or to respond automatically to relevant messages in a channel.
But the construction still happens primarily through ChatGPT’s agent builder: OpenAI’s setup documentation tells users to create the agent first and then add Slack as a channel. Under the hood, the Slack handles rely on Slack user groups managed by the ChatGPT Agents app, rather than NanoClaw’s model in which every provisioned agent is itself a separate Slack bot.
Salesforce’s Agentforce similarly allows organizations to create multiple specialized agents that employees can DM or @mention inside Slack, and it arguably provides the most conventional enterprise administration model of the group.
Companies build the agents in Agentforce Builder, often starting from Slack-specific templates for jobs such as customer insights, employee help or onboarding, and can add subagents and actions that let them search information, create Canvases or perform other work.
Once configured and activated in Salesforce, administrators bring those agents into Slack for employees to use. That makes Agentforce powerful for organizations already centering identity, data and workflows on Salesforce, but again places agent creation before deployment rather than making creation itself something an existing Slack agent can perform during a conversation.
That distinction helps clarify what NanoClaw is actually adding to an increasingly crowded market. Slack itself now provides an Agent Kit for developers and a deployment standard for agents built on outside platforms, automating pieces such as OAuth, manifests and environment configuration. Claude Tag, ChatGPT Workspace Agents and Agentforce all demonstrate that persistent, specialized AI teammates inside Slack are no longer novel on their own.
NanoClaw’s more unusual bet is recursive provisioning: Slack becomes not merely the place where workers invoke agents, but a place where an existing agent can assemble additional named agents, assign them roles and put them together in a channel as a working team.
There are tradeoffs to the different approaches. Claude Tag comes with Anthropic-managed models and centralized administrative controls, including channel-specific permissions, audit logs and token-spending limits, while also offering proactive “ambient” behavior that NanoClaw’s supplied materials do not claim in the same way.
ChatGPT Workspace Agents offer a managed agent builder, schedules, app connections and organization-level publishing and access controls. Agentforce ties agents closely to Salesforce permissions, enterprise data and predefined business actions.
NanoClaw instead emphasizes self-hosting, open-source modification and separate agent identities, shifting more control — and more operational responsibility — to the organization running it.
The result is less a direct replacement for those systems than a different answer to the same emerging question: whether enterprises want a small number of centrally configured AI assistants, or an environment in which employees and existing agents can continuously create specialized digital colleagues as new work appears.
How NanoClaw got here
NanoClaw began far from the enterprise collaboration market. Cohen, a former Wix engineer, launched it under the MIT License on Jan. 31, 2026, as a deliberately small, security-focused alternative to OpenClaw.
The original pitch was that a personal agent with access to messages, files and tools should run inside an OS-isolated container rather than directly on the host, and that the orchestration layer should remain small enough for a developer or security team to understand — an initial core of roughly 500 lines of TypeScript and a design centered on container isolation and a minimal single-process architecture.
The project then moved steadily toward enterprise infrastructure. In March, NanoClaw partnered with Docker to run agents inside Docker Sandboxes, using stronger MicroVM-backed isolation for workloads that may install packages, modify files and launch processes.
In April, NanoClaw 2.0 added Vercel’s Chat SDK and OneCLI’s credential gateway, allowing organizations to define policies around sensitive actions and require human approval before credentials are injected for protected requests.
By May, Cohen and his brother Lazer Cohen had formed NanoCo around the project and raised a $12 million seed round led by Valley Capital Partners, with Docker, Vercel, monday.com and others participating. The commercial strategy is to keep NanoClaw open source while selling managed, organization-wide deployments and “professional assistant” infrastructure to enterprises. The company now says NanoClaw has surpassed 250,000 downloads and 30,000 GitHub stars.
That open-source structure remains central to Cohen’s pitch as NanoClaw moves deeper into workplace infrastructure.
“You’re really able to now integrate an open-source agent into Slack that you fully control,” he said. “You can change all those configurations. Plus, you can fork NanoClaw and completely rewrite or change behaviors — create your own memory system, your own coding harness, agent harness. Whatever you want to do, you can do. Total freedom.”
Persistent agents, but infrastructure stays under the user’s control
Cohen said NanoClaw remains self-hosted: an organization can run it on a local machine or its own cloud VM, with agent data stored there.
The same agent can also appear across Slack, WhatsApp or Telegram while retaining the same memory, workspace and tools, although each messaging surface uses a separate session.
NanoClaw can pull recent context across those sessions so the agent can maintain continuity without merging every chat history into one stream. NanoClaw’s documentation likewise describes a multi-channel architecture in which the same agent can retain one workspace and memory while maintaining separate per-channel sessions.
“This is all self-hosted,” Cohen said. “You’d be running this on your computer or on your virtual machine in the cloud, and that data is stored on your computer or on your [virtual machine] VM. This could be an open-source model running on your Mac Mini, and your data isn’t going anywhere besides your Mac Mini and then into Slack.”
The cross-channel continuity is also intended to make an agent feel less like a Slack-specific bot and more like a persistent colleague that happens to be reachable through Slack.
Cohen said the same agent could exist in Telegram, WhatsApp and Slack with access to the same memory, files and tools. The conversations remain separate sessions, but they share a workspace and persistent context so the agent can carry knowledge from one surface to another.
That architecture matters when an organization starts creating many agents. Cohen said one agent can see its own sessions across channels, but not another agent’s private sessions by default. NanoClaw’s current documentation likewise describes agents running in their own sandboxes and configurable model providers, with Claude Code as the default and Codex, OpenCode and local Ollama models available as alternatives.
There is one cloud dependency for the new Slack flow. Cohen said NanoCo operates a small service that handles Slack provisioning requests and avatar generation. He said it does not receive users’ messages or agent memory.
Continued commitment to open source
NanoCo is not charging for this community Slack capability, according to Cohen, and is absorbing the provisioning-service and avatar-generation costs. Users can still incur their own model inference and hosting expenses, so that does not make a deployed agent team cost-free in practice.
NanoCo says the integration is available through the Slack Marketplace, subject to normal workspace app approval and governance. Slack says workspace owners and administrators can require apps to be approved before installation.
Cohen framed that decision as part of NanoCo’s broader open-source strategy rather than a standalone monetization play. “We’re not making any money off this one. This one is for the community, really,” he said. “We know that in the long run that’s going to benefit NanoCo as a company. As NanoCo grows and builds out capabilities, those go back to the open source. I think that’s the new model of open source, where we’re not trying to monetize every bit of value we bring to the community.”
Whether companies get there that quickly will depend less on how easily agents can be created than on whether IT teams can govern their permissions, memory, spending and failure modes at the same pace. NanoClaw is betting that the next problem is managing the digital coworkers that appear once that barrier is gone.
Adding an AI agent to Slack sounds appealing to many enterprises — but, as VentureBeat has experienced ourselves first hand — the reality is often far more complex and clunkier than it first seems.
Now NanoCo., the company behind the hit open source, enterprise-friendly, autonomous AI agent harness NanoClaw (a more sandboxed, lower code version of OpenClaw), is hoping to make it just as easy as typing a Slack message. To go one step further: the company’s new NanoClaw Slack integration lets human users spin up entire teams of agents with their own specialized skills, workflows, and even custom avatars, all from a single Slack prompt.
«In the next 12 to 18 months, everyone on a team will be a manager of agents,» NanoCo CEO and co-founder Gavriel Cohen told VentureBeat in an exclusive interview.
Furthermore, the NanoClaw agents can work together in channels and shared Slack Canvases, and can even be messaged outside of Slack on other platforms like Telegram or WhatsApp, letting their human colleagues ping them across messaging platforms, just as they would their fellow humans.
“I think this is agents arriving natively in Slack for the first time,” Cohen added. “In the past, you had to do all these weird things to try to have multiple different agents behind the scenes using the same bot, and now every agent gets its own identity in Slack — its own avatar, its own face, its own name. You can tag them. They can tag each other.”
For enterprise teams, the more consequential part is persistence and separation. NanoClaw is not presenting the additional workers as invisible subagents that disappear after one task. Each can be given its own role, memory context, instructions and permissions, creating a structure closer to a small digital department than a single chatbot with a long prompt.
As with the original open source version of NanoClaw released in January 2026, developers and enterprises can further choose whichever underlying large language model (LLM) they wish to power their NanoClaw agents, optimizing for performance, cost, or other combinations of factors.
From a single NanoClaw Slack agent to a whole specialized team
For a new installation, NanoClaw’s current setup process starts by cloning the project and running its nanoclaw.sh installer, which walks the user through dependencies, credentials, building the agent container and pairing a first messaging channel. NanoClaw’s website says the installer takes a user “from a fresh machine to a named agent you can message,” with Slack among the supported channels.
Cohen described the Slack-specific flow to VentureBeat as a significant simplification over building a traditional Slack bot. Previously, he said, a user would have to navigate Slack’s administrative and developer interfaces, create an app, collect secrets, API keys and tokens, and then move those credentials into wherever the bot was running.
With the new integration, the NanoClaw setup instead offers a Connect Slack option. The user names the agent, authenticates, chooses the NanoClaw Add to Slack option and goes through Slack’s installation and authorization flow. Once authorized, the first agent can appear in Slack and begin communicating with the user.
The important distinction is that this initial authorization is largely a one-time workspace connection. Slack’s Marketplace listing says users “connect a workspace once,” after which NanoClaw can provision each additional agent as its own Slack bot, complete with its own name, generated avatar and identity.
Those agents continue running on the customer’s infrastructure and connect to Slack over Socket Mode. NanoCo says it does not store the agents’ Slack tokens; according to the Marketplace listing, those tokens remain on the user’s machine.
Slack’s standard administrative controls still sit around that system. Organizations can apply their normal app-approval policies to the NanoClaw integration, while NanoClaw’s Marketplace listing says the app’s Home tab displays the agents provisioned in a workspace and lets users revoke individual agents or disconnect the workspace entirely.
The result is less a one-click replacement for NanoClaw’s underlying infrastructure than a one-time bridge between that infrastructure and Slack: users still own and operate the agent runtime, but once the bridge is authorized, the agents themselves can create and coordinate additional Slack-native colleagues without sending the user back through manual app configuration each time.
Behind the scenes, Cohen said, the lead agent has a Model Context Protocol (MCP) tool that can create new agents and define their instructions, personas, skills and tools; another tool can place them into shared rooms. The agents come prepared to work with Slack Canvas and can communicate with every human user on the Slack Channel, and with one another.
The interaction itself is deliberately simple. Rather than opening a separate agent builder every time a new role is needed, Cohen said users can tell the agent they already have what kind of colleague or team they want.
“Your agent in Slack, you can say, ‘Create me another agent to handle my code reviews. Create another agent to review the contributor articles. Create a team of agents that reviews contributor articles from different perspectives.’ And then your agent can create new agents, and they just pop up in the sidebar and send you messages.”
That means a developer could ask for a product manager, architect, implementation agent, code reviewer and testing agent, then give each a different toolset and have them hand work between one another. Cohen said the testing agent, for example, could have access to a testing environment while the review agent carries code-review-specific skills and the product agent monitors user feedback.
Cohen argues that this division of labor is more than cosmetic role-playing. “There are advantages in terms of giving each one specific skills, instructions, and tools for different tasks,” he said. “I can have, let’s say, a code review agent, a code testing agent, a code writing agent, and I can have them in a loop.” If the implementation agent runs into an ambiguity, he added, it can tag the product or architecture agent for clarification rather than forcing one general-purpose model to hold every responsibility and tool in the same context.
Agents work together with humans on a share Slack Canvas
A supplied demo screenshot shows the same pattern applied to marketing: a lead agent named Nano creates Atlas for strategy, Sage for content, Echo for social, Scout for outreach and Compass for SEO and analytics. The agents introduce themselves in the same Slack conversation and begin coordinating work, with Atlas noting that it had added an item to Canvas so the task would not get lost.
Users do not have to specify every detail up front. Cohen said someone could give the lead agent exact review procedures, priorities and required tools, or leave more of the configuration to the agent based on its existing context and memory.
The design also tries to avoid a familiar multi-agent failure mode: bots endlessly triggering one another. NanoCo says the agents reply only when tagged, while comments left on work in Canvas can be routed back to the agent responsible for that piece.
And the model can extend beyond teams of task-specific bots created by one person. Cohen described a workplace where individual employees each have persistent agents that can communicate with one another under human-defined policies.
“Each person having their own agent means that I could have my agent and you have your agent in Slack, and your agent can ask my agent questions,” he said. “Maybe I’m out of the office for the day. Your agent can ping my agent and ask a question about availability, and I can set some policies about whether my agent can answer or if I need to give approval.”
That pushes the concept closer to organizational delegation: some agents specialize by function, while others effectively represent individual employees and the context they have accumulated. Cohen said the agents can be equipped with browser and internet access, memory, coding capabilities and other tools, while newly created agents arrive with built-in support for Canvas work, agent-to-agent communication and spawning still more agents.
Slack is opening the door to more third-party agents
The underlying Slack change is broader than NanoClaw.
In April, Slack, a Salesforce product, announced the ability to add external AI agents to the messaging platform directly, initially pointing to Vercel and Lovable and saying those integrations were coming in late May.
Slack said the deployment mechanism automates OAuth, manifest configuration and environment setup so an externally built agent can be brought into the workspace without being rebuilt specifically for Slack.
Salesforce’s newly published Slack Code page now names NanoClaw alongside Lovable, Hyperagent, Superhuman, n8n, Vercel, ChatGPT, LangChain, Runlayer and Skydive, and says Add to Slack can bring agents from those platforms into Slack in a few clicks with their own identity.
Slack is already crowded with AI assistants. OpenAI, for example, lets ChatGPT workspace agents be deployed into Slack channels, where they can answer questions, perform tasks through connected systems and output files. Slack also supports Claude and custom Agentforce agents. NanoClaw’s differentiation is therefore not simply “AI in Slack.” It is the ability for an already-running agent to create additional, independently addressable teammates from inside the conversation itself. NanoCo calls that a first for Slack; that specific market-first claim is the company’s.
“Add to Slack means one message can spin up a full team of NanoClaw agents, working right alongside people in Slack,” Josh Milas, director of product management at Slack, said in the supplied announcement.
How NanoClaw differs from Claude Tag, ChatGPT agents and Agentforce in Slack
NanoClaw is not alone in trying to turn AI from a sidebar chatbot into something resembling a persistent Slack colleague.
Anthropic’s Claude Tag, which began rolling out in beta to Claude Team and Enterprise customers in June, may be the closest conceptual comparison.
Administrators can give @Claude access to selected channels, tools, data sources and codebases; everyone in the channel can then delegate work to it by tagging it. Claude remembers relevant information from the channels it inhabits, can work asynchronously over hours or days, and, when administrators enable its “ambient” behavior, can proactively flag information or revive unresolved work without waiting for another prompt.
Anthropic says separate Claude identities can also be scoped to different use cases so that, for example, a sales Claude does not share its memories or tools with an engineering Claude.
The difference is in how those digital coworkers are provisioned and organized. Claude Tag’s documented workflow is administrator-led: admins pair Claude with Slack, decide which channels, tools and information each Claude identity can access, set spending limits and then expose those identities to employees.
Within a given channel, Anthropic describes “one Claude that interacts with everyone.” Its public documentation does not describe an end user asking that Claude to create several new, independently named Slack bots on demand. NanoClaw’s model is almost inverted.
After an organization connects its NanoClaw installation to Slack once, NanoClaw says an existing agent can itself provision additional agents from a conversational request, with each new worker receiving its own Slack bot identity, name, generated avatar and token and running back on the customer’s infrastructure.
OpenAI’s ChatGPT Workspace Agents occupy another point on that spectrum.
Business, Edu and Enterprise customers can build reusable agents in ChatGPT, give them instructions, models, files, apps, custom MCP connections and schedules, and then attach those agents to Slack channels.
Builders assign each agent a unique Slack handle and can configure it either to respond only when mentioned or to respond automatically to relevant messages in a channel.
But the construction still happens primarily through ChatGPT’s agent builder: OpenAI’s setup documentation tells users to create the agent first and then add Slack as a channel. Under the hood, the Slack handles rely on Slack user groups managed by the ChatGPT Agents app, rather than NanoClaw’s model in which every provisioned agent is itself a separate Slack bot.
Salesforce’s Agentforce similarly allows organizations to create multiple specialized agents that employees can DM or @mention inside Slack, and it arguably provides the most conventional enterprise administration model of the group.
Companies build the agents in Agentforce Builder, often starting from Slack-specific templates for jobs such as customer insights, employee help or onboarding, and can add subagents and actions that let them search information, create Canvases or perform other work.
Once configured and activated in Salesforce, administrators bring those agents into Slack for employees to use. That makes Agentforce powerful for organizations already centering identity, data and workflows on Salesforce, but again places agent creation before deployment rather than making creation itself something an existing Slack agent can perform during a conversation.
That distinction helps clarify what NanoClaw is actually adding to an increasingly crowded market. Slack itself now provides an Agent Kit for developers and a deployment standard for agents built on outside platforms, automating pieces such as OAuth, manifests and environment configuration. Claude Tag, ChatGPT Workspace Agents and Agentforce all demonstrate that persistent, specialized AI teammates inside Slack are no longer novel on their own.
NanoClaw’s more unusual bet is recursive provisioning: Slack becomes not merely the place where workers invoke agents, but a place where an existing agent can assemble additional named agents, assign them roles and put them together in a channel as a working team.
There are tradeoffs to the different approaches. Claude Tag comes with Anthropic-managed models and centralized administrative controls, including channel-specific permissions, audit logs and token-spending limits, while also offering proactive “ambient” behavior that NanoClaw’s supplied materials do not claim in the same way.
ChatGPT Workspace Agents offer a managed agent builder, schedules, app connections and organization-level publishing and access controls. Agentforce ties agents closely to Salesforce permissions, enterprise data and predefined business actions.
NanoClaw instead emphasizes self-hosting, open-source modification and separate agent identities, shifting more control — and more operational responsibility — to the organization running it.
The result is less a direct replacement for those systems than a different answer to the same emerging question: whether enterprises want a small number of centrally configured AI assistants, or an environment in which employees and existing agents can continuously create specialized digital colleagues as new work appears.
How NanoClaw got here
NanoClaw began far from the enterprise collaboration market. Cohen, a former Wix engineer, launched it under the MIT License on Jan. 31, 2026, as a deliberately small, security-focused alternative to OpenClaw.
The original pitch was that a personal agent with access to messages, files and tools should run inside an OS-isolated container rather than directly on the host, and that the orchestration layer should remain small enough for a developer or security team to understand — an initial core of roughly 500 lines of TypeScript and a design centered on container isolation and a minimal single-process architecture.
The project then moved steadily toward enterprise infrastructure. In March, NanoClaw partnered with Docker to run agents inside Docker Sandboxes, using stronger MicroVM-backed isolation for workloads that may install packages, modify files and launch processes.
In April, NanoClaw 2.0 added Vercel’s Chat SDK and OneCLI’s credential gateway, allowing organizations to define policies around sensitive actions and require human approval before credentials are injected for protected requests.
By May, Cohen and his brother Lazer Cohen had formed NanoCo around the project and raised a $12 million seed round led by Valley Capital Partners, with Docker, Vercel, monday.com and others participating. The commercial strategy is to keep NanoClaw open source while selling managed, organization-wide deployments and “professional assistant” infrastructure to enterprises. The company now says NanoClaw has surpassed 250,000 downloads and 30,000 GitHub stars.
That open-source structure remains central to Cohen’s pitch as NanoClaw moves deeper into workplace infrastructure.
“You’re really able to now integrate an open-source agent into Slack that you fully control,” he said. “You can change all those configurations. Plus, you can fork NanoClaw and completely rewrite or change behaviors — create your own memory system, your own coding harness, agent harness. Whatever you want to do, you can do. Total freedom.”
Persistent agents, but infrastructure stays under the user’s control
Cohen said NanoClaw remains self-hosted: an organization can run it on a local machine or its own cloud VM, with agent data stored there.
The same agent can also appear across Slack, WhatsApp or Telegram while retaining the same memory, workspace and tools, although each messaging surface uses a separate session.
NanoClaw can pull recent context across those sessions so the agent can maintain continuity without merging every chat history into one stream. NanoClaw’s documentation likewise describes a multi-channel architecture in which the same agent can retain one workspace and memory while maintaining separate per-channel sessions.
“This is all self-hosted,” Cohen said. “You’d be running this on your computer or on your virtual machine in the cloud, and that data is stored on your computer or on your [virtual machine] VM. This could be an open-source model running on your Mac Mini, and your data isn’t going anywhere besides your Mac Mini and then into Slack.”
The cross-channel continuity is also intended to make an agent feel less like a Slack-specific bot and more like a persistent colleague that happens to be reachable through Slack.
Cohen said the same agent could exist in Telegram, WhatsApp and Slack with access to the same memory, files and tools. The conversations remain separate sessions, but they share a workspace and persistent context so the agent can carry knowledge from one surface to another.
That architecture matters when an organization starts creating many agents. Cohen said one agent can see its own sessions across channels, but not another agent’s private sessions by default. NanoClaw’s current documentation likewise describes agents running in their own sandboxes and configurable model providers, with Claude Code as the default and Codex, OpenCode and local Ollama models available as alternatives.
There is one cloud dependency for the new Slack flow. Cohen said NanoCo operates a small service that handles Slack provisioning requests and avatar generation. He said it does not receive users’ messages or agent memory.
Continued commitment to open source
NanoCo is not charging for this community Slack capability, according to Cohen, and is absorbing the provisioning-service and avatar-generation costs. Users can still incur their own model inference and hosting expenses, so that does not make a deployed agent team cost-free in practice.
NanoCo says the integration is available through the Slack Marketplace, subject to normal workspace app approval and governance. Slack says workspace owners and administrators can require apps to be approved before installation.
Cohen framed that decision as part of NanoCo’s broader open-source strategy rather than a standalone monetization play. “We’re not making any money off this one. This one is for the community, really,” he said. “We know that in the long run that’s going to benefit NanoCo as a company. As NanoCo grows and builds out capabilities, those go back to the open source. I think that’s the new model of open source, where we’re not trying to monetize every bit of value we bring to the community.”
Whether companies get there that quickly will depend less on how easily agents can be created than on whether IT teams can govern their permissions, memory, spending and failure modes at the same pace. NanoClaw is betting that the next problem is managing the digital coworkers that appear once that barrier is gone.
