OpenClaw 2.0 turns the personal AI agent into team infrastructure

OpenClaw shipped 106 releases in 230 days, then went quiet for nearly seven weeks.

On August 30, 2026, the project released OpenClaw 2.0, officially version v2026.8.1, with work from 933 contributors, including 569 first-time contributors, and more than 16,000 pull requests.

The release touches installation, messaging, sessions, memory, skills, models, automations, the browser, native apps, plugins and security.

The size of the update is impressive. The more important change is structural.

OpenClaw began primarily as an open-source AI agent for one person’s tools and workflows. OpenClaw 2.0 makes it easier to set up, share work across people and devices, control what different operators can access and authorize recurring operations.

That moves OpenClaw closer to a shared operating layer for people and agents, where permissions, credentials and handoffs matter as much as prompts.

Six OpenClaw 2.0 changes that matter most for teams

OpenClaw says version 2.0 started with a simpler installation process and a rebuilt browser experience. The cleanup expanded until much of the product had changed.

New users can begin with AI access already available on their machine, including existing ChatGPT or Claude access, API keys and local models. The browser now opens directly into a conversation and can be used to continue setup, return to ongoing work and follow active tasks.

But the most important OpenClaw 2.0 features for teams sit deeper in the product.

• Sessions beyond the Gateway: Work can move to paired devices or cloud workers while keeping durable session context and workspace state.
• Team operator roles: Verified users can be restricted to selected agents, sessions and operator scopes.
• Private credential requests: Agents can request credentials through masked prompts without placing the secret value directly into chat or model context.
• Recurring approvals: An automation can receive permission for one exact operation, while a changed job or operation requires approval again.
• Longer-running work: Goals, Workboards, progress cards and session dashboards make active agent work easier to follow.
• Plugin and capability checks: Provenance warnings, security information and capability reviews introduce checks before executable extensions are trusted.

Together, those changes broaden what kind of work OpenClaw is designed to handle.

The product is no longer only asking: can an agent complete this task?

It is increasingly asking: who owns the task, where can it run, what can it access, who can see it and what happens when the requested action changes?

OpenClaw now grows through three operating stages

The changes make it useful to think about OpenClaw as three increasingly complex operating models.

1. A local AI agent for one person

The simplest OpenClaw setup can still monitor one source, complete a narrow task and send the result somewhere useful.

That remains the easiest place to start.

One person understands the context, controls the machine and has a relatively clear permission boundary. There are fewer questions about who can access a session or whether one user’s credentials should be available to another.

For individuals experimenting with a local AI agent, that simplicity remains one of OpenClaw’s strengths.

2. A shared AI workspace for a team

Shared sessions change the collaboration model.

A conversation can become team-visible work that another authorized teammate can open, follow, steer or take over without discarding the context that has already accumulated.

Cloud workers extend the operating model further by allowing work to execute away from the main Gateway while the durable session and workspace remain connected.

That starts to resemble the model behind Block Buzz, where humans and agents operate inside the same workspace, and OpenWorker, which focuses on agents handing back finished work rather than stopping at a chat response.

The interesting change is not simply collaboration.

It is continuity.

If agents are going to complete longer-running work, teams need a way to understand what has already happened, what the agent is doing now and when a person needs to step in.

3. Delegated, recurring work

The third stage is where things become more consequential.

Once a team trusts a workflow, recurring approvals allow an agent to repeat an exact operation without asking for the same permission every time.

The important detail is that the permission is attached to the operation.

Change the job and OpenClaw asks again.

That is a more useful definition of autonomy than simply giving an agent broad access and hoping its instructions remain aligned with what the business wants.

For agentic workflows, the distinction matters.

A weekly reporting agent should not automatically gain permission to update campaign budgets because someone changed its prompt from “analyse performance” to “optimise performance.”

Repeatability should expand faster than authority.

How OpenClaw 2.0 compares with other AI agent models

The AI agent market is starting to split by operating model rather than one universal definition of “agent.”

Product	Operating model	Where it is strongest	Main tradeoff
OpenClaw 2.0	Open source, local-first with shared and cloud sessions	Flexible personal and team workflows	Team operates more of the stack
Block Buzz	Workspace built for humans and agents together	Shared context, identity and collaboration	Still strongly oriented toward technical teams
OpenWorker	Local desktop agent that completes defined work	Contained business tasks with approvals	Narrower collaboration model
Gemini Spark	Managed cloud agent inside Google’s ecosystem	Recurring work across connected Google products	Greater dependency on one vendor ecosystem
OpenAI Presence	Managed enterprise agent deployment	Customer and employee voice or chat workflows	More centralized, enterprise-oriented deployment

OpenClaw is trying to sit somewhere between the personal agent and the team platform.

That position also brings the responsibilities of both.

Google’s Gemini Spark agent model makes much of the infrastructure Google’s problem. OpenClaw gives the operator considerably more choice over where the agent runs, which models it uses and what it connects to.

OpenAI Presence goes further toward the managed enterprise end of the market, where policies, approved actions, testing and escalation are wrapped around a narrower deployment.

Neither operating model is universally better.

They solve different problems.

A managed environment removes infrastructure work. An open environment creates flexibility.

The question for teams is how much of that flexibility they actually want to operate themselves.

For marketing teams, the value is in the handoff

The immediate marketing use case is not another system for generating copy.

Marketing teams already have plenty of those.

The opportunity sits in the work between research, analysis, preparation and review.

A contained AI marketing automation workflow could monitor selected sources, organize relevant updates, prepare a research brief and hand it to a marketer.

Another could review approved campaign exports and CRM notes, identify unusual changes and prepare a weekly performance report without receiving permission to alter a live budget.

Content teams could let an agent collect source material, compare existing pages and prepare an update brief.

ABM teams could use one to assemble account research before a person decides what message should actually go out.

That is similar to the finished-work shift we examined with GPT-5.6 in Kiro, where the more useful metric becomes the cost and reliability of a completed task rather than the price of an individual prompt.

Four sensible first marketing workflows are:

1. Industry and competitor monitoring: Collect information from approved sources and prepare a human-reviewed summary.
2. Weekly campaign reporting: Read campaign and CRM data without permission to change bids or budgets.
3. Content research: Identify outdated claims, missing evidence and relevant source material before an editor writes.
4. ABM account preparation: Assemble account research while stopping before any outbound message is sent.

These workflows are repetitive, measurable and relatively reversible.

That makes them better starting points for agentic workflows than publishing content, changing campaign budgets or communicating directly with customers.

AI agent permissions are becoming part of product quality

The more an AI agent can do, the less useful “full autonomy” becomes as a product goal.

OpenClaw 2.0 adds AI agent permissions at several layers, including recurring operation approvals, session permission modes, team roles, explicit model allowlists, shared credentials and plugin capability reviews.

One limitation deserves particular attention.

OpenClaw says team operator roles are collaboration controls, not hostile-tenant isolation.

That distinction matters for AI agent security.

A shared Gateway should not be treated like a secure multi-tenant SaaS boundary between mutually untrusted teams.

There is another default teams need to understand: sandboxing is not automatically enabled across every OpenClaw deployment.

OpenClaw treats a Gateway as a trust domain. Teams using the same Gateway therefore still need to decide:

• who belongs inside that trust boundary
• which sessions different operators may access
• which credentials an agent may request
• where protected secrets can be sent
• which tools require sandboxed execution
• which actions always require human approval

If two teams do not trust one another, creating different operator roles inside the same Gateway is not equivalent to isolating them as separate tenants.

This is not administrative work around the product.

It is part of the product.

OpenAI Presence reflects the same broader shift from the managed enterprise side of the market. Useful AI agents increasingly require permissions, escalation rules, evaluation and limits around consequential actions.

The quality of an agent will eventually be judged partly by what it refuses to do.

Open source still means someone owns the maintenance

OpenClaw’s open-source model gives teams flexibility over models, providers, plugins and where work runs.

OpenClaw 2.0 can work with existing subscriptions, API credentials and local models. That makes model choice an operational decision instead of forcing every workflow through one provider.

The same logic behind Cursor Router and multi-model routing applies here.

Routine monitoring might fit a cheaper or faster model.

A complicated research task might justify stronger reasoning.

Sensitive workloads might be routed differently again.

That flexibility is valuable.

It also creates a testing matrix.

Different models call tools differently, interpret instructions differently and produce outputs requiring different levels of review.

A workflow that performs reliably with one model cannot automatically be assumed to behave identically when another model is substituted.

The open model reduces some vendor dependency.

It does not remove operational work.

Someone still owns model evaluation, plugin maintenance, permission design, backups, upgrades and recovery when something breaks.

The OpenClaw 2.0 upgrade deserves a migration plan

Existing OpenClaw users have more to think about than the redesigned browser.

The release includes breaking migrations around OpenProse and older OpenAI model routes. OpenClaw has also moved important session and transcript data into SQLite while adding backup and recovery tooling.

That is a reason not to upgrade a business-critical installation casually.

Before moving a team workflow to OpenClaw 2.0:

• back up the existing state
• inventory active plugins and model routes
• run openclaw doctor --fix and review any migration conflicts it identifies
• review new and changed permissions
• verify which sessions require sandboxing
• test the migrated environment away from production workflows
• confirm that recurring automations still have the intended authority

A release containing more than 16,000 pull requests deserves more than a Friday-afternoon update.

The migration itself may work perfectly.

The larger risk is assuming that permissions, models, plugins and automated workflows behave exactly as they did before.

The first OpenClaw 2.0 test should be boring

OpenClaw 2.0 makes ambitious workflows easy to imagine.

Start with the boring workflow.

Pick one task that runs every week, reads approved information and produces something a person already reviews.

Define four things before the first run:

• approved sources
• expected output
• allowed tools
• stopping and approval conditions

Keep consequential external actions behind human approval.

Then run the workflow several times and measure four things:

Measure	What it tells you
Completion time	Whether automation actually saves work
Human corrections	Whether output quality is stable
Failed tool calls	Whether integrations are reliable
Review time	Whether the agent removes work or simply moves it

That is the same process-first logic behind evaluating AI marketing automation tools.

If the workflow becomes predictable, expand it.

Give it another source. Reduce unnecessary manual steps. Consider one additional approved operation.

If somebody needs to rescue the workflow every week, adding more permissions will not fix it.

More autonomy should be the result of demonstrated reliability, not the starting configuration.

OneMetrik Takeaway

OpenClaw 2.0 is not important because hundreds of people contributed to it or because more than 16,000 pull requests landed around the release.

It matters because the product is crossing a line from personal AI agent to collaborative work system.

Shared sessions make the agent more multiplayer.

Cloud workers make execution more portable.

Recurring approvals make delegation more practical.

Roles, credential controls, sandboxing options and plugin reviews acknowledge the risks that arrive when agents move from answering questions to doing ongoing work.

For marketing teams, that is the more important AI agent trend to watch.

The next stage of AI marketing automation will not be defined by which system writes the best campaign summary from one prompt.

It will be defined by whether an agent can reliably collect the right inputs, complete the same workflow every week, operate inside a clear permission boundary and hand the work back when human judgment is required.

At OneMetrik, we would treat those controls as the feature, not paperwork around the feature.

The next useful agent is not the one allowed to do everything.

It is the one that knows exactly what it can do, completes that work reliably and stops when the boundary changes.